CMMC Toolkit Wiki - User contributions [en]

NIST Cybersecurity Framework

2026-07-30T16:28:28Z

David: Created page with "''' This page is currently under construction."

''' This page is currently under construction.

NIST SP 800-171A R3

2026-07-30T16:28:17Z

David: Replaced content with "''' This page is currently under construction."

''' This page is currently under construction.

NIST SP 800-17 R3

2026-07-30T16:28:05Z

David: Replaced content with "''' This page is currently under construction."

''' This page is currently under construction.

NIST SP 800-171A

2026-07-30T16:27:52Z

David: Replaced content with "''' This page is currently under construction."

''' This page is currently under construction.

NIST SP 800-17 R2

2026-07-30T16:27:05Z

David:

''' This page is currently under construction.

NIST SP 800-17 R2

2026-07-30T16:26:27Z

David: Replaced content with "*** This page is currently under construction. ***"

*** This page is currently under construction. ***

MediaWiki:Sidebar

2026-07-27T03:03:41Z

David:

* navigation
** mainpage | mainpage-description
* CMMC Model and Rule
** Model_Overview | Model Overview
** 32_CFR_Part_170 | 32 CFR Part 170
** 48_CFR_Parts_204_212_217_252 | 48 CFR Parts 204, 212, 217, and 252
* Scoping and Assessment Guides
** Level_1_Scoping_Guidance | Level 1 Scoping Guidance
** Level_1_Self-Assessment_Guide | Level 1 Self-Assessment Guide
** Level_2_Scoping_Guidance | Level 2 Scoping Guidance
** Level_2_Assessment_Guide | Level 2 Assessment Guide
** Level_3_Scoping_Guidance | Level 3 Scoping Guidance
** Level_3_Assessment_Guide | Level 3 Assessment Guide
* CMMC Guides and Tools
** CMMC_Hashing_Guide | CMMC Hashing Guide
** CMMC_Assessment_Process | CMMC Assessment Process (CAP) by CyberAB
** DoD_Assessment_Methodology | DoD Assessment Methodology
** Evidence_Collection_Approach | CMMC Evidence Collection Approach
** DoD Memo on ODPs for 800-171 Revision 3 | DoD Memo on Organization-Defined Parameters for NIST 800-171 Revision 3
* Other Publications and Tools
** NIST_SP_800-17_R2 | NIST SP 800-171 Rev. 2: Protecting CUI in Nonfederal Systems and Organizations
** NIST_SP_800-171A | NIST SP 800-171A: Assessing Security Requirements for CUI
** NIST_SP_800-17_R3 | NIST SP 800-171 Rev. 3: Protecting CUI in Nonfederal Systems and Organizations
** NIST_SP_800-171A_R3 | NIST SP 800-171A Rev. 3: Assessing Security Requirements for CUI
** NIST_Cybersecurity_Framework | NIST Cybersecurity Framework (CSF): NIST Cybersecurity Framework
** External_References | External References

NIST SP 800-171A R3

2026-07-27T03:01:15Z

David: Created page with "'''NIST SP 800-171Ar3''' = Assessing Security Requirements for Controlled Unclassified Information = Ron Ross Computer Security Division, Information Technology Laboratory Victoria Pillitteri Computer Security Division, Information Technology Laboratory This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-171Ar3 May 2024 ---- {{anchor|d30e53-FrontMatterH1}}== Abstract == The protection of Controlled Unclassified Information (C..."

'''NIST SP 800-171Ar3'''

= Assessing Security Requirements for Controlled Unclassified Information =

Ron Ross

Computer Security Division, Information Technology Laboratory

Victoria Pillitteri

Computer Security Division, Information Technology Laboratory

This publication is available free of charge from:

https://doi.org/10.6028/NIST.SP.800-171Ar3

May 2024

----

{{anchor|d30e53-FrontMatterH1}}== Abstract ==

The protection of Controlled Unclassified Information (CUI) is of paramount importance to federal agencies and can directly impact the ability of the Federal Government to successfully conduct its essential missions and functions. This publication provides organizations with assessment procedures and a methodology that can be used to conduct assessments of the security requirements in NIST Special Publication 800-171, ''Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations''. The assessment procedures are flexible and can be customized to the needs of organizations and assessors. Assessments can be conducted as independent, third-party assessments or as government-sponsored assessments. The assessments can be applied with various degrees of rigor based on customer-defined depth and coverage attributes.

{{anchor|d30e60-Head1}}== Keywords ==

assessment, assessment method, assessment object, assessment procedure, assurance, Controlled Unclassified Information, coverage, FISMA, NIST Special Publication 800-171, NIST Special Publication 800-53A, nonfederal organization, nonfederal system, security assessment, security requirement.

{{anchor|d30e64-FrontMatterH1}}== Disclaimer ==

Certain equipment, instruments, software, or materials, commercial or non-commercial, are identified in this paper in order to specify the experimental procedure adequately. Such identification does not imply recommendation or endorsement of any product or service by NIST, nor does it imply that the materials or equipment identified are necessarily the best available for the purpose.

There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST.

Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at https://csrc.nist.gov/publications.

{{anchor|d30e76-FrontMatterH1}}== Authority ==

This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283 [[[#bibr-ref_1|1]]]. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130 [[[#bibr-ref_2|2]]].

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

{{anchor|d30e91-FrontMatterH1}}== NIST Technical Series Policies ==

[https://doi.org/10.6028/NIST-TECHPUBS.CROSSMARK-POLICY Copyright, Use, and Licensing Statements]

[https://www.nist.gov/document/publication-identifier-syntax-nist-technical-series-publications NIST Technical Series Publication Identifier Syntax]

{{anchor|d30e101-FrontMatterH1}}== Publication History ==

Approved by the NIST Editorial Review Board on 2024-04-23

Supersedes NIST Special Publication 800-171A (June 2018) https://doi.org/10.6028/NIST.SP.800-171A

{{anchor|d30e110-FrontMatterH1}}== How to Cite this NIST Technical Series Publication ==

Ross R, Pillitteri V (2024) Assessing Security Requirements for Controlled Unclassified Information and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-171Ar3. https://doi.org/10.6028/NIST.SP.800-171Ar3

{{anchor|d30e117-FrontMatterH1}}== Author ORCID iDs ==

Ron Ross: 0000-0002-1099-9757

Victoria Pillitteri: 0000-0002-7446-7506

{{anchor|d30e124-FrontMatterH1}}== Submit Comments ==

[email protected]

National Institute of Standards and Technology

Attn: Computer Security Division, Information Technology Laboratory

100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930

{{anchor|d30e134-FrontMatterH1}}== Additional Information ==

Additional information about this publication is available at https://csrc.nist.gov/pubs/sp/800/171/a/r3/final, including related content, potential updates, and document history.

'''All comments are subject to release under the Freedom of Information Act (FOIA).'''

{{anchor|d30e145-FrontMatterH1}}== Reports on Computer Systems Technology ==

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.

{{anchor|d30e149-FrontMatterH1}}== Audience ==

This publication serves a diverse group of individuals and organizations in the public and private sectors, including individuals with:

* System development life cycle responsibilities (e.g., program managers, mission/business owners, information owners/stewards, system designers and developers, system/security engineers, systems integrators)
* Acquisition or procurement responsibilities (e.g., contracting officers)
* System, security, or risk management and oversight responsibilities (e.g., authorizing officials, chief information officers, chief information security officers, system owners, information security managers)
* Security assessment and monitoring responsibilities (e.g., auditors, system evaluators, assessors, independent verifiers/validators, analysts)

The above roles and responsibilities can be viewed from two perspectives:

* ''Federal perspective'': The entity establishing and conveying security assessment requirements in contractual vehicles or other types of agreements
* ''Nonfederal perspective'': The entity responding to and complying with the security assessment requirements set forth in contracts or agreements

{{anchor|d30e186-FrontMatterH1}}== Patent Disclosure Notice ==

NOTICE: ITL has requested that holders of patent claims whose use may be required for compliance with the guidance or requirements of this publication disclose such patent claims to ITL. However, holders of patents are not obligated to respond to ITL calls for patents and ITL has not undertaken a patent search in order to identify which, if any, patents may apply to this publication.

As of the date of publication and following call(s) for the identification of patent claims whose use may be required for compliance with the guidance or requirements of this publication, no such patent claims have been identified to ITL.

No representation is made or implied by ITL that licenses are not required to avoid patent infringement in the use of this publication.

{{anchor|d30e194-Acknowledgement_Head}}== Acknowledgments ==

The authors gratefully acknowledge and appreciate the significant contributions from individuals and organizations in the public and private sectors whose constructive comments improved the overall quality, thoroughness, and usefulness of this publication. The authors also wish to thank the NIST technical editing and production staff – Jim Foti, Jeff Brewer, Eduardo Takamura, Isabel Van Wyk, Cristina Ritfeld, Derek Sappington, and Chris Enloe – for their outstanding support in preparing this document for publication.

{{anchor|d30e198-FrontMatterH1}}== Historical Contributions ==

The authors wish to acknowledge the following individuals for their historic contributions to this publication: Jon Boyens, Devin Casey, Ned Goren, Gary Guissanie, Jody Jacobs, Jeff Marron, Vicki Michetti, Mark Riddle, Mary Thomas, Gary Stoneburner, Patricia Toth, and Patrick Viscuso.

{{anchor|d30e207-Head1}}{{anchor|sec-sec_1}}== 1 Introduction ==

The security assessment process gathers information and produces evidence to determine the effectiveness of security requirements by:

* Identifying potential problems or shortfalls in security and risk management programs
* Identifying security weaknesses and deficiencies in systems and the environments in which those systems operate
* Prioritizing risk mitigation decisions and activities
* Confirming that identified security weaknesses and deficiencies in the system and environment of operation have been addressed
* Supporting continuous monitoring activities and providing information security situational awareness

{{anchor|d30e233-Head2}}{{anchor|sec-sec_1.1}}== 1.1 Purpose and Applicability ==

The purpose of this publication is to provide procedures for assessing the security requirements in NIST Special Publication (SP) 800-171, ''Protecting Controlled Unclassified Information (CUI) in Nonfederal Systems and Organizations'' [[[#bibr-ref_3|3]]]. Organizations can use the assessment procedures to generate evidence that the security requirements have been satisfied. The scope of the security assessments conducted using the procedures described in this publication is guided and informed by the system security plans for systems that process, store, or transmit CUI. The assessment procedures offer the flexibility to customize assessments based on organizational policies and requirements, known threat and vulnerability information, system and platform dependencies, operational considerations, and tolerance for risk.{{anchor|footnote-1-backlink}}[[#footnote-1|1]]

{{anchor|d30e257-Head2}}{{anchor|sec-sec_1.2}}== 1.2 Organization of This Publication ==

The remainder of this special publication is organized as follows:

* [[#sec-sec_2|Section 2]] describes the fundamental concepts associated with assessments of security requirements, including assessment procedures, methods, objects, and assurance cases that can be created using the evidence produced during assessments.
* [[#sec-sec_3|Section 3]] provides assessment procedures for the security requirements in SP 800-171, including assessment objectives and potential assessment methods and objects for each procedure.

The following sections provide additional information to support the protection of CUI:

* References
* Appendix A: Acronyms
* Appendix B: Glossary
* Appendix C: Security Requirement Assessments
* Appendix D: Organization-Defined Parameters
* Appendix E: Change Log

{{anchor|box_a}}

<blockquote>
The contents of this publication can be used for many different assessment-related purposes to determine organizational compliance with the security requirements. The broad range of potential assessment methods and objects listed in this publication does not necessarily reflect and should not be directly associated with actual compliance or noncompliance. Rather, the selection of specific assessment methods and objects from the list provided can help generate a picture of overall compliance with the security requirements. There is no expectation about the number of methods or objects needed to determine compliance with the security requirements. Moreover, the entire list of potential assessment objects should not be viewed as required artifacts needed to determine compliance. Organizations have the flexibility to determine the specific methods and objects sufficient to obtain the needed evidence to support any claims of compliance.
</blockquote>

{{anchor|d30e306-Head1}}{{anchor|sec-sec_2}}== 2 The Fundamentals ==

The process used by organizations and assessors to assess the security requirements in SP 800-171 [[[#bibr-ref_3|3]]] includes (1) preparing for the assessment, (2) developing a security assessment plan, (3) conducting the assessment, and (4) documenting, analyzing, and reporting the assessment results.{{anchor|footnote-2-backlink}}[[#footnote-2|2]] The remainder of this section describes the structure and content of the procedures used to assess the security requirements and the importance of assurance cases in providing the evidence necessary to determine compliance with the requirements.

{{anchor|d30e324-Head2}}{{anchor|sec-sec_2.1}}== 2.1 Assessment Procedures ==

The security requirements in SP 800-171 are organized into 17 families, as illustrated in [[#table-tab_1|Table 1]]. The assessment procedures in Sec. 3 are grouped by similar family designations to ensure the completeness and consistency of assessments. The procedures have been derived from the assessment procedures in SP 800-53A [[[#bibr-ref_5|5]]].

'''{{anchor|d30e338}}Table 1. Security Requirement Families'''

{| class="wikitable"
|-
! Access Control !! Maintenance !! Security Assessment and Monitoring
|-
| Awareness and Training || Media Protection || System and Communications Protection
|-
| Audit and Accountability || Personnel Security || System and Information Integrity
|-
| Configuration Management || Physical Protection || Planning
|-
| Identification and Authentication || Risk Assessment || System and Services Acquisition
|-
| Incident Response || || Supply Chain Risk Management
|}

An assessment procedure consists of an assessment ''objective'' and a set of potential assessment ''methods'' and ''objects'' that can be used to conduct the assessment. Each potential assessment objective includes a determination statement related to the security requirement. If there is an organization-defined parameter (ODP) in the security requirement, then the assessment objective begins with a determination statement related to the definition of the ODP. The determination statements are linked to the content of the security requirements to help ensure traceability of the assessment results to the requirements.

Assessment objects identify the specific items being assessed and can include specifications, mechanisms, activities, and individuals. Specifications are the documented artifacts{{anchor|footnote-3-backlink}}[[#footnote-3|3]] (e.g., plans, policies, procedures, requirements, functional and assurance specifications, design documentation, and architectures) associated with a system. Mechanisms are the hardware, software, and firmware safeguards implemented within a system. Activities are the protection-related actions supporting a system that involve people (e.g., conducting system backup operations, exercising an incident response plan, and monitoring network traffic). Individuals are the people applying the specifications, mechanisms, or activities described above.

Assessment methods define the nature and extent of the assessor’s actions and are used to facilitate understanding, achieve clarification, or obtain evidence. The assessment methods include ''examine'', ''interview'', and ''test''. The examine method is the process of reviewing, studying, inspecting, or analyzing assessment objects. The interview method is the process of holding discussions with individuals or groups about assessment objects. The test method is the process of exercising assessment objects (i.e., activities, mechanisms) under specified conditions to compare actual with expected behavior. Assessment methods include attributes of ''depth'' and ''coverage'', which define the rigor, scope, and level of effort for the assessment as well as the degree of assurance that the security requirements have been satisfied. See SP 800-53A, [[#sec-sec_C|Appendix C]], ''Assessment Method Descriptions'' [[[#bibr-ref_5|5]]].

The structure and content of an assessment procedure are provided in the example below:

''[Figure: Security Requirement Name]''

* '''03.01.06 Least Privilege – Privileged Accounts'''

''[Figure: Multi-Part Determination Statement and ODP for Security Requirement]''

* '''ASSESSMENT OBJECTIVE'''
* ''Determine if:''
* '''A.03.01.06.ODP[01]: '''<nowiki/>'''''personnel or roles to which privileged accounts on the system are to be restricted are defined'''''<nowiki/>'''.'''
* '''A.03.01.06.a:''' privileged accounts on the system are restricted to '''''<A.03.01.06.ODP[01]: personnel or roles>'''''.
* '''A.03.01.06.b:''' users (or roles) with privileged accounts are required to use non-privileged accounts when accessing non-security functions or non-security information.
* '''ASSESSMENT METHODS AND OBJECTS'''
* '''Examine'''
* [SELECT FROM: access control policy and procedures; procedures for least privilege; list of system-generated privileged accounts; list of system administration personnel; system audit records; system configuration settings; system security plan; list of system-generated security functions or security-relevant information assigned to system accounts or roles; other relevant documents or records]
* '''Interview'''
* [SELECT FROM: personnel with responsibilities for defining least privileges; personnel with information security responsibilities; system administrators]
* '''Test'''
* [SELECT FROM: mechanisms for implementing least privilege functions]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-06 AC-06(02)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-06 AC-06(05)]

Determination statements have alphanumeric identifiers. Each determination statement begins with the letter “'''A'''” to indicate that it is part of an assessment procedure. The next sequence of numbers or letters (e.g., [[#A.03.01.01.e|03.01.01.e]] or [[#A.03.01.01.f.02|03.01.01.f.02]]) indicates the security requirement identifier from NIST SP 800-171 (and the specific control item if it is a multi-part requirement) that is the target of the assessment. Organization-defined parameters are indicated by the letters “'''ODP'''.” If there are multiple ODPs in the determination statement, the ODP number is indicated in a square bracket (e.g., [[#A.03.01.08.ODP[01]|A.03.01.08.ODP[01]]]). Square brackets are also used to denote when an assessment procedure further decomposes a requirement into more granular determination statements (e.g., [[#A.03.01.12.a[01]|A.03.01.12.a[01]]], [[#A.03.01.12.a[02]|A.03.01.12.a[02]]], [[#A.03.01.12.a[03]|A.03.01.12.a[03]]]).

The application of an assessment procedure to a security requirement produces assessment results or ''findings''. The findings are compiled and used as evidence to determine whether the security requirement has been ''satisfied'' or ''other than satisfied''. A finding of satisfied indicates that the assessment objective has been met, producing a fully acceptable result. A finding of other than satisfied indicates that there are potential anomalies that may need to be addressed by the organization. A finding of other than satisfied may also indicate that the assessor was unable to obtain sufficient information to make the determination called for in the determination statement.

{{anchor|d30e589-Head2}}{{anchor|sec-sec_2.2}}== 2.2 Assurance Cases ==

Building an effective assurance case to determine compliance with security requirements involves compiling evidence from a variety of sources and conducting different types of activities during an assessment. An ''assurance case'' is a body of evidence organized into an argument demonstrating that some claim about a system is true. For security assessments conducted using the procedures in this publication, that claim is “compliance” with the security requirements in SP 800-171. Assessors obtain evidence during security assessments to allow designated officials{{anchor|footnote-4-backlink}}[[#footnote-4|4]] to make objective determinations about compliance with the security requirements. The evidence needed to make such determinations can be obtained from various sources, including independent, third-party assessments or other types of assessments, depending on the needs of the organization establishing the requirements and the organization conducting the assessments.

For example, many technical security requirements are satisfied by security capabilities that are built into commercial information technology products and systems. Product assessments are typically conducted by independent, third-party testing organizations.{{anchor|footnote-5-backlink}}[[#footnote-5|5]] These assessments examine the security functions of products and established configuration settings. Assessments can also be conducted to demonstrate compliance with industry, national, or international security standards as well as developer and vendor claims. Since many information technology products are assessed by commercial testing organizations and then subsequently deployed in hundreds of thousands of systems, these types of assessments can be carried out at a greater level of depth and provide deeper insights into the security capabilities of the products.

The evidence needed to determine compliance with the security requirements is obtained by assessing the implementation of the safeguards and countermeasures selected to satisfy the requirements. Assessors can build on previously developed materials that started with the specification of the information security needs of the organization and were further improved during the design, development, and implementation of the system. These materials provide the initial evidence for an assurance case.

Assessments can be conducted by system developers, system integrators, auditors, system owners, or the security staffs of organizations. The assessors or assessment teams bring available information about the system together, such as the results of component product assessments. The assessors can conduct additional system-level assessments using the assessment methods and procedures contained in this publication and the implementation information provided by the nonfederal organization in its system security plan. Assessments can be used to compile and evaluate the evidence needed by organizations to help determine the effectiveness of the safeguards implemented to protect CUI, the actions needed to mitigate security risks to the organization, and compliance with the security requirements.

{{anchor|box_b}}

<blockquote>
The assessment procedures in this publication are based on and sourced to the assessment procedures in SP 800-53A [[[#bibr-ref_5|5]]]. For additional information and guidance on preparing for security assessments, developing assessment plans, conducting assessments, and analyzing assessment report results, consult SP 800-53A [[[#bibr-ref_5|5]]].
</blockquote>

{{anchor|d30e634-Head1}}{{anchor|sec-sec_3}}== 3 The Procedures ==

This section provides assessment procedures for the security requirements defined in NIST SP 800-171 [[[#bibr-ref_3|3]]]. Organizations that conduct security requirement assessments can develop their security assessment plans by using the information provided in the assessment procedures and selecting the specific assessment methods and objects that meet the organization’s needs. Organizations also have flexibility in defining the level of rigor and detail associated with the assessment based on the assurance requirements of the organization.

{{anchor|d30e644-Head2}}{{anchor|sec-sec_3.1}}== 3.1 [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC Access Control] ==

{{anchor|d30e649-Head3}}{{anchor|sec-sec_03.01.01}}=== 03.01.01 Account Management ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.01.01.ODP[01]}}A.03.01.01.ODP[01]: '''<nowiki/>'''''the time period for account inactivity before disabling is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.01.01.ODP[02]}}A.03.01.01.ODP[02]: '''<nowiki/>'''''the time period within which to notify account managers and designated personnel or roles when accounts are no longer required is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.01.01.ODP[03]}}A.03.01.01.ODP[03]: '''<nowiki/>'''''the time period within which to notify account managers and designated personnel or roles when users are terminated or transferred is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.01.01.ODP[04]}}A.03.01.01.ODP[04]: '''<nowiki/>'''''the time period within which to notify account managers and designated personnel or roles when system usage or the need-to-know changes for an individual is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.01.01.ODP[05]}}A.03.01.01.ODP[05]: '''<nowiki/>'''''the time period of expected inactivity requiring users to log out of the system is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.01.01.ODP[06]}}A.03.01.01.ODP[06]: '''<nowiki/>'''''circumstances requiring users to log out of the system are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.01.01.a[01]}}A.03.01.01.a[01]:''' system account types allowed are defined.
* '''{{anchor|A.03.01.01.a[02]}}A.03.01.01.a[02]:''' system account types prohibited are defined.
* '''{{anchor|A.03.01.01.b[01]}}A.03.01.01.b[01]:''' system accounts are created in accordance with organizational policy, procedures, prerequisites, and criteria.
* '''{{anchor|A.03.01.01.b[02]}}A.03.01.01.b[02]:''' system accounts are enabled in accordance with organizational policy, procedures, prerequisites, and criteria.
* '''{{anchor|A.03.01.01.b[03]}}A.03.01.01.b[03]:''' system accounts are modified in accordance with organizational policy, procedures, prerequisites, and criteria.
* '''{{anchor|A.03.01.01.b[04]}}A.03.01.01.b[04]:''' system accounts are disabled in accordance with organizational policy, procedures, prerequisites, and criteria.
* '''{{anchor|A.03.01.01.b[05]}}A.03.01.01.b[05]:''' system accounts are removed in accordance with organizational policy, procedures, prerequisites, and criteria.
* '''{{anchor|A.03.01.01.c.01}}A.03.01.01.c.01:''' authorized users of the system are specified.
* '''{{anchor|A.03.01.01.c.02}}A.03.01.01.c.02:''' group and role memberships are specified.
* '''{{anchor|A.03.01.01.c.03}}A.03.01.01.c.03:''' access authorizations (i.e., privileges) for each account are specified.
* '''{{anchor|A.03.01.01.d.01}}A.03.01.01.d.01:''' access to the system is authorized based on a valid access authorization.
* '''{{anchor|A.03.01.01.d.02}}A.03.01.01.d.02:''' access to the system is authorized based on intended system usage.
* '''{{anchor|A.03.01.01.e}}A.03.01.01.e:''' the use of system accounts is monitored.
* '''{{anchor|A.03.01.01.f.01}}A.03.01.01.f.01:''' system accounts are disabled when the accounts have expired.
* '''{{anchor|A.03.01.01.f.02}}A.03.01.01.f.02:''' system accounts are disabled when the accounts have been inactive for '''''<A.03.01.01.ODP[01]: time period>'''''.
* '''{{anchor|A.03.01.01.f.03}}A.03.01.01.f.03:''' system accounts are disabled when the accounts are no longer associated with a user or individual.
* '''{{anchor|A.03.01.01.f.04}}A.03.01.01.f.04:''' system accounts are disabled when the accounts violate organizational policy.
* '''{{anchor|A.03.01.01.f.05}}A.03.01.01.f.05:''' system accounts are disabled when significant risks associated with individuals are discovered.
* '''{{anchor|A.03.01.01.g.01}}A.03.01.01.g.01:''' account managers and designated personnel or roles are notified within '''''<A.03.01.01.ODP[02]: time period>''''' when accounts are no longer required.
* '''{{anchor|A.03.01.01.g.02}}A.03.01.01.g.02:''' account managers and designated personnel or roles are notified within '''''<A.03.01.01.ODP[03]: time period>''''' when users are terminated or transferred.
* '''{{anchor|A.03.01.01.g.03}}A.03.01.01.g.03:''' account managers and designated personnel or roles are notified within '''''<A.03.01.01.ODP[04]: time period>''''' when system usage or the need-to-know changes for an individual.
* '''{{anchor|A.03.01.01.h}}A.03.01.01.h:''' users are required to log out of the system after '''''<A.03.01.01.ODP[05]: time period>''''' of expected inactivity or when the following circumstances occur: '''''<A.03.01.01.ODP[06]: circumstances>'''''.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: access control policy and procedures; personnel termination or transfer policies and procedures; procedures for account management; list of active system accounts and the name of the individual associated with each account; system design documentation; list of conditions for group and role membership; system configuration settings; notifications of recent transfers, separations, or terminations of employees; list of recently disabled system accounts and the name of the individual associated with each account; list of user activities that pose significant organizational risks; access authorization records; account management compliance reviews; system monitoring and audit records; system security plan; system-generated list of accounts removed; system-generated list of emergency accounts disabled; system-generated list of disabled accounts; other relevant documents and records]

===== Interview =====

[SELECT FROM: personnel with account management responsibilities; system administrators; personnel with information security responsibilities; system developers]

===== Test =====

[SELECT FROM: processes for account management on the system; mechanisms for implementing account management]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-02 AC-02], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-02 AC-02(03)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-02 AC-02(05)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-02 AC-02(13)]

{{anchor|d30e878-Head3}}{{anchor|sec-sec_03.01.02}}=== 03.01.02 Access Enforcement ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''A.03.01.02[01]:''' approved authorizations for logical access to CUI are enforced in accordance with applicable access control policies.
* '''A.03.01.02[02]:''' approved authorizations for logical access to system resources are enforced in accordance with applicable access control policies.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: access control policy and procedures; procedures for access enforcement; system design documentation; system configuration settings; list of approved authorizations (i.e., user privileges); system audit records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with access enforcement responsibilities; system administrators; personnel with information security responsibilities; system developers]

===== Test =====

[SELECT FROM: mechanisms for implementing the access control policy]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-03 AC-03]

{{anchor|d30e918-Head3}}{{anchor|sec-sec_03.01.03}}=== 03.01.03 Information Flow Enforcement ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''A.03.01.03[01]:''' approved authorizations are enforced for controlling the flow of CUI within the system.
* '''A.03.01.03[02]:''' approved authorizations are enforced for controlling the flow of CUI between connected systems.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: access control policy and procedures; information flow control policies; procedures for information flow enforcement; security architecture and design documentation; system configuration settings; system baseline configuration; system audit records; list of information flow authorizations; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: system administrators; personnel with security architecture responsibilities; personnel with information security responsibilities; system developers]

===== Test =====

[SELECT FROM: mechanisms for implementing the information flow enforcement policy]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-04 AC-04]

{{anchor|d30e958-Head3}}{{anchor|sec-sec_03.01.04}}=== 03.01.04 Separation of Duties ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.01.04.a}}A.03.01.04.a:''' duties of individuals requiring separation are identified.
* '''{{anchor|A.03.01.04.b}}A.03.01.04.b:''' system access authorizations to support separation of duties are defined.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: access control policy and procedures; procedures for the separation of duties and the division of responsibilities; system configuration settings; system audit records; system access authorizations; list of divisions of responsibility and separation of duties; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with responsibilities for defining the separation of duties and the division of responsibilities; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: mechanisms for implementing the separation of duties policy]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-05 AC-05]

{{anchor|d30e1000-Head3}}{{anchor|sec-sec_03.01.05}}=== 03.01.05 Least Privilege ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.01.05.ODP[01]}}A.03.01.05.ODP[01]: '''<nowiki/>'''''security functions for authorized access are defined.'''''
* '''{{anchor|A.03.01.05.ODP[02]}}A.03.01.05.ODP[02]: '''<nowiki/>'''''security-relevant information for authorized access is defined.'''''
* '''{{anchor|A.03.01.05.ODP[03]}}A.03.01.05.ODP[03]: '''<nowiki/>'''''the frequency at which to review the privileges assigned to roles or classes of users is defined.'''''
* '''{{anchor|A.03.01.05.a}}A.03.01.05.a:''' system access for users (or processes acting on behalf of users) is authorized only when necessary to accomplish assigned organizational tasks.
* '''{{anchor|A.03.01.05.b[01]}}A.03.01.05.b[01]:''' access to '''''<A.03.01.05.ODP[01]: security functions>''''' is authorized.
* '''{{anchor|A.03.01.05.b[02]}}A.03.01.05.b[02]:''' access to '''''<A.03.01.05.ODP[02]: security-relevant information>''''' is authorized.
* '''{{anchor|A.03.01.05.c}}A.03.01.05.c:''' the privileges assigned to roles or classes of users are reviewed '''''<A.03.01.05.ODP[03]: frequency>''''' to validate the need for such privileges.
* '''{{anchor|A.03.01.05.d}}A.03.01.05.d:''' privileges are reassigned or removed, as necessary.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: access control policy and procedures; procedures for least privilege; list of assigned access authorizations (i.e., privileges); system configuration settings; system audit records; list of security functions (implemented in hardware, software, and firmware); security-relevant information for which access must be explicitly authorized; list of system-generated roles or classes of users and assigned privileges; validation reviews of privileges assigned to roles or classes of users; records of privilege removals or reassignments for roles or classes of users; system security plan; system design documentation; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with responsibilities for defining least privileges; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: mechanisms for implementing least privilege functions; mechanisms for implementing reviews of user privileges]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-06 AC-06], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-06 AC-06(01)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-06 AC-06(07)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AU-09 AU-09(04)]

{{anchor|d30e1100-Head3}}{{anchor|sec-sec_03.01.06}}=== 03.01.06 Least Privilege – Privileged Accounts ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.01.06.ODP[01]}}A.03.01.06.ODP[01]: '''<nowiki/>'''''personnel or roles to which privileged accounts on the system are to be restricted are defined.'''''
* '''{{anchor|A.03.01.06.a}}A.03.01.06.a:''' privileged accounts on the system are restricted to '''''<A.03.01.06.ODP[01]: personnel or roles>'''''.
* '''{{anchor|A.03.01.06.b}}A.03.01.06.b:''' users (or roles) with privileged accounts are required to use non-privileged accounts when accessing non-security functions or non-security information.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: access control policy and procedures; procedures for least privilege; list of system-generated privileged accounts; list of system administration personnel; system audit records; system configuration settings; system security plan; list of system-generated security functions or security-relevant information assigned to system accounts or roles; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with responsibilities for defining least privileges; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: mechanisms for implementing least privilege functions]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-06 AC-06(02)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-06 AC-06(05)]

{{anchor|d30e1157-Head3}}{{anchor|sec-sec_03.01.07}}=== 03.01.07 Least Privilege – Privileged Functions ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.01.07.a}}A.03.01.07.a:''' non-privileged users are prevented from executing privileged functions.
* '''{{anchor|A.03.01.07.b}}A.03.01.07.b:''' the execution of privileged functions is logged.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: access control policy and procedures; procedures for least privilege; system design documentation; system configuration settings; system audit records; list of audited events; list of privileged functions to be audited and associated user account assignments; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with responsibilities for reviewing least privileges; personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: mechanisms for auditing the execution of least privilege functions; mechanisms for implementing least privilege functions for non-privileged users]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-06 AC-06(09)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-06 AC-06(10)]

{{anchor|d30e1203-Head3}}{{anchor|sec-sec_03.01.08}}=== 03.01.08 Unsuccessful Logon Attempts ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.01.08.ODP[01]}}A.03.01.08.ODP[01]: '''<nowiki/>'''''the number of consecutive invalid logon attempts by a user allowed during a time period is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.01.08.ODP[02]}}A.03.01.08.ODP[02]: '''<nowiki/>'''''the time period to which the number of consecutive invalid logon attempts by a user is limited is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.01.08.ODP[03]}}A.03.01.08.ODP[03]: '''<nowiki/>'''''one or more of the following PARAMETER VALUES are selected: {the account or node is locked automatically for <A.03.01.08.ODP[04]: time period>; the account or node is locked automatically until released by an administrator; the next logon prompt is delayed automatically; the system administrator is notified automatically; other action is taken automatically}.'''''
* '''{{anchor|A.03.01.08.ODP[04]}}A.03.01.08.ODP[04]: '''<nowiki/>'''''the time period for an account or node to be locked is defined (if selected)'''''<nowiki/>'''.'''
* '''{{anchor|A.03.01.08.a}}A.03.01.08.a:''' a limit of '''''<A.03.01.08.ODP[01]: number>''''' consecutive invalid logon attempts by a user during '''''<A.03.01.08.ODP[02]: time period>''''' is enforced.
* '''{{anchor|A.03.01.08.b}}A.03.01.08.b: '''<nowiki/>'''''<A.03.01.08.ODP[03]: SELECTED PARAMETER VALUES>''''' when the maximum number of unsuccessful attempts is exceeded.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: access control policy and procedures; procedures for unsuccessful logon attempts; system design documentation; system audit records; system configuration settings; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: mechanisms for implementing the access control policy for unsuccessful logon attempts]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-07 AC-07]

{{anchor|d30e1289-Head3}}{{anchor|sec-sec_03.01.09}}=== 03.01.09 System Use Notification ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''A.03.01.09:''' a system use notification message with privacy and security notices consistent with applicable CUI rules is displayed before granting access to the system.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: access control policy and procedures; privacy and security policies, procedures for system use notification; documented approval of system use notification messages; system audit records; user acknowledgements of system use notification messages; system design documentation; system configuration settings; system use notification messages; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with information security responsibilities; legal counsel; system developers; system administrators]

===== Test =====

[SELECT FROM: mechanisms for implementing system use notifications]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-08 AC-08]

{{anchor|d30e1325-Head3}}{{anchor|sec-sec_03.01.10}}=== 03.01.10 Device Lock ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.01.10.ODP[01]}}A.03.01.10.ODP[01]: '''<nowiki/>'''''one or more of the following PARAMETER VALUES are selected: {a device lock is initiated after <A.03.01.10.ODP[02]: time period> of inactivity; the user is required to initiate a device lock before leaving the system unattended}'''''<nowiki/>'''.'''
* '''{{anchor|A.03.01.10.ODP[02]}}A.03.01.10.ODP[02]: '''<nowiki/>'''''the time period of inactivity after which a device lock is initiated is defined (if selected)'''''<nowiki/>'''.'''
* '''{{anchor|A.03.01.10.a}}A.03.01.10.a:''' access to the system is prevented by '''''<A.03.01.10.ODP[01]: SELECTED PARAMETER VALUES>'''''.
* '''{{anchor|A.03.01.10.b}}A.03.01.10.b:''' the device lock is retained until the user reestablishes access using established identification and authentication procedures.
* '''{{anchor|A.03.01.10.c}}A.03.01.10.c:''' information previously visible on the display is concealed via device lock with a publicly viewable image.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: access control policy and procedures; procedures for session lock and identification and authentication; system design documentation; system configuration settings; display screen with session lock activated; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: mechanisms for implementing the access control policy for session lock; session lock mechanisms]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-11 AC-11], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-11 AC-11(01)]

{{anchor|d30e1397-Head3}}{{anchor|sec-sec_03.01.11}}=== 03.01.11 Session Termination ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.01.11.ODP[01]}}A.03.01.11.ODP[01]: '''<nowiki/>'''''conditions or trigger events that require session disconnect are defined'''''<nowiki/>'''.'''
* '''A.03.01.11:''' a user session is terminated automatically after '''''<A.03.01.11.ODP[01]: conditions or trigger events>'''''.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: access control policy and procedures; procedures for session termination; system design documentation; system configuration settings; list of conditions or trigger events requiring session disconnect; system audit records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: automated mechanisms for implementing user session termination]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-12 AC-12]

{{anchor|d30e1446-Head3}}{{anchor|sec-sec_03.01.12}}=== 03.01.12 Remote Access ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.01.12.a[01]}}A.03.01.12.a[01]:''' types of allowable remote system access are defined.
* '''{{anchor|A.03.01.12.a[02]}}A.03.01.12.a[02]:''' usage restrictions are established for each type of allowable remote system access.
* '''{{anchor|A.03.01.12.a[03]}}A.03.01.12.a[03]:''' configuration requirements are established for each type of allowable remote system access.
* '''{{anchor|A.03.01.12.a[04]}}A.03.01.12.a[04]:''' connection requirements are established for each type of allowable remote system access.
* '''{{anchor|A.03.01.12.b}}A.03.01.12.b:''' each type of remote system access is authorized prior to establishing such connections.
* '''{{anchor|A.03.01.12.c[01]}}A.03.01.12.c[01]:''' remote access to the system is routed through authorized access control points.
* '''{{anchor|A.03.01.12.c[02]}}A.03.01.12.c[02]:''' remote access to the system is routed through managed access control points.
* '''{{anchor|A.03.01.12.d[1]}}A.03.01.12.d[1]:''' remote execution of privileged commands is authorized.
* '''{{anchor|A.03.01.12.d[2]}}A.03.01.12.d[2]:''' remote access to security-relevant information is authorized.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: access control policy and procedures; procedures for remote system access; remote system access configuration and connection requirements; configuration management plan; system configuration settings; remote access authorizations; system audit records; system design documentation; procedures for remote access to the system; system monitoring records; list of managed network access control points; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with responsibilities for managing remote access connections; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: mechanisms for monitoring and controlling remote access methods; mechanisms for routing remote accesses through managed access control points; remote access management capability for the system]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-17 AC-17], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-17 AC-17(03)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-17 AC-17(04)]

{{anchor|d30e1536-Head3}}{{anchor|sec-sec_03.01.13}}=== 03.01.13 Withdrawn ===

Addressed by [[#sec-sec_03.13.08|03.13.08]].

{{anchor|d30e1547-Head3}}{{anchor|sec-sec_03.01.14}}=== 03.01.14 Withdrawn ===

Incorporated into [[#sec-sec_03.01.12|03.01.12]].

{{anchor|d30e1557-Head3}}{{anchor|sec-sec_03.01.15}}=== 03.01.15 Withdrawn ===

Incorporated into [[#sec-sec_03.01.12|03.01.12]].

{{anchor|d30e1567-Head3}}{{anchor|sec-sec_03.01.16}}=== 03.01.16 Wireless Access ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.01.16.a[01]}}A.03.01.16.a[01]:''' each type of wireless access to the system is defined.
* '''{{anchor|A.03.01.16.a[02]}}A.03.01.16.a[02]:''' usage restrictions are established for each type of wireless access to the system.
* '''{{anchor|A.03.01.16.a[03]}}A.03.01.16.a[03]:''' configuration requirements are established for each type of wireless access to the system.
* '''{{anchor|A.03.01.16.a[04]}}A.03.01.16.a[04]:''' connection requirements are established for each type of wireless access to the system.
* '''{{anchor|A.03.01.16.b}}A.03.01.16.b:''' each type of wireless access to the system is authorized prior to establishing such connections.
* '''{{anchor|A.03.01.16.c}}A.03.01.16.c:''' wireless networking capabilities not intended for use are disabled prior to issuance and deployment.
* '''{{anchor|A.03.01.16.d[01]}}A.03.01.16.d[01]:''' wireless access to the system is protected using authentication.
* '''{{anchor|A.03.01.16.d[02]}}A.03.01.16.d[02]:''' wireless access to the system is protected using encryption.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: access control policy and procedures; procedures for wireless system access; wireless system access configuration and connection requirements; configuration management plan; system configuration settings; wireless access authorizations; system audit records; system design documentation; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with responsibilities for managing wireless access connections; personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: wireless access management capability for the system; mechanisms for implementing wireless access protections to the system; mechanisms for managing the disabling of wireless networking capabilities]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-18 AC-18], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-18 AC-18(01)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-18 AC-18(03)]

{{anchor|d30e1653-Head3}}{{anchor|sec-sec_03.01.17}}=== 03.01.17 Withdrawn ===

Incorporated into [[#sec-sec_03.01.16|03.01.16]].

{{anchor|d30e1664-Head3}}{{anchor|sec-sec_03.01.18}}=== 03.01.18 Access Control for Mobile Devices ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.01.18.a[01]}}A.03.01.18.a[01]:''' usage restrictions are established for mobile devices.
* '''{{anchor|A.03.01.18.a[02]}}A.03.01.18.a[02]:''' configuration requirements are established for mobile devices.
* '''{{anchor|A.03.01.18.a[03]}}A.03.01.18.a[03]:''' connection requirements are established for mobile devices.
* '''{{anchor|A.03.01.18.b}}A.03.01.18.b:''' the connection of mobile devices to the system is authorized.
* '''{{anchor|A.03.01.18.c}}A.03.01.18.c:''' full-device or container-based encryption is implemented to protect the confidentiality of CUI on mobile devices.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: access control policy and procedures; procedures for mobile device access control; system design documentation; configuration management plan; system configuration settings; authorizations for mobile device connections to organizational systems; system audit records; encryption mechanisms and associated configuration documentation; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with access control responsibilities for mobile devices; personnel using mobile devices to access organizational systems; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: access control capability for mobile device connections to organizational systems; encryption mechanisms for protecting the confidentiality of CUI on mobile devices; configurations of mobile devices]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-19 AC-19], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-19 AC-19(05)]

{{anchor|d30e1731-Head3}}{{anchor|sec-sec_03.01.19}}=== 03.01.19 Withdrawn ===

Incorporated into [[#sec-sec_03.01.18|03.01.18]].

{{anchor|d30e1741-Head3}}{{anchor|sec-sec_03.01.20}}=== 03.01.20 Use of External Systems ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.01.20.ODP[01]}}A.03.01.20.ODP[01]: '''<nowiki/>'''''security requirements to be satisfied on external systems prior to allowing the use of or access to those systems by authorized individuals are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.01.20.a}}A.03.01.20.a: the''' use of external systems is prohibited unless the systems are specifically authorized.
* '''{{anchor|A.03.01.20.b}}A.03.01.20.b:''' the following security requirements to be satisfied on external systems prior to allowing the use of or access to those systems by authorized individuals are established: '''''<A.03.01.20.ODP[01]: security requirements>'''''.
* '''{{anchor|A.03.01.20.c.01}}A.03.01.20.c.01:''' authorized individuals are permitted to use external systems to access the organizational system or to process, store, or transmit CUI only after verifying that the security requirements on the external systems as specified in the organization’s system security plans have been satisfied.
* '''{{anchor|A.03.01.20.c.02}}A.03.01.20.c.02:''' authorized individuals are permitted to use external systems to access the organizational system or to process, store, or transmit CUI only after retaining approved system connection or processing agreements with the organizational entity hosting the external systems.
* '''{{anchor|A.03.01.20.d}}A.03.01.20.d:''' the use of organization-controlled portable storage devices by authorized individuals on external systems is restricted.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: access control policy and procedures; procedures for the use of external systems; terms and conditions for the use of external systems; external systems security requirements; list of types of applications accessible from external systems; system configuration settings; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with responsibilities for defining terms, conditions, and security requirements for the use of external systems; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: mechanisms for implementing or enforcing terms, conditions, and security requirements for the use of external systems]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-20 AC-20], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-20 AC-20(01)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-20 AC-20(02)]

{{anchor|d30e1823-Head3}}{{anchor|sec-sec_03.01.21}}=== 03.01.21 Withdrawn ===

Incorporated into [[#sec-sec_03.01.20|03.01.20]].

{{anchor|d30e1834-Head3}}{{anchor|sec-sec_03.01.22}}=== 03.01.22 Publicly Accessible Content ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.01.22.a}}A.03.01.22.a:''' authorized individuals are trained to ensure that publicly accessible information does not contain CUI.
* '''{{anchor|A.03.01.22.b[01]}}A.03.01.22.b[01]:''' the content on publicly accessible systems is reviewed for CUI.
* '''{{anchor|A.03.01.22.b[02]}}A.03.01.22.b[02]:''' CUI is removed from publicly accessible systems, if discovered.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: access control policy and procedures; procedures for publicly accessible content; list of users authorized to post publicly accessible content on organizational systems; training materials or records; records of publicly accessible information reviews; records of response to CUI discovered on public websites; system audit logs; security awareness training records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with responsibilities for managing publicly accessible information posted on organizational systems; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: mechanisms for implementing the management of publicly accessible content]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-22 AC-22]

{{anchor|d30e1886-Head2}}{{anchor|sec-sec_3.2}}== 3.2 [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AT Awareness and Training] ==

{{anchor|d30e1891-Head3}}{{anchor|sec-sec_03.02.01}}=== 03.02.01 Literacy Training and Awareness ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.02.01.ODP[01]}}A.03.02.01.ODP[01]: '''<nowiki/>'''''the frequency at which to provide security literacy training to system users after initial training is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.02.01.ODP[02]}}A.03.02.01.ODP[02]: '''<nowiki/>'''''events that require security literacy training for system users are defined.'''''
* '''{{anchor|A.03.02.01.ODP[03]}}A.03.02.01.ODP[03]: '''<nowiki/>'''''the frequency at which to update security literacy training content is defined.'''''
* '''{{anchor|A.03.02.01.ODP[04]}}A.03.02.01.ODP[04]: '''<nowiki/>'''''events that require security literacy training content updates are defined.'''''
* '''{{anchor|A.03.02.01.a.01[01]}}A.03.02.01.a.01[01]:''' security literacy training is provided to system users as part of initial training for new users.
* '''{{anchor|A.03.02.01.a.01[02]}}A.03.02.01.a.01[02]:''' security literacy training is provided to system users '''''<A.03.02.01.ODP[01]: frequency>''''' after initial training.
* '''{{anchor|A.03.02.01.a.02}}A.03.02.01.a.02:''' security literacy training is provided to system users when required by system changes or following '''''<A.03.02.01.ODP[02]: events>'''''.
* '''{{anchor|A.03.02.01.a.03[01]}}A.03.02.01.a.03[01]:''' security literacy training is provided to system users on recognizing indicators of insider threat.
* '''{{anchor|A.03.02.01.a.03[02]}}A.03.02.01.a.03[02]:''' security literacy training is provided to system users on reporting indicators of insider threat.
* '''{{anchor|A.03.02.01.a.03[03]}}A.03.02.01.a.03[03]:''' security literacy training is provided to system users on recognizing indicators of social engineering.
* '''{{anchor|A.03.02.01.a.03[04]}}A.03.02.01.a.03[04]:''' security literacy training is provided to system users on reporting indicators of social engineering.
* '''{{anchor|A.03.02.01.a.03[05]}}A.03.02.01.a.03[05]:''' security literacy training is provided to system users on recognizing indicators of social mining.
* '''{{anchor|A.03.02.01.a.03[06]}}A.03.02.01.a.03[06]:''' security literacy training is provided to system users on reporting indicators of social mining.
* '''{{anchor|A.03.02.01.b[01]}}A.03.02.01.b[01]:''' security literacy training content is updated '''''<A.03.02.01.ODP[03]: frequency>'''''.
* '''{{anchor|A.03.02.01.b[02]}}A.03.02.01.b[02]:''' security literacy training content is updated following '''''<A.03.02.01.ODP[04]: events>'''''.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: security literacy training and awareness policy and procedures; procedures for security literacy training and awareness implementation; codes of federal regulations; security literacy and awareness training curriculum; security literacy and awareness training materials; training records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with responsibilities for security literacy training and awareness; personnel comprising the general system user community; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: mechanisms for managing information security literacy training and awareness]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AT-02 AT-02], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AT-02 AT-02(02)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AT-02 AT-02(03)]

{{anchor|d30e2034-Head3}}{{anchor|sec-sec_03.02.02}}=== 03.02.02 Role-Based Training ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.02.02.ODP[01]}}A.03.02.02.ODP[01]: '''<nowiki/>'''''the frequency at which to provide role-based security training to assigned personnel after initial training is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.02.02.ODP[02]}}A.03.02.02.ODP[02]: '''<nowiki/>'''''events that require role-based security training are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.02.02.ODP[03]}}A.03.02.02.ODP[03]: '''<nowiki/>'''''the frequency at which to update role-based security training content is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.02.02.ODP[04]}}A.03.02.02.ODP[04]: '''<nowiki/>'''''events that require role-based security training content updates are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.02.02.a.01[01]}}A.03.02.02.a.01[01]:''' role-based security training is provided to organizational personnel before authorizing access to the system or CUI.
* '''{{anchor|A.03.02.02.a.01[02]}}A.03.02.02.a.01[02]:''' role-based security training is provided to organizational personnel before performing assigned duties.
* '''{{anchor|A.03.02.02.a.01[03]}}A.03.02.02.a.01[03]:''' role-based security training is provided to organizational personnel '''''<A.03.02.02.ODP[01]: frequency>''''' after initial training.
* '''{{anchor|A.03.02.02.a.02}}A.03.02.02.a.02:''' role-based security training is provided to organizational personnel when required by system changes or following '''''<A.03.02.02.ODP[02]: events>'''''.
* '''{{anchor|A.03.02.02.b[01]}}A.03.02.02.b[01]:''' role-based security training content is updated '''''<A.03.02.02.ODP[03]: frequency>'''''.
* '''{{anchor|A.03.02.02.b[02]}}A.03.02.02.b[02]:''' role-based security training content is updated following '''''<A.03.02.02.ODP[04]: events>'''''.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: security awareness and training policy and procedures; procedures for security training implementation; codes of federal regulations; security training curriculum; security training materials; training records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with responsibilities for role-based security training; personnel with assigned system security roles and responsibilities]

===== Test =====

[SELECT FROM: mechanisms for managing role-based security training and awareness]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AT-03 AT-03]

{{anchor|d30e2150-Head3}}{{anchor|sec-sec_03.02.03}}=== 03.02.03 Withdrawn ===

Incorporated into [[#sec-sec_03.02.01|03.02.01]].

{{anchor|d30e2161-Head2}}{{anchor|sec-sec_3.3}}== 3.3 [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU Audit and Accountability] ==

{{anchor|d30e2166-Head3}}{{anchor|sec-sec_03.03.01}}=== 03.03.01 Event Logging ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.03.01.ODP[01]}}A.03.03.01.ODP[01]: '''<nowiki/>'''''event types selected for logging within the system are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.03.01.ODP[02]}}A.03.03.01.ODP[02]: '''<nowiki/>'''''the frequency of event types selected for logging are reviewed and updated.'''''
* '''{{anchor|A.03.03.01.a}}A.03.03.01.a:''' the following event types are specified for logging within the system: '''''<A.03.03.01.ODP[01]: event types>'''''.
* '''{{anchor|A.03.03.01.b[01]}}A.03.03.01.b[01]:''' the event types selected for logging are reviewed '''''<A.03.03.01.ODP[02]: frequency>'''''.
* '''{{anchor|A.03.03.01.b[02]}}A.03.03.01.b[02]:''' the event types selected for logging are updated '''''<A.03.03.01.ODP[02]: frequency>'''''.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: audit and accountability policy and procedures; procedures for auditable events; system design documentation; system configuration settings; system audit records; system auditable events; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with audit and accountability responsibilities; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: mechanisms for implementing system auditing]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AU-02 AU-02]

{{anchor|d30e2243-Head3}}{{anchor|sec-sec_03.03.02}}=== 03.03.02 Audit Record Content ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.03.02.a.01}}A.03.03.02.a.01:''' audit records contain information that establishes what type of event occurred.
* '''{{anchor|A.03.03.02.a.02}}A.03.03.02.a.02:''' audit records contain information that establishes when the event occurred.
* '''{{anchor|A.03.03.02.a.03}}A.03.03.02.a.03:''' audit records contain information that establishes where the event occurred.
* '''{{anchor|A.03.03.02.a.04}}A.03.03.02.a.04:''' audit records contain information that establishes the source of the event.
* '''{{anchor|A.03.03.02.a.05}}A.03.03.02.a.05:''' audit records contain information that establishes the outcome of the event.
* '''{{anchor|A.03.03.02.a.06}}A.03.03.02.a.06:''' audit records contain information that establishes the identity of the individuals, subjects, objects, or entities associated with the event.
* '''{{anchor|A.03.03.02.b}}A.03.03.02.b:''' additional information for audit records is provided, as needed.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: audit and accountability policy and procedures; procedures for the content of audit records; list of organization-defined auditable events; system design documentation; system configuration settings; system audit records; system incident reports; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with audit and accountability responsibilities; personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: mechanisms for implementing system auditing of auditable events; system audit capability]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AU-03 AU-03], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AU-03 AU-03(01)]

{{anchor|d30e2320-Head3}}{{anchor|sec-sec_03.03.03}}=== 03.03.03 Audit Record Generation ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.03.03.a}}A.03.03.03.a:''' audit records for the selected event types and audit record content specified in [[#sec-sec_03.03.01|03.03.01]] and [[#sec-sec_03.03.02|03.03.02]] are generated.
* '''{{anchor|A.03.03.03.b}}A.03.03.03.b:''' audit records are retained for a time period consistent with the records retention policy.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: audit and accountability policy and procedures; procedures for audit record generation; system design documentation; list of auditable events; system audit records; audit record retention policy and procedures; organization-defined retention period for audit records; audit record archives; system configuration settings; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with audit record generation responsibilities; personnel with audit record retention responsibilities; personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: mechanisms for implementing the audit record generation capability]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AU-11 AU-11], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AU-12 AU-12]

{{anchor|d30e2377-Head3}}{{anchor|sec-sec_03.03.04}}=== 03.03.04 Response to Audit Logging Process Failures ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.03.04.ODP[01]}}A.03.03.04.ODP[01]: '''<nowiki/>'''''the time period for organizational personnel or roles receiving audit logging process failure alerts is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.03.04.ODP[02]}}A.03.03.04.ODP[02]: '''<nowiki/>'''''additional actions to be taken in the event of an audit logging process failure are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.03.04.a}}A.03.03.04.a:''' organizational personnel or roles are alerted in the event of an audit logging process failure within '''''<A.03.03.04.ODP[01]: time period>'''''.
* '''{{anchor|A.03.03.04.b}}A.03.03.04.b:''' the following additional actions are taken: '''''<A.03.03.04.ODP[02]: additional actions>'''''.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: audit and accountability policy and procedures; procedures for responding to audit processing failures; system design documentation; system configuration settings; list of personnel to be notified in case of an audit processing failure; system audit records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with audit and accountability responsibilities; personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: mechanisms for implementing system response to audit processing failures]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AU-05 AU-05]

{{anchor|d30e2449-Head3}}{{anchor|sec-sec_03.03.05}}=== 03.03.05 Audit Record Review, Analysis, and Reporting ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.03.05.ODP[01]}}A.03.03.05.ODP[01]: '''<nowiki/>'''''the frequency at which system audit records are reviewed and analyzed is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.03.05.a}}A.03.03.05.a:''' system audit records are reviewed and analyzed '''''<A.03.03.05.ODP[01]: frequency>''''' for indications and the potential impact of inappropriate or unusual activity.
* '''{{anchor|A.03.03.05.b}}A.03.03.05.b:''' findings are reported to organizational personnel or roles.
* '''{{anchor|A.03.03.05.c[01]}}A.03.03.05.c[01]:''' audit records across different repositories are analyzed to gain organization-wide situational awareness.
* '''{{anchor|A.03.03.05.c[02]}}A.03.03.05.c[02]:''' audit records across different repositories are correlated to gain organization-wide situational awareness.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: audit and accountability policy and procedures; procedures for audit record review, analysis, and reporting; reports of audit record findings; records of actions taken in response to reviews and analyses of audit records; system design documentation; system audit records across different repositories; system security plan; system configuration settings; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with audit record review, analysis, and reporting responsibilities; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: mechanisms for supporting the analysis and correlation of audit records]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AU-06 AU-06], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AU-06 AU-06(03)]

{{anchor|d30e2522-Head3}}{{anchor|sec-sec_03.03.06}}=== 03.03.06 Audit Record Reduction and Report Generation ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.03.06.a[01]}}A.03.03.06.a[01]:''' an audit record reduction and report generation capability that supports audit record review is implemented.
* '''{{anchor|A.03.03.06.a[02]}}A.03.03.06.a[02]:''' an audit record reduction and report generation capability that supports audit record analysis is implemented.
* '''{{anchor|A.03.03.06.a[03]}}A.03.03.06.a[03]:''' an audit record reduction and report generation capability that supports audit record reporting requirements is implemented.
* '''{{anchor|A.03.03.06.a[04]}}A.03.03.06.a[04]:''' an audit record reduction and report generation capability that supports after-the-fact investigations of incidents is implemented.
* '''{{anchor|A.03.03.06.b[01]}}A.03.03.06.b[01]:''' the original content of audit records is preserved.
* '''{{anchor|A.03.03.06.b[02]}}A.03.03.06.b[02]:''' the original time ordering of audit records is preserved.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: audit and accountability policy and procedures; procedures for audit record reduction and report generation; audit record reduction, review, analysis, and reporting tools; system audit records; system design documentation; system configuration settings; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with audit record reduction and report generation responsibilities; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: mechanisms for supporting audit record reduction and report generation capability]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AU-07 AU-07]

{{anchor|d30e2590-Head3}}{{anchor|sec-sec_03.03.07}}=== 03.03.07 Time Stamps ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.03.07.ODP[01]}}A.03.03.07.ODP[01]: '''<nowiki/>'''''granularity of time measurement for audit record time stamps is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.03.07.a}}A.03.03.07.a:''' internal system clocks are used to generate time stamps for audit records.
* '''{{anchor|A.03.03.07.b[01]}}A.03.03.07.b[01]:''' time stamps are recorded for audit records that meet '''''<A.03.03.07.ODP[01]: granularity of time measurement>'''''.
* '''{{anchor|A.03.03.07.b[02]}}A.03.03.07.b[02]:''' time stamps are recorded for audit records that use Coordinated Universal Time (UTC), have a fixed local time offset from UTC, or include the local time offset as part of the time stamp.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: audit and accountability policy and procedures; procedures for timestamp generation; system design documentation; system configuration settings; system audit records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: mechanisms for implementing timestamp generation]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AU-08 AU-08]

{{anchor|d30e2654-Head3}}{{anchor|sec-sec_03.03.08}}=== 03.03.08 Protection of Audit Information ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.03.08.a[01]}}A.03.03.08.a[01]:''' audit information is protected from unauthorized access, modification, and deletion.
* '''{{anchor|A.03.03.08.a[02]}}A.03.03.08.a[02]:''' audit logging tools are protected from unauthorized access, modification, and deletion.
* '''{{anchor|A.03.03.08.b}}A.03.03.08.b:''' access to management of audit logging functionality is authorized to only a subset of privileged users or roles.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: audit and accountability policy and procedures; access control policy and procedures; procedures for the protection of audit information; system configuration settings; system audit records; audit tools; system-generated list of privileged users with access to the management of audit functionality; access authorizations; access control list; system design documentation; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with audit and accountability responsibilities; personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: mechanisms for implementing audit information protection; mechanisms for managing access to audit functionality]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AU-09 AU-09], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AU-09 AU-09(04)]

{{anchor|d30e2711-Head3}}{{anchor|sec-sec_03.03.09}}=== 03.03.09 Withdrawn ===

Incorporated into [[#sec-sec_03.03.08|03.03.08]].

{{anchor|d30e2721-Head2}}{{anchor|sec-sec_3.4}}== 3.4 [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM Configuration Management] ==

{{anchor|d30e2726-Head3}}{{anchor|sec-sec_03.04.01}}=== 03.04.01 Baseline Configuration ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.04.01.ODP[01]}}A.03.04.01.ODP[01]: '''<nowiki/>'''''the frequency of baseline configuration review and update is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.04.01.a[01]}}A.03.04.01.a[01]:''' a current baseline configuration of the system is developed.
* '''{{anchor|A.03.04.01.a[02]}}A.03.04.01.a[02]:''' a current baseline configuration of the system is maintained under configuration control.
* '''{{anchor|A.03.04.01.b[01]}}A.03.04.01.b[01]:''' the baseline configuration of the system is reviewed '''''<A.03.04.01.ODP[01]: frequency>'''''.
* '''{{anchor|A.03.04.01.b[02]}}A.03.04.01.b[02]:''' the baseline configuration of the system is updated '''''<A.03.04.01.ODP[01]: frequency>'''''.
* '''{{anchor|A.03.04.01.b[03]}}A.03.04.01.b[03]:''' the baseline configuration of the system is reviewed when system components are installed or modified.
* '''{{anchor|A.03.04.01.b[04]}}A.03.04.01.b[04]:''' the baseline configuration of the system is updated when system components are installed or modified.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: configuration management policy and procedures; procedures for the baseline system configuration; configuration management plan; enterprise architecture; system design documentation; system architecture; system configuration settings; system component inventory; change control records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with configuration management responsibilities; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: processes for managing baseline configurations; mechanisms for supporting configuration control of the baseline configuration]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=CM-02 CM-02]

{{anchor|d30e2809-Head3}}{{anchor|sec-sec_03.04.02}}=== 03.04.02 Configuration Settings ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.04.02.ODP[01]}}A.03.04.02.ODP[01]: '''<nowiki/>'''''configuration settings for the system that reflect the most restrictive mode consistent with operational requirements are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.04.02.a[01]}}A.03.04.02.a[01]:''' the following configuration settings for the system that reflect the most restrictive mode consistent with operational requirements are established and documented: '''''<A.03.04.02.ODP[01]: configuration settings>'''''.
* '''{{anchor|A.03.04.02.a[02]}}A.03.04.02.a[02]:''' the following configuration settings for the system are implemented: '''''<A.03.04.02.ODP[01]: configuration settings>'''''.
* '''{{anchor|A.03.04.02.b[01]}}A.03.04.02.b[01]:''' any deviations from established configuration settings are identified and documented.
* '''{{anchor|A.03.04.02.b[02]}}A.03.04.02.b[02]:''' any deviations from established configuration settings are approved.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: configuration management policy and procedures; procedures for system configuration settings; configuration management plan; system design documentation; system configuration settings; common secure configuration checklists; system component inventory; evidence supporting approved deviations from established configuration settings; change control records; system data processing and retention permissions; system audit records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with security configuration management responsibilities; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: processes for managing configuration settings; mechanisms that implement, monitor, or control system configuration settings; mechanisms that identify or document deviations from established configuration settings]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=CM-06 CM-06]

{{anchor|d30e2881-Head3}}{{anchor|sec-sec_03.04.03}}=== 03.04.03 Configuration Change Control ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.04.03.a}}A.03.04.03.a:''' the types of changes to the system that are configuration-controlled are defined.
* '''{{anchor|A.03.04.03.b[01]}}A.03.04.03.b[01]:''' proposed configuration-controlled changes to the system are reviewed with explicit consideration for security impacts.
* '''{{anchor|A.03.04.03.b[02]}}A.03.04.03.b[02]:''' proposed configuration-controlled changes to the system are approved or disapproved with explicit consideration for security impacts.
* '''{{anchor|A.03.04.03.c[01]}}A.03.04.03.c[01]:''' approved configuration-controlled changes to the system are implemented.
* '''{{anchor|A.03.04.03.c[02]}}A.03.04.03.c[02]:''' approved configuration-controlled changes to the system are documented.
* '''{{anchor|A.03.04.03.d[01]}}A.03.04.03.d[01]:''' activities associated with configuration-controlled changes to the system are monitored.
* '''{{anchor|A.03.04.03.d[02]}}A.03.04.03.d[02]:''' activities associated with configuration-controlled changes to the system are reviewed.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: configuration management policy and procedures; procedures for system configuration change control; configuration management plan; system architecture; configuration settings; change control records; system audit records; change control audit and review reports; agenda, minutes, and documentation from configuration change control oversight meetings; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with configuration change control responsibilities; personnel with information security responsibilities; members of change control board or similar; system administrators]

===== Test =====

[SELECT FROM: processes for configuration change control; mechanisms that implement configuration change control]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=CM-03 CM-03]

{{anchor|d30e2954-Head3}}{{anchor|sec-sec_03.04.04}}=== 03.04.04 Impact Analyses ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.04.04.a}}A.03.04.04.a:''' changes to the system are analyzed to determine potential security impacts prior to change implementation.
* '''{{anchor|A.03.04.04.b}}A.03.04.04.b:''' the security requirements for the system continue to be satisfied after the system changes have been implemented.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: configuration management policy and procedures; procedures for security impact analyses for system changes; configuration management plan; security impact analysis documentation; system design documentation; analysis tools and outputs; change control records; system audit records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with security impact analysis responsibilities; personnel with information security responsibilities; members of change control board; system developers; system administrators]

===== Test =====

[SELECT FROM: processes for security impact analyses]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-04 CM-04], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-04 CM-04(02)]

{{anchor|d30e3005-Head3}}{{anchor|sec-sec_03.04.05}}=== 03.04.05 Access Restrictions for Change ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''A.03.04.05[01]:''' physical access restrictions associated with changes to the system are defined and documented.
* '''A.03.04.05[02]:''' physical access restrictions associated with changes to the system are approved.
* '''A.03.04.05[03]:''' physical access restrictions associated with changes to the system are enforced.
* '''A.03.04.05[04]:''' logical access restrictions associated with changes to the system are defined and documented.
* '''A.03.04.05[05]:''' logical access restrictions associated with changes to the system are approved.
* '''A.03.04.05[06]:''' logical access restrictions associated with changes to the system are enforced.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: configuration management policy and procedures; procedures for access restrictions for system changes; configuration management plan; system design documentation; system architecture; system configuration settings; logical access approvals; physical access approvals; access credentials; change control records; system audit records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with logical access control responsibilities; personnel with physical access control responsibilities; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: processes for managing access restrictions for system changes; mechanisms for supporting, implementing, or enforcing access restrictions associated with system changes]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=CM-05 CM-05]

{{anchor|d30e3067-Head3}}{{anchor|sec-sec_03.04.06}}=== 03.04.06 Least Functionality ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.04.06.ODP[01]}}A.03.04.06.ODP[01]: '''<nowiki/>'''''functions to be prohibited or restricted are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.04.06.ODP[02]}}A.03.04.06.ODP[02]: '''<nowiki/>'''''ports to be prohibited or restricted are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.04.06.ODP[03]}}A.03.04.06.ODP[03]: '''<nowiki/>'''''protocols to be prohibited or restricted are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.04.06.ODP[04]}}A.03.04.06.ODP[04]: '''<nowiki/>'''''connections to be prohibited or restricted are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.04.06.ODP[05]}}A.03.04.06.ODP[05]: '''<nowiki/>'''''services to be prohibited or restricted are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.04.06.ODP[06]}}A.03.04.06.ODP[06]: '''<nowiki/>'''''the frequency at which to review the system to identify unnecessary or nonsecure functions, ports, protocols, connections, or services is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.04.06.a}}A.03.04.06.a:''' the system is configured to provide only mission-essential capabilities.
* '''{{anchor|A.03.04.06.b[01]}}A.03.04.06.b[01]:''' the use of the following functions is prohibited or restricted: '''''<A.03.04.06.ODP[01]: functions>'''''.
* '''{{anchor|A.03.04.06.b[02]}}A.03.04.06.b[02]:''' the use of the following ports is prohibited or restricted: '''''<A.03.04.06.ODP[02]: ports>'''''.
* '''{{anchor|A.03.04.06.b[03]}}A.03.04.06.b[03]:''' the use of the following protocols is prohibited or restricted: '''''<A.03.04.06.ODP[03]: protocols>'''''.
* '''{{anchor|A.03.04.06.b[04]}}A.03.04.06.b[04]:''' the use of the following connections is prohibited or restricted: '''''<A.03.04.06.ODP[04]: connections>'''''.
* '''{{anchor|A.03.04.06.b[05]}}A.03.04.06.b[05]:''' the use of the following services is prohibited or restricted: '''''<A.03.04.06.ODP[05]: services>'''''.
* '''{{anchor|A.03.04.06.c}}A.03.04.06.c:''' the system is reviewed '''''<A.03.04.06.ODP[06]: frequency>''''' to identify unnecessary or nonsecure functions, ports, protocols, connections, and services.
* '''{{anchor|A.03.04.06.d}}A.03.04.06.d:''' unnecessary or nonsecure functions, ports, protocols, connections, and services are disabled or removed.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: configuration management policy and procedures; procedures for least functionality in the system; configuration management plan; system design documentation; system configuration settings; system component inventory; common secure configuration checklists; documented reviews of functions, ports, protocols, and services; change control records; system audit records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with configuration management responsibilities; personnel with responsibilities for reviewing functions, ports, protocols, and services; personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: processes for prohibiting or restricting functions, ports, protocols, and services; processes for reviewing or disabling functions, ports, protocols, and services; mechanisms for implementing the review and disabling of functions, ports, protocols, and services; mechanisms for implementing restrictions on or the prohibition of functions, ports, protocols, and services]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=CM-07 CM-07], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=CM-07 CM-07(01)]

{{anchor|d30e3221-Head3}}{{anchor|sec-sec_03.04.07}}=== 03.04.07 Withdrawn ===

Incorporated into [[#sec-sec_03.04.06|03.04.06]] and [[#sec-sec_03.04.08|03.04.08]].

{{anchor|d30e3234-Head3}}{{anchor|sec-sec_03.04.08}}=== 03.04.08 Authorized Software – Allow by Exception ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.04.08.ODP[01]}}A.03.04.08.ODP[01]: '''<nowiki/>'''''the frequency at which to review and update the list of authorized software programs is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.04.08.a}}A.03.04.08.a:''' software programs authorized to execute on the system are identified.
* '''{{anchor|A.03.04.08.b}}A.03.04.08.b:''' a deny-all, allow-by-exception policy for the execution of authorized software programs on the system is implemented.
* '''{{anchor|A.03.04.08.c}}A.03.04.08.c:''' the list of authorized software programs is reviewed and updated '''''<A.03.04.08.ODP[01]: frequency>'''''.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: configuration management policy and procedures; procedures for least functionality in the system; configuration management plan; system design documentation; system configuration settings; list of software programs authorized to execute on the system; system component inventory; records associated with the review and update of the list of authorized software programs; common secure configuration checklists; change control records; system audit records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with responsibilities for identifying software authorized to execute on the system; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: processes for identifying, reviewing, and updating programs authorized to execute on the system; processes for implementing authorized software policy; mechanisms for supporting or implementing authorized software policy]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=CM-07 CM-07(05)]

{{anchor|d30e3299-Head3}}{{anchor|sec-sec_03.04.09}}=== 03.04.09 Withdrawn ===

Addressed by [[#sec-sec_03.01.05|03.01.05]], [[#sec-sec_03.01.06|03.01.06]], [[#sec-sec_03.01.07|03.01.07]], [[#sec-sec_03.04.08|03.04.08]], and [[#sec-sec_03.12.03|03.12.03]].

{{anchor|d30e3321-Head3}}{{anchor|sec-sec_03.04.10}}=== 03.04.10 System Component Inventory ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.04.10.ODP[01]}}A.03.04.10.ODP[01]: '''<nowiki/>'''''the frequency at which to review and update the system component inventory is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.04.10.a}}A.03.04.10.a:''' an inventory of system components is developed and documented.
* '''{{anchor|A.03.04.10.b[01]}}A.03.04.10.b[01]:''' the system component inventory is reviewed '''''<A.03.04.10.ODP[01]: frequency>'''''.
* '''{{anchor|A.03.04.10.b[02]}}A.03.04.10.b[02]:''' the system component inventory is updated '''''<A.03.04.10.ODP[01]: frequency>'''''.
* '''{{anchor|A.03.04.10.c[01]}}A.03.04.10.c[01]:''' the system component inventory is updated as part of component installations.
* '''{{anchor|A.03.04.10.c[02]}}A.03.04.10.c[02]:''' the system component inventory is updated as part of component removals.
* '''{{anchor|A.03.04.10.c[03]}}A.03.04.10.c[03]:''' the system component inventory is updated as part of system updates.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: configuration management policy and procedures; procedures for system component inventory; configuration management plan; system design documentation; system component inventory; inventory reviews and update records; component installation records; change control records; component removal records; system change records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with component inventory management responsibilities; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: processes for managing the system component inventory; mechanisms for supporting or implementing the system component inventory; processes for updating the system component inventory; mechanisms for supporting or implementing the system component inventory updates]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=CM-08 CM-08], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=CM-08 CM-08(01)]

{{anchor|d30e3408-Head3}}{{anchor|sec-sec_03.04.11}}=== 03.04.11 Information Location ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.04.11.a[01]}}A.03.04.11.a[01]:''' the location of CUI is identified and documented.
* '''{{anchor|A.03.04.11.a[02]}}A.03.04.11.a[02]:''' the system components on which CUI is processed are identified and documented.
* '''{{anchor|A.03.04.11.a[03]}}A.03.04.11.a[03]:''' the system components on which CUI is stored are identified and documented.
* '''{{anchor|A.03.04.11.b[01]}}A.03.04.11.b[01]:''' changes to the system or system component location where CUI is processed are documented.
* '''{{anchor|A.03.04.11.b[02]}}A.03.04.11.b[02]:''' changes to the system or system component location where CUI is stored are documented.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: configuration management policy and procedures; configuration management plan; procedures for identification and documentation of information location; system audit records; architecture documentation; system design documentation; list of users with system and system component access; change control records; system component inventory; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with responsibilities for managing information location and user access; personnel with responsibilities for operating, using, or maintaining the system; personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: processes governing information location; mechanisms for enforcing policies and methods for governing information location]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=CM-12 CM-12]

{{anchor|d30e3470-Head3}}{{anchor|sec-sec_03.04.12}}=== 03.04.12 System and Component Configuration for High-Risk Areas ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.04.12.ODP[01]}}A.03.04.12.ODP[01]: '''<nowiki/>'''''configurations for systems or system components to be issued to individuals traveling to high-risk locations are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.04.12.ODP[02]}}A.03.04.12.ODP[02]: '''<nowiki/>'''''security requirements to be applied to the system or system components when individuals return from travel are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.04.12.a}}A.03.04.12.a:''' systems or system components with the following configurations are issued to individuals traveling to high-risk locations: '''''<A.03.04.12.ODP[01]: configurations>'''''.
* '''{{anchor|A.03.04.12.b}}A.03.04.12.b:''' the following security requirements are applied to the system or system components when the individuals return from travel: '''''<A.03.04.12.ODP[02]: security requirements>'''''.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: configuration management policy and procedures; configuration management plan; procedures for the baseline configuration of the system; procedures for system component installations and upgrades; system component inventory; system component installations or upgrades and associated records; records of system baseline configuration reviews and updates; system configuration settings; system architecture; change control records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with configuration management responsibilities; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: processes for managing baseline configurations]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=CM-02 CM-02(07)]

{{anchor|d30e3542-Head2}}{{anchor|sec-sec_3.5}}== 3.5 [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA Identification and Authentication] ==

{{anchor|d30e3547-Head3}}{{anchor|sec-sec_03.05.01}}=== 03.05.01 User Identification, Authentication, and Re-Authentication ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.05.01.ODP[01]}}A.03.05.01.ODP[01]: '''<nowiki/>'''''circumstances or situations that require re-authentication are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.05.01.a[01]}}A.03.05.01.a[01]:''' system users are uniquely identified.
* '''{{anchor|A.03.05.01.a[02]}}A.03.05.01.a[02]:''' system users are authenticated.
* '''{{anchor|A.03.05.01.a[03]}}A.03.05.01.a[03]:''' processes acting on behalf of users are associated with uniquely identified and authenticated system users.
* '''{{anchor|A.03.05.01.b}}A.03.05.01.b:''' users are reauthenticated when '''''<A.03.05.01.ODP[01]: circumstances or situations>'''''.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: identification and authentication policy and procedures; list of circumstances or situations requiring re-authentication; system design documentation; system configuration settings; system audit records; list of system accounts; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with identification and authentication responsibilities; personnel with system operations responsibilities; personnel with account management responsibilities; system developers; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: processes for uniquely identifying and authenticating users; mechanisms for supporting or implementing identification and authentication capabilities]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=IA-02 IA-02], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=IA-11 IA-11]

{{anchor|d30e3620-Head3}}{{anchor|sec-sec_03.05.02}}=== 03.05.02 Device Identification and Authentication ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.05.02.ODP[01]}}A.03.05.02.ODP[01]: '''<nowiki/>'''''devices or types of devices to be uniquely identified and authenticated before establishing a connection are defined'''''<nowiki/>'''.'''
* '''A.03.05.02[01]: '''<nowiki/>'''''<A.03.05.02.ODP[01]: devices or types of devices>''''' are uniquely identified before establishing a system connection.
* '''A.03.05.02[02]: '''<nowiki/>'''''<A.03.05.02.ODP[01]: devices or types of devices>''''' are authenticated before establishing a system connection.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: identification and authentication policy and procedures; procedures for device identification and authentication; system design documentation; list of devices requiring unique identification and authentication; device connection reports; system configuration settings; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with responsibilities for device identification and authentication; personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: mechanisms for supporting or implementing device identification and authentication capabilities]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=IA-03 IA-03]

{{anchor|d30e3681-Head3}}{{anchor|sec-sec_03.05.03}}=== 03.05.03 Multi-Factor Authentication ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''A.03.05.03[01]:''' multi-factor authentication for access to privileged accounts is implemented.
* '''A.03.05.03[02]:''' multi-factor authentication for access to non-privileged accounts is implemented.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: identification and authentication policy and procedures; system design documentation; list of system accounts; system configuration settings; system audit records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with system operations responsibilities; personnel with account management responsibilities; personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: mechanisms for supporting or implementing a multi-factor authentication capability]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=IA-02 IA-02(01)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=IA-02 IA-02(02)]

{{anchor|d30e3730-Head3}}{{anchor|sec-sec_03.05.04}}=== 03.05.04 Replay-Resistant Authentication ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''A.03.05.04[01]:''' replay-resistant authentication mechanisms for access to privileged accounts are implemented.
* '''A.03.05.04[02]:''' replay-resistant authentication mechanisms for access to non-privileged accounts are implemented.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: identification and authentication policy and procedures; system design documentation; system audit records; system configuration settings; list of privileged system accounts; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with system operations responsibilities; personnel with account management responsibilities; personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: mechanisms for supporting or implementing identification and authentication capabilities; mechanisms for supporting or implementing replay-resistance]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=IA-02 IA-02(08)]

{{anchor|d30e3775-Head3}}{{anchor|sec-sec_03.05.05}}=== 03.05.05 Identifier Management ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.05.05.ODP[01]}}A.03.05.05.ODP[01]: '''<nowiki/>'''''the time period for preventing the reuse of identifiers is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.05.05.ODP[02]}}A.03.05.05.ODP[02]: '''<nowiki/>'''''characteristics used to identify individual status are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.05.05.a}}A.03.05.05.a:''' authorization is received from organizational personnel or roles to assign an individual, group, role, service, or device identifier.
* '''{{anchor|A.03.05.05.b[01]}}A.03.05.05.b[01]:''' an identifier that identifies an individual, group, role, service, or device is selected.
* '''{{anchor|A.03.05.05.b[02]}}A.03.05.05.b[02]:''' an identifier that identifies an individual, group, role, service, or device is assigned.
* '''{{anchor|A.03.05.05.c}}A.03.05.05.c:''' the reuse of identifiers for '''''<A.03.05.05.ODP[01]: time period>''''' is prevented.
* '''{{anchor|A.03.05.05.d}}A.03.05.05.d:''' individual identifiers are managed by uniquely identifying each individual as '''''<A.03.05.05.ODP[02]: characteristic>'''''.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: identification and authentication policy and procedures; procedures for identifier management; procedures for account management; system design documentation; list of system accounts; list of characteristics identifying individual status; system configuration settings; list of identifiers generated from physical access control devices; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with identifier management responsibilities; personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: mechanisms for supporting or implementing identifier management]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=IA-04 IA-04], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=IA-04 IA-04(04)]

{{anchor|d30e3866-Head3}}{{anchor|sec-sec_03.05.06}}=== 03.05.06 Withdrawn ===

Consistency with SP 800-53 [[[#bibr-ref_8|8]]].

{{anchor|d30e3876-Head3}}{{anchor|sec-sec_03.05.07}}=== 03.05.07 Password Management ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.05.07.ODP[01]}}A.03.05.07.ODP[01]: '''<nowiki/>'''''the frequency at which to update the list of commonly used, expected, or compromised passwords is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.05.07.ODP[02]}}A.03.05.07.ODP[02]: '''<nowiki/>'''''password composition and complexity rules are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.05.07.a[01]}}A.03.05.07.a[01]:''' a list of commonly used, expected, or compromised passwords is maintained.
* '''{{anchor|A.03.05.07.a[02]}}A.03.05.07.a[02]:''' a list of commonly used, expected, or compromised passwords is updated '''''<A.03.05.07.ODP[01]: frequency>'''''.
* '''{{anchor|A.03.05.07.a[03]}}A.03.05.07.a[03]:''' a list of commonly used, expected, or compromised passwords is updated when organizational passwords are suspected to have been compromised.
* '''{{anchor|A.03.05.07.b}}A.03.05.07.b:''' passwords are verified not to be found on the list of commonly used, expected, or compromised passwords when they are created or updated by users.
* '''{{anchor|A.03.05.07.c}}A.03.05.07.c:''' passwords are only transmitted over cryptographically protected channels.
* '''{{anchor|A.03.05.07.d}}A.03.05.07.d:''' passwords are stored in a cryptographically protected form.
* '''{{anchor|A.03.05.07.e}}A.03.05.07.e:''' a new password is selected upon first use after account recovery.
* '''{{anchor|A.03.05.07.f}}A.03.05.07.f:''' the following composition and complexity rules for passwords are enforced: '''''<A.03.05.07.ODP[02]: rules>'''''.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: identification and authentication policy and procedures; password policy; procedures for authenticator management; system design documentation; system configuration settings; password configurations; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with authenticator management responsibilities; personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: mechanisms for supporting or implementing a password-based authenticator management capability]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=IA-05 IA-05(01)]

{{anchor|d30e3978-Head3}}{{anchor|sec-sec_03.05.08}}=== 03.05.08 Withdrawn ===

Consistency with SP 800-53 [[[#bibr-ref_8|8]]].

{{anchor|d30e3988-Head3}}{{anchor|sec-sec_03.05.09}}=== 03.05.09 Withdrawn ===

Consistency with SP 800-53 [[[#bibr-ref_8|8]]].

{{anchor|d30e3999-Head3}}{{anchor|sec-sec_03.05.10}}=== 03.05.10 Withdrawn ===

Incorporated into [[#sec-sec_03.05.07|03.05.07]].

{{anchor|d30e4009-Head3}}{{anchor|sec-sec_03.05.11}}=== 03.05.11 Authentication Feedback ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''A.03.05.11:''' feedback of authentication information during the authentication process is obscured.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: identification and authentication policy and procedures; procedures for authenticator feedback; system design documentation; system configuration settings; system audit records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: mechanisms for supporting or implementing the obscuring of feedback of authentication information during authentication]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=IA-06 IA-06]

{{anchor|d30e4050-Head3}}{{anchor|sec-sec_03.05.12}}=== 03.05.12 Authenticator Management ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.05.12.ODP[01]}}A.03.05.12.ODP[01]: '''<nowiki/>'''''the frequency for changing or refreshing authenticators is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.05.12.ODP[02]}}A.03.05.12.ODP[02]: '''<nowiki/>'''''events that trigger the change or refreshment of authenticators are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.05.12.a}}A.03.05.12.a:''' the identity of the individual, group, role, service, or device receiving the authenticator as part of the initial authenticator distribution is verified.
* '''{{anchor|A.03.05.12.b}}A.03.05.12.b:''' initial authenticator content for any authenticators issued by the organization is established.
* '''{{anchor|A.03.05.12.c[01]}}A.03.05.12.c[01]:''' administrative procedures for initial authenticator distribution are established.
* '''{{anchor|A.03.05.12.c[02]}}A.03.05.12.c[02]:''' administrative procedures for lost, compromised, or damaged authenticators are established.
* '''{{anchor|A.03.05.12.c[03]}}A.03.05.12.c[03]:''' administrative procedures for revoking authenticators are established.
* '''{{anchor|A.03.05.12.c[04]}}A.03.05.12.c[04]:''' administrative procedures for initial authenticator distribution are implemented.
* '''{{anchor|A.03.05.12.c[05]}}A.03.05.12.c[05]:''' administrative procedures for lost, compromised, or damaged authenticators are implemented.
* '''{{anchor|A.03.05.12.c[06]}}A.03.05.12.c[06]:''' administrative procedures for revoking authenticators are implemented.
* '''{{anchor|A.03.05.12.d}}A.03.05.12.d:''' default authenticators are changed at first use.
* '''{{anchor|A.03.05.12.e}}A.03.05.12.e:''' authenticators are changed or refreshed '''''<A.03.05.12.ODP[01]: frequency>''''' or when the following events occur: '''''<A.03.05.12.ODP[02]: events>'''''.
* '''{{anchor|A.03.05.12.f[01]}}A.03.05.12.f[01]:''' authenticator content is protected from unauthorized disclosure.
* '''{{anchor|A.03.05.12.f[02]}}A.03.05.12.f[02]:''' authenticator content is protected from unauthorized modification.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: identification and authentication policy and procedures; procedures for authenticator management; system configuration settings; list of system authenticator types; system design documentation; system audit records; change control records associated with managing system authenticators; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with authenticator management responsibilities; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: mechanisms for supporting or implementing the authenticator management capability]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=IA-05 IA-05]

{{anchor|d30e4172-Head2}}{{anchor|sec-sec_3.6}}== 3.6 [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IR Incident Response] ==

{{anchor|d30e4177-Head3}}{{anchor|sec-sec_03.06.01}}=== 03.06.01 Incident Handling ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''A.03.06.01[01]:''' an incident-handling capability that is consistent with the incident response plan is implemented.
* '''A.03.06.01[02]:''' the incident handling capability includes preparation.
* '''A.03.06.01[03]:''' the incident handling capability includes detection and analysis.
* '''A.03.06.01[04]:''' the incident handling capability includes containment.
* '''A.03.06.01[05]:''' the incident handling capability includes eradication.
* '''A.03.06.01[06]:''' the incident handling capability includes recovery.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: incident response policy and procedures; contingency planning policy and procedures; procedures for incident handling; procedures for incident response planning; incident response plan; contingency plan; records of incident response plan reviews and approvals; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with incident handling responsibilities; personnel with incident response planning responsibilities; personnel with contingency planning responsibilities; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: incident handling capability for the organization; incident response plan]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=IR-04 IR-04]

{{anchor|d30e4239-Head3}}{{anchor|sec-sec_03.06.02}}=== 03.06.02 Incident Monitoring, Reporting, and Response Assistance ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.06.02.ODP[01]}}A.03.06.02.ODP[01]: '''<nowiki/>'''''the time period to report suspected incidents to the organizational incident response capability is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.06.02.ODP[02]}}A.03.06.02.ODP[02]: '''<nowiki/>'''''authorities to whom incident information is to be reported are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.06.02.a[01]}}A.03.06.02.a[01]:''' system security incidents are tracked.
* '''{{anchor|A.03.06.02.a[02]}}A.03.06.02.a[02]:''' system security incidents are documented.
* '''{{anchor|A.03.06.02.b}}A.03.06.02.b:''' suspected incidents are reported to the organizational incident response capability within '''''<A.03.06.02.ODP[01]: time period>'''''.
* '''{{anchor|A.03.06.02.c}}A.03.06.02.c:''' incident information is reported to '''''<A.03.06.02.ODP[02]: authorities>'''''.
* '''{{anchor|A.03.06.02.d}}A.03.06.02.d:''' an incident response support resource that offers advice and assistance to system users on handling and reporting incidents is provided.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: incident response policy and procedures; procedures for incident monitoring; procedures for incident response assistance; incident response records and documentation; incident response plan; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with incident monitoring responsibilities; personnel with incident response assistance and support responsibilities; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: processes for incident reporting; incident monitoring capability; mechanisms for supporting or implementing the tracking and documenting of system security incidents; mechanisms for supporting or implementing incident reporting; mechanisms for supporting or implementing incident response assistance; processes for incident response assistance]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=IR-05 IR-05], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=IR-06 IR-06], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=IR-07 IR-07]

{{anchor|d30e4334-Head3}}{{anchor|sec-sec_03.06.03}}=== 03.06.03 Incident Response Testing ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.06.03.ODP[01]}}A.03.06.03.ODP[01]: '''<nowiki/>'''''the frequency at which to test the effectiveness of the incident response capability for the system is defined.'''''
* '''A.03.06.03:''' the effectiveness of the incident response capability is tested '''''<A.03.06.03.ODP[01]: frequency>'''''.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: incident response policy and procedures; contingency planning policy and procedures; procedures for incident response testing; procedures for contingency plan testing; incident response testing material; incident response test results; incident response test plan; incident response plan; contingency plan; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with incident response testing responsibilities; personnel with information security responsibilities]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=IR-03 IR-03]

{{anchor|d30e4380-Head3}}{{anchor|sec-sec_03.06.04}}=== 03.06.04 Incident Response Training ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.06.04.ODP[01]}}A.03.06.04.ODP[01]: '''<nowiki/>'''''the time period within which incident response training is to be provided to system users is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.06.04.ODP[02]}}A.03.06.04.ODP[02]: '''<nowiki/>'''''the frequency at which to provide incident response training to users after initial training is defined.'''''
* '''{{anchor|A.03.06.04.ODP[03]}}A.03.06.04.ODP[03]: '''<nowiki/>'''''the frequency at which to review and update incident response training content is defined.'''''
* '''{{anchor|A.03.06.04.ODP[04]}}A.03.06.04.ODP[04]: '''<nowiki/>'''''events that initiate a review of the incident response training content are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.06.04.a.01}}A.03.06.04.a.01:''' incident response training for system users consistent with assigned roles and responsibilities is provided within '''''<A.03.06.04.ODP[01]: time period>''''' of assuming an incident response role or responsibility or acquiring system access.
* '''{{anchor|A.03.06.04.a.02}}A.03.06.04.a.02:''' incident response training for system users consistent with assigned roles and responsibilities is provided when required by system changes.
* '''{{anchor|A.03.06.04.a.03}}A.03.06.04.a.03:''' incident response training for system users consistent with assigned roles and responsibilities is provided '''''<A.03.06.04.ODP[02]: frequency>''''' thereafter.
* '''{{anchor|A.03.06.04.b[01]}}A.03.06.04.b[01]:''' incident response training content is reviewed '''''<A.03.06.04.ODP[03]: frequency>'''''.
* '''{{anchor|A.03.06.04.b[02]}}A.03.06.04.b[02]:''' incident response training content is updated '''''<A.03.06.04.ODP[03]: frequency>'''''.
* '''{{anchor|A.03.06.04.b[03]}}A.03.06.04.b[03]:''' incident response training content is reviewed following '''''<A.03.06.04.ODP[04]: events>'''''.
* '''{{anchor|A.03.06.04.b[04]}}A.03.06.04.b[04]:''' incident response training content is updated following '''''<A.03.06.04.ODP[04]: events>'''''.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: incident response policy and procedures; procedures for incident response training; incident response training curriculum; incident response training materials; incident response plan; incident response training records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with incident response training and operational responsibilities; personnel with information security responsibilities]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=IR-02 IR-02]

{{anchor|d30e4498-Head3}}{{anchor|sec-sec_03.06.05}}=== 03.06.05 Incident Response Plan ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.06.05.a.01}}A.03.06.05.a.01:''' an incident response plan is developed that provides the organization with a roadmap for implementing its incident response capability.
* '''{{anchor|A.03.06.05.a.02}}A.03.06.05.a.02:''' an incident response plan is developed that describes the structure and organization of the incident response capability.
* '''{{anchor|A.03.06.05.a.03}}A.03.06.05.a.03:''' an incident response plan is developed that provides a high-level approach for how the incident response capability fits into the overall organization.
* '''{{anchor|A.03.06.05.a.04}}A.03.06.05.a.04:''' an incident response plan is developed that defines reportable incidents.
* '''{{anchor|A.03.06.05.a.05}}A.03.06.05.a.05:''' an incident response plan is developed that addresses the sharing of incident information.
* '''{{anchor|A.03.06.05.a.06}}A.03.06.05.a.06:''' an incident response plan is developed that designates responsibilities to organizational entities, personnel, or roles.
* '''{{anchor|A.03.06.05.b[01]}}A.03.06.05.b[01]:''' copies of the incident response plan are distributed to designated incident response personnel (identified by name or by role).
* '''{{anchor|A.03.06.05.b[02]}}A.03.06.05.b[02]:''' copies of the incident response plan are distributed to organizational elements.
* '''{{anchor|A.03.06.05.c}}A.03.06.05.c:''' the incident response plan is updated to address system and organizational changes or problems encountered during plan implementation, execution, or testing.
* '''{{anchor|A.03.06.05.d}}A.03.06.05.d:''' the incident response plan is protected from unauthorized disclosure.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: incident response policy; procedures addressing incident response planning; incident response plan; system security plan; records of incident response plan reviews and approvals; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with incident response planning responsibilities; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: incident response plan and related processes]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=IR-08 IR-08]

{{anchor|d30e4586-Head2}}{{anchor|sec-sec_3.7}}== 3.7 [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MA Maintenance] ==

{{anchor|d30e4591-Head3}}{{anchor|sec-sec_03.07.01}}=== 03.07.01 Withdrawn ===

Recategorized as NCO.

{{anchor|d30e4598-Head3}}{{anchor|sec-sec_03.07.02}}=== 03.07.02 Withdrawn ===

Incorporated into [[#sec-sec_03.07.04|03.07.04]] and [[#sec-sec_03.07.06|03.07.06]].

{{anchor|d30e4611-Head3}}{{anchor|sec-sec_03.07.03}}=== 03.07.03 Withdrawn ===

Incorporated into [[#sec-sec_03.08.03|03.08.03]].

{{anchor|d30e4621-Head3}}{{anchor|sec-sec_03.07.04}}=== 03.07.04 Maintenance Tools ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.07.04.a[01]}}A.03.07.04.a[01]:''' the use of system maintenance tools is approved.
* '''{{anchor|A.03.07.04.a[02]}}A.03.07.04.a[02]:''' the use of system maintenance tools is controlled.
* '''{{anchor|A.03.07.04.a[03]}}A.03.07.04.a[03]:''' the use of system maintenance tools is monitored.
* '''{{anchor|A.03.07.04.b}}A.03.07.04.b:''' media with diagnostic and test programs are checked for malicious code before the media are used in the system.
* '''{{anchor|A.03.07.04.c}}A.03.07.04.c:''' the removal of system maintenance equipment containing CUI is prevented by verifying that there is no CUI on the equipment, sanitizing or destroying the equipment, or retaining the equipment within the facility.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: maintenance policy and procedures; procedures for system maintenance tools; system maintenance tools; maintenance tool inspection records; equipment sanitization records; media sanitization records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with system maintenance responsibilities; personnel responsible for media sanitization; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: processes for approving, controlling, and monitoring maintenance tools; mechanisms for supporting or implementing the approval, control, or monitoring of maintenance tools; processes for preventing the unauthorized removal of information; processes for inspecting media for malicious code; mechanisms for supporting media sanitization or the destruction of equipment; mechanisms for supporting the verification of media sanitization; processes for inspecting maintenance tools; mechanisms for supporting or implementing the inspection of maintenance tools; mechanisms for supporting or implementing the inspection of media used for maintenance]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=MA-03 MA-03], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=MA-03 MA-03(01)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=MA-03 MA-03(02)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=MA-03 MA-03(03)]

{{anchor|d30e4696-Head3}}{{anchor|sec-sec_03.07.05}}=== 03.07.05 Nonlocal Maintenance ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.07.05.a[01]}}A.03.07.05.a[01]:''' nonlocal maintenance and diagnostic activities are approved.
* '''{{anchor|A.03.07.05.a[02]}}A.03.07.05.a[02]:''' nonlocal maintenance and diagnostic activities are monitored.
* '''{{anchor|A.03.07.05.b[01]}}A.03.07.05.b[01]:''' multi-factor authentication is implemented in the establishment of nonlocal maintenance and diagnostic sessions.
* '''{{anchor|A.03.07.05.b[02]}}A.03.07.05.b[02]:''' replay resistance is implemented in the establishment of nonlocal maintenance and diagnostic sessions.
* '''{{anchor|A.03.07.05.c[01]}}A.03.07.05.c[01]:''' session connections are terminated when nonlocal maintenance is completed.
* '''{{anchor|A.03.07.05.c[02]}}A.03.07.05.c[02]:''' network connections are terminated when nonlocal maintenance is completed.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: maintenance policy and procedures; remote access policy and procedures; procedures for nonlocal system maintenance; records of remote access; maintenance records; diagnostic records; system design documentation; system configuration settings; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with system maintenance responsibilities; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: processes for managing nonlocal maintenance; mechanisms for implementing, supporting, or managing nonlocal maintenance; mechanisms for implementing multi-factor authentication and replay resistance; mechanisms for terminating nonlocal maintenance sessions and network connections]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=MA-04 MA-04]

{{anchor|d30e4764-Head3}}{{anchor|sec-sec_03.07.06}}=== 03.07.06 Maintenance Personnel ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.07.06.a}}A.03.07.06.a:''' a process for maintenance personnel authorization is established.
* '''{{anchor|A.03.07.06.b}}A.03.07.06.b:''' a list of authorized maintenance organizations or personnel is maintained.
* '''{{anchor|A.03.07.06.c}}A.03.07.06.c:''' non-escorted personnel who perform maintenance on the system possess the required access authorizations.
* '''{{anchor|A.03.07.06.d[01]}}A.03.07.06.d[01]:''' organizational personnel with required access authorizations are designated to supervise the maintenance activities of personnel who do not possess the required access authorizations.
* '''{{anchor|A.03.07.06.d[02]}}A.03.07.06.d[02]:''' organizational personnel with required technical competence are designated to supervise the maintenance activities of personnel who do not possess the required access authorizations.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: maintenance policy and procedures; service provider contracts; service-level agreements; list of authorized personnel; maintenance records; access control records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with system maintenance responsibilities; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: processes for authorizing and managing maintenance personnel; mechanisms for supporting or implementing the authorization of maintenance personnel]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=MA-05 MA-05]

{{anchor|d30e4826-Head2}}{{anchor|sec-sec_3.8}}== 3.8 [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MP Media Protection] ==

{{anchor|d30e4831-Head3}}{{anchor|sec-sec_03.08.01}}=== 03.08.01 Media Storage ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''A.03.08.01[01]:''' system media that contain CUI are physically controlled.
* '''A.03.08.01[02]:''' system media that contain CUI are securely stored.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: physical protection policy and procedures; media protection policy and procedures; procedures for media storage; access control policy and procedures; system media; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with system media protection and storage responsibilities; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: processes for storing information media; mechanisms for supporting or implementing secure media storage/media protection]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=MP-04 MP-04]

{{anchor|d30e4877-Head3}}{{anchor|sec-sec_03.08.02}}=== 03.08.02 Media Access ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''A.03.08.02:''' access to CUI on system media is restricted to authorized personnel or roles.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: physical protection policy and procedures; media protection policy and procedures; procedures for media access restrictions; access control policy and procedures; media storage facilities; access control records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with system media protection responsibilities; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: processes for restricting information on media; mechanisms for supporting or implementing media access restrictions]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=MP-02 MP-02]

{{anchor|d30e4918-Head3}}{{anchor|sec-sec_03.08.03}}=== 03.08.03 Media Sanitization ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''A.03.08.03:''' system media that contain CUI are sanitized prior to disposal, release out of organizational control, or release for reuse.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: media protection policy and procedures; procedures for media sanitization and disposal; applicable standards and policies that address media sanitization policy; system audit records; media sanitization records; system design documentation; system configuration settings; records retention and disposition policy; records retention and disposition procedures; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with media sanitization responsibilities; personnel with records retention and disposition responsibilities; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: processes for media sanitization; mechanisms for supporting or implementing media sanitization]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=MP-06 MP-06]

{{anchor|d30e4959-Head3}}{{anchor|sec-sec_03.08.04}}=== 03.08.04 Media Marking ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''A.03.08.04[01]:''' system media that contain CUI are marked to indicate distribution limitations.
* '''A.03.08.04[02]:''' system media that contain CUI are marked to indicate handling caveats.
* '''A.03.08.04[03]:''' system media that contain CUI are marked to indicate applicable CUI markings.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: physical protection policy and procedures; media protection policy and procedures; procedures for media marking; list of system media marking security attributes; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with system media protection and marking responsibilities; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: processes for marking information media; mechanisms for supporting or implementing media marking]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=MP-03 MP-03]

{{anchor|d30e5008-Head3}}{{anchor|sec-sec_03.08.05}}=== 03.08.05 Media Transport ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.08.05.a[01]}}A.03.08.05.a[01]:''' system media that contain CUI are protected during transport outside of controlled areas.
* '''{{anchor|A.03.08.05.a[02]}}A.03.08.05.a[02]:''' system media that contain CUI are controlled during transport outside of controlled areas.
* '''{{anchor|A.03.08.05.b}}A.03.08.05.b:''' accountability for system media that contain CUI is maintained during transport outside of controlled areas.
* '''{{anchor|A.03.08.05.c}}A.03.08.05.c:''' activities associated with the transport of system media that contain CUI are documented.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: physical protection policy and procedures; media protection policy and procedures; procedures for media storage; access control policy and procedures; authorized personnel list; system media; designated controlled areas; system and communications protection policy and procedures; cryptographic mechanisms and configuration documentation; procedures for the protection of information at rest; system design documentation; system configuration settings; list of information at rest requiring confidentiality protections; system audit records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with system media protection and storage responsibilities; personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: processes for storing information media; mechanisms for supporting or implementing media storage/media protection; mechanisms for supporting or implementing confidentiality protections for information at rest]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=MP-05 MP-05], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SC-28 SC-28]

{{anchor|d30e5070-Head3}}{{anchor|sec-sec_03.08.06}}=== 03.08.06 Withdrawn ===

Addressed by [[#sec-sec_03.13.08|03.13.08]].

{{anchor|d30e5080-Head3}}{{anchor|sec-sec_03.08.07}}=== 03.08.07 Media Use ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.08.07.ODP[01]}}A.03.08.07.ODP[01]: '''<nowiki/>'''''types of system media with usage restrictions or that are prohibited from use are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.08.07.a}}A.03.08.07.a:''' the use of the following types of system media is restricted or prohibited: '''''<A.03.08.07.ODP[01]: types of system media>'''''.
* '''{{anchor|A.03.08.07.b}}A.03.08.07.b:''' the use of removable system media without an identifiable owner is prohibited.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: system media protection policy and procedures; system use policy; procedures for media usage restrictions; rules of behavior; system audit records; system design documentation; system configuration settings; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with system media use responsibilities; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: processes for media use; mechanisms for restricting or prohibiting the use of system media on systems or system components]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=MP-07 MP-07]

{{anchor|d30e5139-Head3}}{{anchor|sec-sec_03.08.08}}=== 03.08.08 Withdrawn ===

Incorporated into [[#sec-sec_03.08.07|03.08.07]].

{{anchor|d30e5149-Head3}}{{anchor|sec-sec_03.08.09}}=== 03.08.09 System Backup – Cryptographic Protection ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.08.09.a}}A.03.08.09.a:''' the confidentiality of backup information is protected.
* '''{{anchor|A.03.08.09.b}}A.03.08.09.b:''' cryptographic mechanisms are implemented to prevent the unauthorized disclosure of CUI at backup storage locations.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: contingency planning policy and procedures; procedures for system backup; contingency plan; system design documentation; system configuration settings; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with system backup responsibilities; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: mechanisms for supporting or implementing the cryptographic protection of backup information]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=CP-09 CP-09], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=CP-09 CP-09(08)]

{{anchor|d30e5201-Head2}}{{anchor|sec-sec_3.9}}== 3.9 [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PS Personnel Security] ==

{{anchor|d30e5206-Head3}}{{anchor|sec-sec_03.09.01}}=== 03.09.01 Personnel Screening ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.09.01.ODP[01]}}A.03.09.01.ODP[01]: '''<nowiki/>'''''conditions that require the rescreening of individuals are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.09.01.a}}A.03.09.01.a:''' individuals are screened prior to authorizing access to the system.
* '''{{anchor|A.03.09.01.b}}A.03.09.01.b:''' individuals are rescreened in accordance with the following conditions: '''''<A.03.09.01.ODP[01]: conditions>'''''.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: personnel security policy and procedures; procedures for personnel screening and rescreening; records of screened personnel; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with personnel security responsibilities; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: processes for personnel screening and rescreening]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=PS-03 PS-03]

{{anchor|d30e5265-Head3}}{{anchor|sec-sec_03.09.02}}=== 03.09.02 Personnel Termination and Transfer ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.09.02.ODP[01]}}A.03.09.02.ODP[01]: '''<nowiki/>'''''the time period within which to disable system access is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.09.02.a.01}}A.03.09.02.a.01:''' upon termination of individual employment, system access is disabled within '''''<A.03.09.02.ODP[01]: time period>'''''.
* '''{{anchor|A.03.09.02.a.02[01]}}A.03.09.02.a.02[01]:''' upon termination of individual employment, authenticators associated with the individual are terminated or revoked.
* '''{{anchor|A.03.09.02.a.02[02]}}A.03.09.02.a.02[02]:''' upon termination of individual employment, credentials associated with the individual are terminated or revoked.
* '''{{anchor|A.03.09.02.a.03}}A.03.09.02.a.03:''' upon termination of individual employment, security-related system property is retrieved.
* '''{{anchor|A.03.09.02.b.01[01]}}A.03.09.02.b.01[01]:''' upon individual reassignment or transfer to other positions in the organization, the ongoing operational need for current logical and physical access authorizations to the system and facility is reviewed.
* '''{{anchor|A.03.09.02.b.01[02]}}A.03.09.02.b.01[02]:''' upon individual reassignment or transfer to other positions in the organization, the ongoing operational need for current logical and physical access authorizations to the system and facility is confirmed.
* '''{{anchor|A.03.09.02.b.02}}A.03.09.02.b.02:''' upon individual reassignment or transfer to other positions in the organization, access authorization is modified to correspond with any changes in operational need.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: personnel security policy and procedures; procedures for personnel termination; records of personnel transfer actions; procedures for personnel transfer; list of system and facility access authorizations; records of personnel termination actions; records of terminated or revoked authenticators or credentials; list of system accounts; records of exit interviews; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with personnel security responsibilities; personnel with account management responsibilities; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: processes for personnel termination; processes for personnel transfer; mechanisms for supporting or implementing personnel transfer notifications; mechanisms for supporting or implementing personnel termination notifications; mechanisms for disabling system access and revoking authenticators]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=PS-04 PS-04], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=PS-05 PS-05]

{{anchor|d30e5354-Head2}}{{anchor|sec-sec_3.10}}== 3.10 [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE Physical Protection] ==

{{anchor|d30e5359-Head3}}{{anchor|sec-sec_03.10.01}}=== 03.10.01 Physical Access Authorizations ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.10.01.ODP[01]}}A.03.10.01.ODP[01]: '''<nowiki/>'''''the frequency at which to review the access list detailing authorized facility access by individuals is defined.'''''
* '''{{anchor|A.03.10.01.a[01]}}A.03.10.01.a[01]:''' a list of individuals with authorized access to the facility where the system resides is developed.
* '''{{anchor|A.03.10.01.a[02]}}A.03.10.01.a[02]:''' a list of individuals with authorized access to the facility where the system resides is approved.
* '''{{anchor|A.03.10.01.a[03]}}A.03.10.01.a[03]:''' a list of individuals with authorized access to the facility where the system resides is maintained.
* '''{{anchor|A.03.10.01.b}}A.03.10.01.b:''' authorization credentials for facility access are issued.
* '''{{anchor|A.03.10.01.c}}A.03.10.01.c:''' the facility access list is reviewed '''''<A.03.10.01.ODP[01]: frequency>'''''.
* '''{{anchor|A.03.10.01.d}}A.03.10.01.d:''' individuals from the facility access list are removed when access is no longer required.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: physical protection policy and procedures; procedures for physical access authorizations; authorized personnel access list; physical access list reviews; physical access termination records; authorization credentials; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with physical access authorization responsibilities; personnel with physical access to the facility where the system resides; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: processes for physical access authorizations; mechanisms for supporting or implementing physical access authorizations]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=PE-02 PE-02]

{{anchor|d30e5437-Head3}}{{anchor|sec-sec_03.10.02}}=== 03.10.02 Monitoring Physical Access ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.10.02.ODP[01]}}A.03.10.02.ODP[01]: '''<nowiki/>'''''the frequency at which to review physical access logs is defined.'''''
* '''{{anchor|A.03.10.02.ODP[02]}}A.03.10.02.ODP[02]: '''<nowiki/>'''''events or potential indications of events requiring physical access logs to be reviewed are defined.'''''
* '''{{anchor|A.03.10.02.a[01]}}A.03.10.02.a[01]:''' physical access to the facility where the system resides is monitored to detect physical security incidents.
* '''{{anchor|A.03.10.02.a[02]}}A.03.10.02.a[02]:''' physical security incidents are responded to.
* '''{{anchor|A.03.10.02.b[01]}}A.03.10.02.b[01]:''' physical access logs are reviewed '''''<A.03.10.02.ODP[01]: frequency>'''''.
* '''{{anchor|A.03.10.02.b[02]}}A.03.10.02.b[02]:''' physical access logs are reviewed upon occurrence of '''''<A.03.10.02.ODP[02]: events or potential indications of events>'''''.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: physical protection policy and procedures; procedures for physical access monitoring; physical access logs or records; physical access monitoring records; physical access log reviews; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with physical access monitoring responsibilities; personnel with incident response responsibilities; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: processes for monitoring physical access; mechanisms for supporting or implementing physical access monitoring; mechanisms for supporting or implementing the review of physical access logs]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=PE-06 PE-06]

{{anchor|d30e5514-Head3}}{{anchor|sec-sec_03.10.03}}=== 03.10.03 Withdrawn ===

Incorporated into [[#sec-sec_03.10.07|03.10.07]].

{{anchor|d30e5525-Head3}}{{anchor|sec-sec_03.10.04}}=== 03.10.04 Withdrawn ===

Incorporated into [[#sec-sec_03.10.07|03.10.07]].

{{anchor|d30e5535-Head3}}{{anchor|sec-sec_03.10.05}}=== 03.10.05 Withdrawn ===

Incorporated into [[#sec-sec_03.10.07|03.10.07]].

{{anchor|d30e5545-Head3}}{{anchor|sec-sec_03.10.06}}=== 03.10.06 Alternate Work Site ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.10.06.ODP[01]}}A.03.10.06.ODP[01]: '''<nowiki/>'''''security requirements to be employed at alternate work sites are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.10.06.a}}A.03.10.06.a:''' alternate work sites allowed for use by employees are determined.
* '''{{anchor|A.03.10.06.b}}A.03.10.06.b:''' the following security requirements are employed at alternate work sites: '''''<A.03.10.06.ODP[01]: security requirements>'''''.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: physical protection policy and procedures; procedures for alternate work sites for personnel; list of security requirements for alternate work sites; assessments of security requirements at alternate work sites; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel approving the use of alternate work sites; personnel using alternate work sites; personnel assessing security requirements at alternate work sites; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: processes for security at alternate work sites; mechanisms for supporting alternate work sites; security requirements employed at alternate work sites; means of communication between personnel at alternate work sites and security personnel]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=PE-17 PE-17]

{{anchor|d30e5604-Head3}}{{anchor|sec-sec_03.10.07}}=== 03.10.07 Physical Access Control ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.10.07.a.01}}A.03.10.07.a.01:''' physical access authorizations are enforced at entry and exit points to the facility where the system resides by verifying individual physical access authorizations before granting access.
* '''{{anchor|A.03.10.07.a.02}}A.03.10.07.a.02:''' physical access authorizations are enforced at entry and exit points to the facility where the system resides by controlling ingress and egress with physical access control systems, devices, or guards.
* '''{{anchor|A.03.10.07.b}}A.03.10.07.b:''' physical access audit logs for entry or exit points are maintained.
* '''{{anchor|A.03.10.07.c[01]}}A.03.10.07.c[01]:''' visitors are escorted.
* '''{{anchor|A.03.10.07.c[02]}}A.03.10.07.c[02]:''' visitor activity is controlled.
* '''{{anchor|A.03.10.07.d}}A.03.10.07.d:''' keys, combinations, and other physical access devices are secured.
* '''{{anchor|A.03.10.07.e}}A.03.10.07.e:''' physical access to output devices is controlled to prevent unauthorized individuals from obtaining access to CUI.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: physical protection policy and procedures; procedures for physical access control; physical access control logs or records; inventory records of physical access control devices; system entry and exit points; records of key and lock combination changes; storage locations for physical access control devices; physical access control devices; list of security safeguards controlling access to designated publicly accessible areas within facility; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with physical access control responsibilities; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: processes for physical access control; mechanisms for supporting or implementing physical access control; physical access control devices]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-03 PE-03], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-05 PE-05]

{{anchor|d30e5681-Head3}}{{anchor|sec-sec_03.10.08}}=== 03.10.08 Access Control for Transmission ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''A.03.10.08:''' physical access to system distribution and transmission lines within organizational facilities is controlled.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: physical protection policy and procedures; procedures for access control for transmission mediums; system design documentation; facility communications and wiring diagrams; list of physical security safeguards applied to system distribution and transmission lines; procedures for access control for display medium; facility layout of system components; list of output devices and associated outputs that require physical access controls; actual displays from system components; physical access control logs or records for areas containing output devices and related outputs; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with physical access control responsibilities; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: processes for access control for distribution and transmission lines; mechanisms for supporting or implementing access control for distribution and transmission lines; processes for access control to output devices; mechanisms for supporting or implementing access control for output devices]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=PE-04 PE-04]

{{anchor|d30e5722-Head2}}{{anchor|sec-sec_3.11}}== 3.11 [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=RA Risk Assessment] ==

{{anchor|d30e5727-Head3}}{{anchor|sec-sec_03.11.01}}=== 03.11.01 Risk Assessment ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.11.01.ODP[01]}}A.03.11.01.ODP[01]: '''<nowiki/>'''''the frequency at which to update the risk assessment is defined.'''''
* '''{{anchor|A.03.11.01.a}}A.03.11.01.a:''' the risk (including supply chain risk) of unauthorized disclosure resulting from the processing, storage, or transmission of CUI is assessed.
* '''{{anchor|A.03.11.01.b}}A.03.11.01.b:''' risk assessments are updated '''''<A.03.11.01.ODP[01]: frequency>'''''.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: risk assessment policy and procedures; security planning policy and procedures; procedures for organizational assessments of risk; risk assessment; risk assessment results; risk assessment reviews; risk assessment updates; SCRM policy and procedures; inventory of critical systems, system components, and system services; procedures for organizational assessments of supply chain risk; acquisition policy; SCRM plan; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with risk assessment responsibilities; personnel with SCRM responsibilities; personnel with security responsibilities]

===== Test =====

[SELECT FROM: processes for organizational risk assessments; mechanisms for supporting or conducting, documenting, reviewing, disseminating, and updating risk assessments; mechanisms for supporting or conducting, documenting, reviewing, disseminating, and updating supply chain risk assessments]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=RA-03 RA-03], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=RA-03 RA-03(01)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SR-06 SR-06]

{{anchor|d30e5793-Head3}}{{anchor|sec-sec_03.11.02}}=== 03.11.02 Vulnerability Monitoring and Scanning ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.11.02.ODP[01]}}A.03.11.02.ODP[01]: '''<nowiki/>'''''the frequency at which the system is monitored for vulnerabilities is defined.'''''
* '''{{anchor|A.03.11.02.ODP[02]}}A.03.11.02.ODP[02]: '''<nowiki/>'''''the frequency at which the system is scanned for vulnerabilities is defined.'''''
* '''{{anchor|A.03.11.02.ODP[03]}}A.03.11.02.ODP[03]: '''<nowiki/>'''''response times to remediate system vulnerabilities are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.11.02.ODP[04]}}A.03.11.02.ODP[04]: '''<nowiki/>'''''the frequency at which to update system vulnerabilities to be scanned is defined.'''''
* '''{{anchor|A.03.11.02.a[01]}}A.03.11.02.a[01]:''' the system is monitored for vulnerabilities '''''<A.03.11.02.ODP[01]: frequency>'''''.
* '''{{anchor|A.03.11.02.a[02]}}A.03.11.02.a[02]:''' the system is scanned for vulnerabilities '''''<A.03.11.02.ODP[02]: frequency>'''''.
* '''{{anchor|A.03.11.02.a[03]}}A.03.11.02.a[03]:''' the system is monitored for vulnerabilities when new vulnerabilities that affect the system are identified.
* '''{{anchor|A.03.11.02.a[04]}}A.03.11.02.a[04]:''' the system is scanned for vulnerabilities when new vulnerabilities that affect the system are identified.
* '''{{anchor|A.03.11.02.b}}A.03.11.02.b:''' system vulnerabilities are remediated within '''''<A.03.11.02.ODP[03]: response times>'''''.
* '''{{anchor|A.03.11.02.c[01]}}A.03.11.02.c[01]:''' system vulnerabilities to be scanned are updated '''''<A.03.11.02.ODP[04]: frequency>'''''.
* '''{{anchor|A.03.11.02.c[02]}}A.03.11.02.c[02]:''' system vulnerabilities to be scanned are updated when new vulnerabilities are identified and reported.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: risk assessment policy and procedures; procedures for vulnerability scanning; patch and vulnerability management records; vulnerability scanning tools and configuration documentation; vulnerability scanning results; risk assessment; risk assessment report; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with risk assessment and vulnerability scanning responsibilities; personnel with vulnerability scan analysis responsibilities; personnel with vulnerability remediation responsibilities; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: processes for vulnerability monitoring, scanning, analysis, and remediation; mechanisms for supporting or implementing vulnerability monitoring, scanning, analysis, and remediation]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=RA-05 RA-05], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=RA-05 RA-05(02)]

{{anchor|d30e5912-Head3}}{{anchor|sec-sec_03.11.03}}=== 03.11.03 Withdrawn ===

Incorporated into [[#sec-sec_03.11.02|03.11.02]].

{{anchor|d30e5922-Head3}}{{anchor|sec-sec_03.11.04}}=== 03.11.04 Risk Response ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''A.03.11.04[01]:''' findings from security assessments are responded to.
* '''A.03.11.04[02]:''' findings from security monitoring are responded to.
* '''A.03.11.04[03]:''' findings from security audits are responded to.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: risk assessment policy; assessment reports; system audit records; event logs; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with assessment and auditing responsibilities; system administrators; personnel with security responsibilities]

===== Test =====

[SELECT FROM: processes for assessments and audits; mechanisms and tools supporting or implementing assessments and auditing]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=RA-07 RA-07]

{{anchor|d30e5971-Head2}}{{anchor|sec-sec_3.12}}== 3.12 [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CA Security Assessment and Monitoring] ==

{{anchor|d30e5976-Head3}}{{anchor|sec-sec_03.12.01}}=== 03.12.01 Security Assessment ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.12.01.ODP[01]}}A.03.12.01.ODP[01]: '''<nowiki/>'''''the frequency at which to assess the security requirements for the system and its environment of operation is defined.'''''
* '''A.03.12.01:''' the security requirements for the system and its environment of operation are assessed '''''<A.03.12.01.ODP[01]: frequency>''''' to determine if the requirements have been satisfied.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: security assessment and monitoring policy and procedures; procedures for security assessment planning; security assessment plan; security assessment report; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with security assessment responsibilities; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: mechanisms for supporting security assessments, processes for security assessment plan development, or security assessment reporting]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=CA-02 CA-02]

{{anchor|d30e6028-Head3}}{{anchor|sec-sec_03.12.02}}=== 03.12.02 Plan of Action and Milestones ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.12.02.a.01}}A.03.12.02.a.01:''' a plan of action and milestones for the system is developed to document the planned remediation actions for correcting weaknesses or deficiencies noted during security assessments.
* '''{{anchor|A.03.12.02.a.02}}A.03.12.02.a.02:''' a plan of action and milestones for the system is developed to reduce or eliminate known system vulnerabilities.
* '''{{anchor|A.03.12.02.b.01}}A.03.12.02.b.01:''' the existing plan of action and milestones is updated based on the findings from security assessments.
* '''{{anchor|A.03.12.02.b.02}}A.03.12.02.b.02:''' the existing plan of action and milestones is updated based on the findings from audits or reviews.
* '''{{anchor|A.03.12.02.b.03}}A.03.12.02.b.03:''' the existing plan of action and milestones is updated based on the findings from continuous monitoring activities.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: security assessment and monitoring policy and procedures; procedures for plans of action and milestones; security assessment plan; security assessment report; security assessment evidence; plan of action and milestones; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with plans of action and milestones development and implementation responsibilities; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: mechanisms for developing, implementing, and maintaining plans of action and milestones]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=CA-05 CA-05]

{{anchor|d30e6090-Head3}}{{anchor|sec-sec_03.12.03}}=== 03.12.03 Continuous Monitoring ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''A.03.12.03[01]:''' a system-level continuous monitoring strategy is developed.
* '''A.03.12.03[02]:''' a system-level continuous monitoring strategy is implemented.
* '''A.03.12.03[03]:''' ongoing monitoring is included in the continuous monitoring strategy.
* '''A.03.12.03[04]:''' security assessments are included in the continuous monitoring strategy.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: security assessment and monitoring policy and procedures; organizational continuous monitoring strategy; system-level continuous monitoring strategy; procedures for continuous monitoring of the system; procedures for configuration management; security assessment report; plan of action and milestones; system monitoring records; configuration management records; impact analyses; status reports; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with continuous monitoring responsibilities; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: mechanisms for implementing continuous monitoring; mechanisms for supporting response actions for assessment and monitoring results; mechanisms for supporting security status reporting]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=CA-07 CA-07]

{{anchor|d30e6144-Head3}}{{anchor|sec-sec_03.12.04}}=== 03.12.04 Withdrawn ===

Incorporated into [[#sec-sec_03.15.02|03.15.02]].

{{anchor|d30e6154-Head3}}{{anchor|sec-sec_03.12.05}}=== 03.12.05 Information Exchange ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.12.05.ODP[01]}}A.03.12.05.ODP[01]: '''<nowiki/>'''''one or more of the following PARAMETER VALUES are selected: {interconnection security agreements; information exchange security agreements; memoranda of understanding or agreement; service-level agreements; user agreements; non-disclosure agreements'''''; '''''other types of agreements}'''''.
* '''{{anchor|A.03.12.05.ODP[02]}}A.03.12.05.ODP[02]: '''<nowiki/>'''''the frequency at which to review and update agreements is defined.'''''
* '''{{anchor|A.03.12.05.a[01]}}A.03.12.05.a[01]:''' the exchange of CUI between the system and other systems is approved using '''''<A.03.12.05.ODP[01]: SELECTED PARAMETER VALUES>'''''.
* '''{{anchor|A.03.12.05.a[02]}}A.03.12.05.a[02]:''' the exchange of CUI between the system and other systems is managed using '''''<A.03.12.05.ODP[01]: SELECTED PARAMETER VALUES>'''''.
* '''{{anchor|A.03.12.05.b[01]}}A.03.12.05.b[01]:''' interface characteristics for each system are documented as part of the exchange agreements.
* '''{{anchor|A.03.12.05.b[02]}}A.03.12.05.b[02]:''' security requirements for each system are documented as part of the exchange agreements.
* '''{{anchor|A.03.12.05.b[03]}}A.03.12.05.b[03]:''' responsibilities for each system are documented as part of the exchange agreements.
* '''{{anchor|A.03.12.05.c[01]}}A.03.12.05.c[01]:''' exchange agreements are reviewed '''''<A.03.12.05.ODP[02]: frequency>'''''.
* '''{{anchor|A.03.12.05.c[02]}}A.03.12.05.c[02]:''' exchange agreements are updated '''''<A.03.12.05.ODP[02]: frequency>'''''.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: access control policy and procedures; procedures for system connections; system and communications protection policy and procedures; system interconnection security agreements; information exchange security agreements; service-level agreements; memoranda of understanding or agreements; non-disclosure agreements; system design documentation; enterprise architecture; security architecture; system configuration settings; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with development, implementation, and approval responsibilities for system interconnection agreements; personnel who manage systems to which the exchange agreements apply; personnel with information security responsibilities]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=CA-03 CA-03]

{{anchor|d30e6252-Head2}}{{anchor|sec-sec_3.13}}== 3.13 [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC System and Communications Protection] ==

{{anchor|d30e6257-Head3}}{{anchor|sec-sec_03.13.01}}=== 03.13.01 Boundary Protection ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.13.01.a[01]}}A.03.13.01.a[01]:''' communications at external managed interfaces to the system are monitored.
* '''{{anchor|A.03.13.01.a[02]}}A.03.13.01.a[02]:''' communications at external managed interfaces to the system are controlled.
* '''{{anchor|A.03.13.01.a[03]}}A.03.13.01.a[03]:''' communications at key internal managed interfaces within the system are monitored.
* '''{{anchor|A.03.13.01.a[04]}}A.03.13.01.a[04]:''' communications at key internal managed interfaces within the system are controlled.
* '''{{anchor|A.03.13.01.b}}A.03.13.01.b:''' subnetworks are implemented for publicly accessible system components that are physically or logically separated from internal networks.
* '''{{anchor|A.03.13.01.c}}A.03.13.01.c:''' external system connections are only made through managed interfaces that consist of boundary protection devices arranged in accordance with an organizational security architecture.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: system and communications protection policy and procedures; procedures for boundary protection; list of key internal boundaries within the system; boundary protection hardware and software; system configuration settings; security architecture; system audit records; system design documentation; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with boundary protection responsibilities; personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: mechanisms for implementing boundary protection capabilities]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SC-07 SC-07]

{{anchor|d30e6324-Head3}}{{anchor|sec-sec_03.13.02}}=== 03.13.02 Withdrawn ===

Recategorized as NCO.

{{anchor|d30e6332-Head3}}{{anchor|sec-sec_03.13.03}}=== 03.13.03 Withdrawn ===

Addressed by [[#sec-sec_03.01.01|03.01.01]], [[#sec-sec_03.01.02|03.01.02]], [[#sec-sec_03.01.03|03.01.03]], [[#sec-sec_03.01.04|03.01.04]], [[#sec-sec_03.01.05|03.01.05]], [[#sec-sec_03.01.06|03.01.06]], and [[#sec-sec_03.01.07|03.01.07]].

{{anchor|d30e6361-Head3}}{{anchor|sec-sec_03.13.04}}=== 03.13.04 Information in Shared System Resources ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''A.03.13.04[01]:''' unauthorized information transfer via shared system resources is prevented.
* '''A.03.13.04[02]:''' unintended information transfer via shared system resources is prevented.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: system and communications protection policy and procedures; procedures for information protection in shared system resources; system configuration settings; system audit records; system design documentation; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: mechanisms for preventing the unauthorized and unintended transfer of information via shared system resources]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SC-04 SC-04]

{{anchor|d30e6406-Head3}}{{anchor|sec-sec_03.13.05}}=== 03.13.05 Withdrawn ===

Incorporated into [[#sec-sec_03.13.01|03.13.01]].

{{anchor|d30e6416-Head3}}{{anchor|sec-sec_03.13.06}}=== 03.13.06 Network Communications – Deny by Default – Allow by Exception ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''A.03.13.06[01]:''' network communications traffic is denied by default.
* '''A.03.13.06[02]:''' network communications traffic is allowed by exception.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: system and communications protection policy and procedures; procedures for boundary protection; system design documentation; system configuration settings; system audit records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with boundary protection responsibilities; personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: mechanisms for implementing traffic management at managed interfaces]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SC-07 SC-07(05)]

{{anchor|d30e6461-Head3}}{{anchor|sec-sec_03.13.07}}=== 03.13.07 Withdrawn ===

Addressed by [[#sec-sec_03.01.12|03.01.12]], [[#sec-sec_03.04.02|03.04.02]] and [[#sec-sec_03.04.06|03.04.06]].

{{anchor|d30e6478-Head3}}{{anchor|sec-sec_03.13.08}}=== 03.13.08 Transmission and Storage Confidentiality ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''A.03.13.08[01]:''' cryptographic mechanisms are implemented to prevent the unauthorized disclosure of CUI during transmission.
* '''A.03.13.08[02]:''' cryptographic mechanisms are implemented to prevent the unauthorized disclosure of CUI while in storage.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: system and communications protection policy and procedures; procedures for transmission confidentiality; procedures for the protection of information at rest; system design documentation; system configuration settings; cryptographic mechanisms and associated configuration documentation; information in storage requiring confidentiality protection; system audit records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: mechanisms for supporting or implementing transmission confidentiality; cryptographic mechanisms for supporting or implementing transmission confidentiality; mechanisms for supporting or implementing confidentiality protection for information in storage; cryptographic mechanisms for implementing confidentiality protections for information in storage]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SC-08 SC-08], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SC-08 SC-08(01)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SC-28 SC-28], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SC-28 SC-28(01)]

{{anchor|d30e6535-Head3}}{{anchor|sec-sec_03.13.09}}=== 03.13.09 Network Disconnect ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.13.09.ODP[01]}}A.03.13.09.ODP[01]: '''<nowiki/>'''''the time period of inactivity after which the system terminates a network connection associated with a communications session is defined.'''''
* '''A.03.13.09:''' the network connection associated with a communications session is terminated at the end of the session or after '''''<A.03.13.09.ODP[01]: time period>''''' of inactivity.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: system and communications protection policy and procedures; procedures for network disconnect; system design documentation; system configuration settings; system audit records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: mechanisms for supporting or implementing a network disconnect capability]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SC-10 SC-10]

{{anchor|d30e6586-Head3}}{{anchor|sec-sec_03.13.10}}=== 03.13.10 Cryptographic Key Establishment and Management ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.13.10.ODP[01]}}A.03.13.10.ODP[01]: '''<nowiki/>'''''requirements for key generation, distribution, storage, access, and destruction are defined.'''''
* '''A.03.13.10[01]:''' cryptographic keys are established in the system in accordance with the following key management requirements: '''''<A.03.13.10.ODP[01]: requirements>'''''.
* '''A.03.13.10[02]:''' cryptographic keys are managed in the system in accordance with the following key management requirements: '''''<A.03.13.10.ODP[01]: requirements>'''''.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: system and communications protection policy and procedures; procedures for cryptographic key establishment and management; system design documentation; system configuration settings; cryptographic mechanisms; system audit records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with responsibilities for cryptographic key establishment or management; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: mechanisms for supporting or implementing cryptographic key establishment and management]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SC-12 SC-12]

{{anchor|d30e6645-Head3}}{{anchor|sec-sec_03.13.11}}=== 03.13.11 Cryptographic Protection ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.13.11.ODP[01]}}A.03.13.11.ODP[01]: '''<nowiki/>'''''the types of cryptography for protecting the confidentiality of CUI are defined'''''<nowiki/>'''.'''
* '''A.03.13.11:''' the following types of cryptography are implemented to protect the confidentiality of CUI: '''''<A.03.13.11.ODP[01]: types of cryptography>'''''.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: system and communications protection policy and procedures; procedures for cryptographic protection; system design documentation; system configuration settings; cryptographic module validation certificates; list of FIPS-validated cryptographic modules; system audit records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with responsibilities for cryptographic protection; personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: mechanisms for supporting or implementing cryptographic protection]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SC-13 SC-13]

{{anchor|d30e6698-Head3}}{{anchor|sec-sec_03.13.12}}=== 03.13.12 Collaborative Computing Devices and Applications ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.13.12.ODP[01]}}A.03.13.12.ODP[01]: '''<nowiki/>'''''exceptions where remote activation is to be allowed are defined.'''''
* '''{{anchor|A.03.13.12.a}}A.03.13.12.a:''' the remote activation of collaborative computing devices and applications is prohibited with the following exceptions: '''''<A.03.13.12.ODP[01]: exceptions>'''''.
* '''{{anchor|A.03.13.12.b}}A.03.13.12.b:''' an explicit indication of use is provided to users who are physically present at the devices.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: system and communications protection policy and procedures; procedures for collaborative computing; access control policy and procedures; system configuration settings; system design documentation; system audit records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with responsibilities for managing collaborative computing devices; personnel with information security responsibilities; system developers; system administrators]

===== Test =====

[SELECT FROM: mechanisms for supporting or implementing the management of remote activation of collaborative computing devices; mechanisms for providing an indication of use of collaborative computing devices]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SC-15 SC-15]

{{anchor|d30e6755-Head3}}{{anchor|sec-sec_03.13.13}}=== 03.13.13 Mobile Code ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.13.13.a[01]}}A.03.13.13.a[01]:''' acceptable mobile code is defined.
* '''{{anchor|A.03.13.13.a[02]}}A.03.13.13.a[02]:''' acceptable mobile code technologies are defined.
* '''{{anchor|A.03.13.13.b[01]}}A.03.13.13.b[01]:''' the use of mobile code is authorized.
* '''{{anchor|A.03.13.13.b[02]}}A.03.13.13.b[02]:''' the use of mobile code is monitored.
* '''{{anchor|A.03.13.13.b[03]}}A.03.13.13.b[03]:''' the use of mobile code is controlled.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: system and communications protection policy and procedures; procedures for mobile code; mobile code implementation policy and procedures; list of acceptable mobile code and mobile code technologies; authorization records; system monitoring records; system audit records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with responsibilities for managing mobile code; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: processes for authorizing, monitoring, and controlling mobile code; mechanisms for supporting or implementing the management of mobile code; mechanisms for supporting or implementing mobile code monitoring]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SC-18 SC-18]

{{anchor|d30e6818-Head3}}{{anchor|sec-sec_03.13.14}}=== 03.13.14 Withdrawn ===

Technology-specific.

{{anchor|d30e6825-Head3}}{{anchor|sec-sec_03.13.15}}=== 03.13.15 Session Authenticity ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''A.03.13.15:''' the authenticity of communications sessions is protected.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: system and communications protection policy and procedures; procedures for session authenticity; system design documentation; system configuration settings; system audit records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: mechanisms for supporting or implementing session authenticity]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SC-23 SC-23]

{{anchor|d30e6866-Head3}}{{anchor|sec-sec_03.13.16}}=== 03.13.16 Withdrawn ===

Incorporated into [[#sec-sec_03.13.08|03.13.08]].

{{anchor|d30e6876-Head2}}{{anchor|sec-sec_3.14}}== 3.14 [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI System and Information Integrity] ==

{{anchor|d30e6881-Head3}}{{anchor|sec-sec_03.14.01}}=== 03.14.01 Flaw Remediation ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.14.01.ODP[01]}}A.03.14.01.ODP[01]: '''<nowiki/>'''''the time period within which to install security-relevant software updates after the release of the updates is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.14.01.ODP[02]}}A.03.14.01.ODP[02]: '''<nowiki/>'''''the time period within which to install security-relevant firmware updates after the release of the updates is defined.'''''
* '''{{anchor|A.03.14.01.a[01]}}A.03.14.01.a[01]:''' system flaws are identified.
* '''{{anchor|A.03.14.01.a[02]}}A.03.14.01.a[02]:''' system flaws are reported.
* '''{{anchor|A.03.14.01.a[03]}}A.03.14.01.a[03]:''' system flaws are corrected.
* '''{{anchor|A.03.14.01.b[01]}}A.03.14.01.b[01]:''' security-relevant software updates are installed within '''''<A.03.14.01.ODP[01]: time period>''''' of the release of the updates.
* '''{{anchor|A.03.14.01.b[02]}}A.03.14.01.b[02]:''' security-relevant firmware updates are installed within '''''<A.03.14.01.ODP[02]: time period>''''' of the release of the updates.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: system and information integrity policy and procedures; procedures for flaw remediation; procedures for configuration management; list of recent security flaw remediation actions performed on the system; list of flaws and vulnerabilities that may potentially affect the system; test results from the installation of software and firmware updates to correct system flaws; installation and change control records for security-relevant software and firmware updates; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel responsible for installing, configuring, or maintaining the system; personnel responsible for flaw remediation; personnel with configuration management responsibilities; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: processes for identifying, reporting, and correcting system flaws; processes for installing software and firmware updates; mechanisms for supporting or implementing the reporting and correction of system flaws; mechanisms for supporting or implementing the testing software and firmware updates]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SI-02 SI-02]

{{anchor|d30e6966-Head3}}{{anchor|sec-sec_03.14.02}}=== 03.14.02 Malicious Code Protection ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.14.02.ODP[01]}}A.03.14.02.ODP[01]: '''<nowiki/>'''''the frequency at which malicious code protection mechanisms perform scans is defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.14.02.a[01]}}A.03.14.02.a[01]:''' malicious code protection mechanisms are implemented at system entry and exit points to detect malicious code.
* '''{{anchor|A.03.14.02.a[02]}}A.03.14.02.a[02]:''' malicious code protection mechanisms are implemented at system entry and exit points to eradicate malicious code.
* '''{{anchor|A.03.14.02.b}}A.03.14.02.b:''' malicious code protection mechanisms are updated as new releases are available in accordance with configuration management policy and procedures.
* '''{{anchor|A.03.14.02.c.01[01]}}A.03.14.02.c.01[01]:''' malicious code protection mechanisms are configured to perform scans of the system '''''<A.03.14.02.ODP[01]: frequency>'''''.
* '''{{anchor|A.03.14.02.c.01[02]}}A.03.14.02.c.01[02]:''' malicious code protection mechanisms are configured to perform real-time scans of files from external sources at endpoints or system entry and exit points as the files are downloaded, opened, or executed.
* '''{{anchor|A.03.14.02.c.02}}A.03.14.02.c.02:''' malicious code protection mechanisms are configured to block malicious code, quarantine malicious code, or take other actions in response to malicious code detection.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: system and information integrity policy and procedures; configuration management policy and procedures; procedures for malicious code protection; records of malicious code protection updates; system design documentation; system configuration settings; scan results from malicious code protection mechanisms; record of actions initiated by malicious code protection mechanisms in response to malicious code detection; system audit records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel responsible for malicious code protection; personnel with system installation, configuration, or maintenance responsibilities; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: processes for employing, updating, and configuring malicious code protection mechanisms; processes for addressing the detection of false positives and resulting potential impacts; mechanisms for supporting or implementing, employing, updating, and configuring malicious code protection mechanisms; mechanisms for supporting or implementing malicious code scanning and the execution of subsequent actions]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SI-03 SI-03]

{{anchor|d30e7046-Head3}}{{anchor|sec-sec_03.14.03}}=== 03.14.03 Security Alerts, Advisories, and Directives ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.14.03.a}}A.03.14.03.a:''' system security alerts, advisories, and directives from external organizations are received on an ongoing basis.
* '''{{anchor|A.03.14.03.b[01]}}A.03.14.03.b[01]:''' internal security alerts, advisories, and directives are generated, as necessary.
* '''{{anchor|A.03.14.03.b[02]}}A.03.14.03.b[02]:''' internal security alerts, advisories, and directives are disseminated, as necessary.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: system and information integrity policy and procedures; procedures for security alerts, advisories, and directives; records of security alerts and advisories; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with security alert and advisory responsibilities; personnel implementing, operating, maintaining, and using the system; personnel, organizational elements, or external organizations to whom alerts, advisories, and directives are to be disseminated; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: processes for defining, receiving, generating, disseminating, and complying with security alerts, advisories, and directives; mechanisms for supporting or implementing security directives; mechanisms for supporting or implementing the definition, receipt, generation, and dissemination of security alerts, advisories, and directives]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SI-05 SI-05]

{{anchor|d30e7098-Head3}}{{anchor|sec-sec_03.14.04}}=== 03.14.04 Withdrawn ===

Incorporated into [[#sec-sec_03.14.02|03.14.02]].

{{anchor|d30e7108-Head3}}{{anchor|sec-sec_03.14.05}}=== 03.14.05 Withdrawn ===

Addressed by [[#sec-sec_03.14.02|03.14.02]].

{{anchor|d30e7119-Head3}}{{anchor|sec-sec_03.14.06}}=== 03.14.06 System Monitoring ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.14.06.a.01[01]}}A.03.14.06.a.01[01]:''' the system is monitored to detect attacks.
* '''{{anchor|A.03.14.06.a.01[02]}}A.03.14.06.a.01[02]:''' the system is monitored to detect indicators of potential attacks.
* '''{{anchor|A.03.14.06.a.02}}A.03.14.06.a.02:''' the system is monitored to detect unauthorized connections.
* '''{{anchor|A.03.14.06.b}}A.03.14.06.b:''' unauthorized use of the system is identified.
* '''{{anchor|A.03.14.06.c[01]}}A.03.14.06.c[01]:''' inbound communications traffic is monitored to detect unusual or unauthorized activities or conditions.
* '''{{anchor|A.03.14.06.c[02]}}A.03.14.06.c[02]:''' outbound communications traffic is monitored to detect unusual or unauthorized activities or conditions.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: system and information integrity policy and procedures; procedures for system monitoring tools and techniques; continuous monitoring strategy; facility diagram or layout; system design documentation; locations within the system where monitoring devices are deployed; system configuration settings; system protocols; system audit records; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with responsibilities for installing, configuring, or maintaining the system; personnel with system monitoring responsibilities; personnel with intrusion detection responsibilities; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: processes for intrusion detection and system monitoring; mechanisms for supporting or implementing system monitoring capabilities; mechanisms for supporting or implementing intrusion detection and system monitoring capabilities; mechanisms for supporting or implementing the monitoring of inbound and outbound communications traffic]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SI-04 SI-04], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SI-04 SI-04(04)]

{{anchor|d30e7190-Head3}}{{anchor|sec-sec_03.14.07}}=== 03.14.07 Withdrawn ===

Incorporated into [[#sec-sec_03.14.06|03.14.06]].

{{anchor|d30e7200-Head3}}{{anchor|sec-sec_03.14.08}}=== 03.14.08 Information Management and Retention ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''A.03.14.08[01]:''' CUI within the system is managed in accordance with applicable laws, Executive Orders, directives, regulations, policies, standards, guidelines, and operational requirements.
* '''A.03.14.08[02]:''' CUI within the system is retained in accordance with applicable laws, Executive Orders, directives, regulations, policies, standards, guidelines, and operational requirements.
* '''A.03.14.08[03]:''' CUI output from the system is managed in accordance with applicable laws, Executive Orders, directives, regulations, policies, standards, guidelines, and operational requirements.
* '''A.03.14.08[04]:''' CUI output from the system is retained in accordance with applicable laws, Executive Orders, directives, regulations, policies, standards, guidelines, and operational requirements.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: system and information integrity policy and procedures; laws, Executive Orders, directives, policies, regulations, standards, and operational requirements applicable to information management and retention; records retention and disposition policy; records retention and disposition procedures; media protection policy; media protection procedures; audit findings; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with information and records management, retention, and disposition responsibilities; personnel with information security responsibilities; system administrators]

===== Test =====

[SELECT FROM: processes for information management, retention, and disposition; mechanisms for supporting or implementing information management, retention, and disposition]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SI-12 SI-12]

{{anchor|d30e7254-Head2}}{{anchor|sec-sec_3.15}}== 3.15 [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PL Planning] ==

{{anchor|d30e7259-Head3}}{{anchor|sec-sec_03.15.01}}=== 03.15.01 Policy and Procedures ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.15.01.ODP[01]}}A.03.15.01.ODP[01]: '''<nowiki/>'''''the frequency at which the policies and procedures for satisfying security requirements are reviewed and updated is defined.'''''
* '''{{anchor|A.03.15.01.a[01]}}A.03.15.01.a[01]:''' policies needed to satisfy the security requirements for the protection of CUI are developed and documented.
* '''{{anchor|A.03.15.01.a[02]}}A.03.15.01.a[02]:''' policies needed to satisfy the security requirements for the protection of CUI are disseminated to organizational personnel or roles.
* '''{{anchor|A.03.15.01.a[03]}}A.03.15.01.a[03]:''' procedures needed to satisfy the security requirements for the protection of CUI are developed and documented.
* '''{{anchor|A.03.15.01.a[04]}}A.03.15.01.a[04]:''' procedures needed to satisfy the security requirements for the protection of CUI are disseminated to organizational personnel or roles.
* '''{{anchor|A.03.15.01.b[01]}}A.03.15.01.b[01]:''' policies and procedures are reviewed '''''<A.03.15.01.ODP[01]: frequency>'''''.
* '''{{anchor|A.03.15.01.b[02]}}A.03.15.01.b[02]:''' policies and procedures are updated '''''<A.03.15.01.ODP[01]: frequency>'''''.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: security policies and procedures associated with the protection of CUI; audit findings; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with information security responsibilities]

==== REFERENCES ====

Source Assessment Procedures: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AC-01 AC-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AT-01 AT-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=AU-01 AU-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=CA-01 CA-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=CM-01 CM-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=IA-01 IA-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=IR-01 IR-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=MA-01 MA-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=MP-01 MP-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=PE-01 PE-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=PL-01 PL-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=PS-01 PS-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=RA-01 RA-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SA-01 SA-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SC-01 SC-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SI-01 SI-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SR-01 SR-01]

{{anchor|d30e7400-Head3}}{{anchor|sec-sec_03.15.02}}=== 03.15.02 System Security Plan ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.15.02.ODP[01]}}A.03.15.02.ODP[01]: '''<nowiki/>'''''the frequency at which the system security plan is reviewed and updated is defined.'''''
* '''{{anchor|A.03.15.02.a.01}}A.03.15.02.a.01:''' a system security plan that defines the constituent system components is developed.
* '''{{anchor|A.03.15.02.a.02}}A.03.15.02.a.02:''' a system security plan that identifies the information types processed, stored, and transmitted by the system is developed.
* '''{{anchor|A.03.15.02.a.03}}A.03.15.02.a.03:''' a system security plan that describes specific threats to the system that are of concern to the organization is developed.
* '''{{anchor|A.03.15.02.a.04}}A.03.15.02.a.04:''' a system security plan that describes the operational environment for the system and any dependencies on or connections to other systems or system components is developed.
* '''{{anchor|A.03.15.02.a.05}}A.03.15.02.a.05:''' a system security plan that provides an overview of the security requirements for the system is developed.
* '''{{anchor|A.03.15.02.a.06}}A.03.15.02.a.06:''' a system security plan that describes the safeguards in place or planned for meeting the security requirements is developed.
* '''{{anchor|A.03.15.02.a.07}}A.03.15.02.a.07:''' a system security plan that identifies individuals that fulfill system roles and responsibilities is developed.
* '''{{anchor|A.03.15.02.a.08}}A.03.15.02.a.08:''' a system security plan that includes other relevant information necessary for the protection of CUI is developed.
* '''{{anchor|A.03.15.02.b[01]}}A.03.15.02.b[01]:''' the system security plan is reviewed '''''<A.03.15.02.ODP[01]: frequency>'''''.
* '''{{anchor|A.03.15.02.b[02]}}A.03.15.02.b[02]:''' the system security plan is updated '''''<A.03.15.02.ODP[01]: frequency>'''''.
* '''{{anchor|A.03.15.02.c}}A.03.15.02.c:''' the system security plan is protected from unauthorized disclosure.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: security planning policy and procedures; procedures for system security plan development and implementation; procedures for system security plan reviews and updates; enterprise architecture; system security plan; records of system security plan reviews and updates; risk assessments; risk assessment results; security architecture and design documentation; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with system security planning and plan implementation responsibilities; system developers; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: processes for system security plan development, review, update, and approval]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=PL-02 PL-02]

{{anchor|d30e7507-Head3}}{{anchor|sec-sec_03.15.03}}=== 03.15.03 Rules of Behavior ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.15.03.ODP[01]}}A.03.15.03.ODP[01]: '''<nowiki/>'''''the frequency at which the rules of behavior are reviewed and updated is defined.'''''
* '''{{anchor|A.03.15.03.a}}A.03.15.03.a:''' rules that describe responsibilities and expected behavior for system usage and protecting CUI are established.
* '''{{anchor|A.03.15.03.b}}A.03.15.03.b:''' rules are provided to individuals who require access to the system.
* '''{{anchor|A.03.15.03.c}}A.03.15.03.c:''' a documented acknowledgement from individuals indicating that they have read, understand, and agree to abide by the rules of behavior is received before authorizing access to CUI and the system.
* '''{{anchor|A.03.15.03.d[01]}}A.03.15.03.d[01]:''' the rules of behavior are reviewed '''''<A.03.15.03.ODP[01]: frequency>'''''.
* '''{{anchor|A.03.15.03.d[02]}}A.03.15.03.d[02]:''' the rules of behavior are updated '''''<A.03.15.03.ODP[01]: frequency>'''''.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: security planning policy and procedures; rules of behavior for system users; signed acknowledgements of rules of behavior; records for rules of behavior reviews and updates; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with rules of behavior establishment, review, and update responsibilities; personnel with literacy training and awareness responsibilities; personnel with role-based training responsibilities; authorized users of the system who have signed rules of behavior; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: processes for establishing, reviewing, disseminating, and updating rules of behavior; mechanisms for supporting or implementing the establishment, dissemination, review, and update of rules of behavior]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=PL-04 PL-04]

{{anchor|d30e7582-Head2}}{{anchor|sec-sec_3.16}}== 3.16 [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SA System and Services Acquisition] ==

{{anchor|d30e7587-Head3}}{{anchor|sec-sec_03.16.01}}=== 03.16.01 Systems Security Engineering Principles ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.16.01.ODP[01]}}A.03.16.01.ODP[01]: '''<nowiki/>'''''systems security engineering principles to be applied to the development or modification of the system and system components are defined.'''''
* '''A.03.16.01: '''<nowiki/>'''''<A.03.16.01.ODP[01]: systems security engineering principles>''''' are applied to the development or modification of the system and system components.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: system and services acquisition policy; system and services

acquisition procedures; procedures addressing security engineering principles used in the development and modification of the system; system design documentation; security requirements and specifications for the system; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with acquisition/contracting responsibilities; personnel with information security responsibilities; personnel with system development and modification responsibilities; system developers]

===== Test =====

[SELECT FROM: processes for applying security engineering principles in system development and modification; mechanisms supporting the application of security engineering principles in system development and modification]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SA-08 SA-08]

{{anchor|d30e7641-Head3}}{{anchor|sec-sec_03.16.02}}=== 03.16.02 Unsupported System Components ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.16.02.a}}A.03.16.02.a:''' system components are replaced when support for the components is no longer available from the developer, vendor, or manufacturer.
* '''{{anchor|A.03.16.02.b}}A.03.16.02.b:''' options for risk mitigation or alternative sources for continued support for unsupported components that cannot be replaced are provided.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: system and services acquisition policy and procedures; procedures for the replacement or continued use of unsupported system components; documented evidence of replacing unsupported system components; documented approvals (including justification) for the continued use of unsupported system components; SCRM plan; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with system and service acquisition responsibilities; personnel responsible for component replacement; personnel with system development life cycle responsibilities; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: processes for replacing unsupported system components; mechanisms for supporting or implementing the replacement of unsupported system components]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SA-22 SA-22]

{{anchor|d30e7688-Head3}}{{anchor|sec-sec_03.16.03}}=== 03.16.03 External System Services ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.16.03.ODP[01]}}A.03.16.03.ODP[01]: '''<nowiki/>'''''security requirements to be satisfied by external system service providers are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.16.03.a}}A.03.16.03.a:''' the providers of external system services used for the processing, storage, or transmission of CUI comply with the following security requirements: '''''<A.03.16.03.ODP[01]: security requirements>'''''.
* '''{{anchor|A.03.16.03.b}}A.03.16.03.b:''' user roles and responsibilities with regard to external system services, including shared responsibilities with external service providers, are defined and documented.
* '''{{anchor|A.03.16.03.c}}A.03.16.03.c:''' processes, methods, and techniques to monitor security requirement compliance by external service providers on an ongoing basis are implemented.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: system and services acquisition policy and procedures; procedures for monitoring security requirement compliance by external service providers; acquisition documentation; contracts; service-level agreements; interagency agreements; licensing agreements; list of security requirements for external provider services; assessment results or reports from external service providers; SCRM plan; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with acquisition responsibilities; external providers of system services; personnel with SCRM responsibilities; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: organizational processes for monitoring security and privacy control compliance by external service providers on an ongoing basis; mechanisms for monitoring security and privacy control compliance by external service providers on an ongoing basis]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SA-09 SA-09]

{{anchor|d30e7752-Head2}}{{anchor|sec-sec_3.17}}== 3.17 [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SR Supply Chain Risk Management] ==

{{anchor|d30e7758-Head3}}{{anchor|sec-sec_03.17.01}}=== 03.17.01 Supply Chain Risk Management Plan ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.17.01.ODP[01]}}A.03.17.01.ODP[01]: '''<nowiki/>'''''the frequency at which to review and update the supply chain risk management plan is defined.'''''
* '''{{anchor|A.03.17.01.a[01]}}A.03.17.01.a[01]:''' a plan for managing supply chain risks is developed.
* '''{{anchor|A.03.17.01.a[02]}}A.03.17.01.a[02]:''' the SCRM plan addresses risks associated with the research and development of the system, system components, or system services.
* '''{{anchor|A.03.17.01.a[03]}}A.03.17.01.a[03]:''' the SCRM plan addresses risks associated with the design of the system, system components, or system services.
* '''{{anchor|A.03.17.01.a[04]}}A.03.17.01.a[04]:''' the SCRM plan addresses risks associated with the manufacturing of the system, system components, or system services.
* '''{{anchor|A.03.17.01.a[05]}}A.03.17.01.a[05]:''' the SCRM plan addresses risks associated with the acquisition of the system, system components, or system services.
* '''{{anchor|A.03.17.01.a[06]}}A.03.17.01.a[06]:''' the SCRM plan addresses risks associated with the delivery of the system, system components, or system services.
* '''{{anchor|A.03.17.01.a[07]}}A.03.17.01.a[07]:''' the SCRM plan addresses risks associated with the integration of the system, system components, or system services.
* '''{{anchor|A.03.17.01.a[08]}}A.03.17.01.a[08]:''' the SCRM plan addresses risks associated with the operation of the system, system components, or system services.
* '''{{anchor|A.03.17.01.a[09]}}A.03.17.01.a[09]:''' the SCRM plan addresses risks associated with the maintenance of the system, system components, or system services.
* '''{{anchor|A.03.17.01.a}}A.03.17.01.a['''[[#bibr-ref_10|'''10''']]''']:''' the SCRM plan addresses risks associated with the disposal of the system, system components, or system services.
* '''{{anchor|A.03.17.01.b[01]}}A.03.17.01.b[01]:''' the SCRM plan is reviewed '''''<A.03.17.01.ODP[01]: frequency>'''''.
* '''{{anchor|A.03.17.01.b[02]}}A.03.17.01.b[02]:''' the SCRM plan is updated '''''<A.03.17.01.ODP[01]: frequency>'''''.
* '''{{anchor|A.03.17.01.c}}A.03.17.01.c:''' the SCRM plan is protected from unauthorized disclosure.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: SCRM policy and procedures; SCRM plan; system and services acquisition policy and procedures; system and services acquisition procedures; procedures for supply chain protection; procedures for protecting the SCRM plan from unauthorized disclosure; system development life cycle procedures; procedures for the integration of information security requirements into the acquisition process; acquisition documentation; service-level agreements; acquisition contracts for the system, system components, or system services; list of supply chain threats; list of safeguards for supply chain threats; system life cycle documentation, including research and development, design, manufacturing, acquisition, delivery, integration, operations, maintenance, and disposal; inter-organizational agreements and procedures; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with acquisition responsibilities; personnel with SCRM responsibilities; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: organizational processes for defining and documenting the system development life cycle (SDLC); organizational processes for identifying SDLC roles and responsibilities; organizational processes for integrating SCRM into the SDLC; mechanisms for supporting or implementing the SDLC]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SR-02 SR-02]

{{anchor|d30e7879-Head3}}{{anchor|sec-sec_03.17.02}}=== 03.17.02 Acquisition Strategies, Tools, and Methods ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''A.03.17.02[01]:''' acquisition strategies, contract tools, and procurement methods are developed to identify supply chain risks.
* '''A.03.17.02[02]:''' acquisition strategies, contract tools, and procurement methods are developed to protect against supply chain risks.
* '''A.03.17.02[03]:''' acquisition strategies, contract tools, and procurement methods are developed to mitigate supply chain risks.
* '''A.03.17.02[04]:''' acquisition strategies, contract tools, and procurement methods are implemented to identify supply chain risks.
* '''A.03.17.02[05]:''' acquisition strategies, contract tools, and procurement methods are implemented to protect against supply chain risks.
* '''A.03.17.02[06]:''' acquisition strategies, contract tools, and procurement methods are implemented to mitigate supply chain risks.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: SCRM policy and procedures; SCRM plan; system and services acquisition policy and procedures; procedures for supply chain protection; procedures for the integration of information security requirements into the acquisition process; solicitation documentation; acquisition documentation (including purchase orders); service-level agreements; acquisition contracts for the system, system components, or services; documentation of identified supply chain risks; mitigation plans for supply chain risks; documentation of training, education, and awareness programs for personnel regarding supply chain risk; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with acquisition responsibilities; personnel with SCRM responsibilities; personnel with information security responsibilities]

===== Test =====

[SELECT FROM: processes for defining and employing tailored acquisition strategies, contract tools, and procurement methods; mechanisms for implementing tailored acquisition strategies, contract tools, and procurement methods]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SR-05 SR-05]

{{anchor|d30e7941-Head3}}{{anchor|sec-sec_03.17.03}}=== 03.17.03 Supply Chain Requirements and Processes ===

==== ASSESSMENT OBJECTIVE ====

''Determine if:''

* '''{{anchor|A.03.17.03.ODP[01]}}A.03.17.03.ODP[01]: '''<nowiki/>'''''security requirements to protect against supply chain risks to the system, system components, or system services and to limit the harm or consequences from supply chain-related events are defined'''''<nowiki/>'''.'''
* '''{{anchor|A.03.17.03.a[01]}}A.03.17.03.a[01]:''' a process for identifying weaknesses or deficiencies in the supply chain elements and processes is established.
* '''{{anchor|A.03.17.03.a[02]}}A.03.17.03.a[02]:''' a process for addressing weaknesses or deficiencies in the supply chain elements and processes is established.
* '''{{anchor|A.03.17.03.b}}A.03.17.03.b:''' the following security requirements are enforced to protect against supply chain risks to the system, system components, or system services and to limit the harm or consequences of supply chain-related events: '''''<A.03.17.03.ODP[01]: security requirements>'''''.

==== ASSESSMENT METHODS AND OBJECTS ====

===== Examine =====

[SELECT FROM: SCRM policy and procedures; SCRM strategy; SCRM plan; systems and critical system components inventory documentation; system and services acquisition policy and procedures; procedures for the integration of security requirements into the acquisition process; solicitation documentation; acquisition documentation (including purchase orders); shipping and handling procedures; configuration management documentation and records; acquisition contracts for systems or services; service-level agreements; risk register documentation; system security plan; other relevant documents or records]

===== Interview =====

[SELECT FROM: personnel with acquisition responsibilities; personnel with information security responsibilities; personnel with SCRM responsibilities]

===== Test =====

[SELECT FROM: processes for identifying and addressing supply chain element and process deficiencies]

==== REFERENCES ====

Source Assessment Procedure: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_A_5_1_1/home?element=SR-03 SR-03]

{{anchor|d30e8005-BiblioHead}}References

{{anchor|bibr-ref_1}}[1] Federal Information Security Modernization Act (P.L. 113-283), December 2014. Available at https://www.govinfo.gov/app/details/PLAW-113publ283

{{anchor|bibr-ref_2}}[2] Office of Management and Budget Memorandum Circular A-130, Managing Information as a Strategic Resource, July 2016. Available at https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf

{{anchor|bibr-ref_3}}[3] Ross RS, Pillitteri VY, (2024) Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-171r3. https://doi.org/10.6028/NIST.SP.800-171r3

{{anchor|bibr-ref_4}}[4] Joint Task Force Transformation Initiative (2011) Managing Information Security Risk: Organization, Mission, and Information System View. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication ( SP) 800-39. https://doi.org/10.6028/NIST.SP.800-39

{{anchor|bibr-ref_5}}[5] Joint Task Force (2022) Assessing Security and Privacy Controls in Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53A, Rev. 5. https://doi.org/10.6028/NIST.SP.800-53Ar5

{{anchor|bibr-ref_6}}[6] International Organization for Standardization/International Electrotechnical Commission 15408-3:2017, Information technology — Security techniques — Evaluation criteria for IT security — Part 3: Security assurance requirements, April 2017. https://www.commoncriteriaportal.org/files/ccfiles/CCPART3V3.1R5.pdf

{{anchor|bibr-ref_7}}[7] National Institute of Standards and Technology (2019) Security Requirements for Cryptographic Modules. (U.S. Department of Commerce, Washington, D.C.), Federal Information Processing Standards Publication (FIPS) 140-3. https://doi.org/10.6028/NIST.FIPS.140-3

{{anchor|bibr-ref_8}}[8] Joint Task Force (2020) Security and Privacy Controls for Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53, Rev. 5, Includes updates as of December 10, 2020. https://doi.org/10.6028/NIST.SP.800-53r5

{{anchor|bibr-ref_9}}[9] Committee on National Security Systems (2022) Committee on National Security Systems (CNSS) Glossary. (National Security Agency, Fort George G. Meade, MD), CNSS Instruction 4009. Available at https://www.cnss.gov/CNSS/issuances/Instructions.cfm

{{anchor|bibr-ref_10}}[10] Executive Order 13556 (2010) Controlled Unclassified Information. (The White House, 2340 Washington, DC), DCPD-201000942, November 4, 2010. Available at https://www.govinfo.gov/app/details/DCPD-201000942

{{anchor|d30e8109-Appendix_Title}}{{anchor|sec-sec_A}}== Appendix A : Acronyms ==

; CNSS
: Committee on National Security Systems
; CUI
: Controlled Unclassified Information
; FIPS
: Federal Information Processing Standards
; FISMA
: Federal Information Security Modernization Act
; GRC
: Governance, Risk, and Compliance
; ODP
: Organization-Defined Parameter
; OSCAL
: Open Security Controls Assessment Language
; SCRM
: Supply Chain Risk Management
; SDLC
: System Development Life Cycle

{{anchor|d30e8150-Appendix_Title}}{{anchor|sec-sec_B}}== Appendix B : Glossary ==

[[#sec-sec_B|Appendix B]] provides definitions for the terminology used in SP 800-171A. The definitions are consistent with the definitions contained in the Committee on National Security Systems (CNSS) Glossary [[[#bibr-ref_9|9]]] unless otherwise noted.

; agency
: Any executive agency or department, military department, Federal Government corporation, Federal Government-controlled corporation, or other establishment in the Executive Branch of the Federal Government, or any independent regulatory agency. [[[#bibr-ref_2|2]]]
; assessment
: See ''security control assessment''.
; assessor
: See ''security control assessor''.
; controlled unclassified information
: Information that law, regulation, or governmentwide policy requires to have safeguarding or disseminating controls, excluding information that is classified under Executive Order 13526, Classified National Security Information, December 29, 2009, or any predecessor or successor order, or the Atomic Energy Act of 1954, as amended. [[[#bibr-ref_10|10]]]
; information
: Any communication or representation of knowledge such as facts, data, or opinions in any medium or form, including textual, numerical, graphic, cartographic, narrative, electronic, or audiovisual forms. [[[#bibr-ref_2|2]]]
; nonfederal organization
: An entity that owns, operates, or maintains a nonfederal system.
; nonfederal system
: A system that does not meet the criteria for a federal system.
; risk
: A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically is a function of: (i) the adverse impact, or magnitude of harm, that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. [[[#bibr-ref_2|2]]]
; security
: A condition that results from the establishment and maintenance of protective measures that enable an organization to perform its mission or critical functions despite risks posed by threats to its use of systems. Protective measures may involve a combination of deterrence, avoidance, prevention, detection, recovery, and correction that should form part of the organization’s risk management approach. [[[#bibr-ref_9|9]]]
; security assessment S
: ee ''security control assessment''.
; security control
: The safeguards or countermeasures prescribed for an information system or an organization to protect the confidentiality, integrity, and availability of the system and its information. [[[#bibr-ref_2|2]]]
; security control assessment
: The testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization. [[[#bibr-ref_2|2]]]
; system
: See ''information system''.
; system security plan
: A document that describes how an organization meets or plans to meet the security requirements for a system. In particular, the system security plan describes the system boundary, the environment in which the system operates, how the security requirements are satisfied, and the relationships with or connections to other systems.

{{anchor|d30e8258-Appendix_Title}}{{anchor|sec-sec_C}}== Appendix C : Security Requirement Assessment ==

This appendix provides an overview of the process for assessing the security requirements in SP 800-171 [[[#bibr-ref_3|3]]]. The four-phase process is based on the methodology in SP 800-53A [[[#bibr-ref_5|5]]]{{anchor|footnote-6-backlink}}[[#footnote-6|6]] and includes:

* Preparing for assessments
* Developing assessment plans
* Conducting assessments
* Analyzing, documenting, and reporting assessment results

=== {{anchor|sec-sec_C.1}}C.1 Preparing for Assessments ===

Thorough preparation by the organization and assessors is an important aspect of conducting an effective assessment. Preparatory activities address a range of issues relating to the cost, schedule, and conduct of the assessment. From an organizational perspective, preparing for an assessment includes the following activities:

* Ensuring that appropriate policies that cover the assessment are in place and understood by affected organizational elements
* Establishing the objective and scope of the assessment (i.e., the purpose of the assessment and what is being assessed)
* Notifying appropriate organizational officials of the impending assessment and allocating the necessary resources to carry out the assessment
* Establishing appropriate communication channels among organizational officials with an interest in the assessment
* Establishing the time frame for completing the assessment and the key milestone decision points required by the organization
* Identifying and selecting the assessors who will be responsible for conducting the assessment and considering issues of assessor independence
* Providing artifacts to the assessors (e.g., policies, procedures, plans, specifications, designs, records, administrator/operator manuals, information exchange agreements, system documentation, previous assessment results, legal requirements)
* Establishing a mechanism between the organization and the assessors to minimize ambiguities or misunderstandings about the security requirements, implementation issues, and deficiencies identified during the assessment

Assessors begin preparing for the assessment by:

* Developing a general understanding of the organization’s operations and how the scope of the assessment supports those organizational operations
* Understanding the structure of the system (i.e., the system architecture) and the security requirements being assessed
* Meeting with organizational officials to ensure that there is a common understanding of the assessment objectives and the proposed rigor and scope of the assessment
* Obtaining the artifacts needed for the assessment (e.g., policies, procedures, plans, specifications, administrator/operator manuals, system documentation, information exchange agreements, designs, records, previous assessment results{{anchor|footnote-7-backlink}}[[#footnote-7|7]])
* Establishing organizational points of contact to carry out the assessment

[[#table-tab_2|Table 2]] provides a summary of the purpose and expected outcomes of the ''assessment preparation phase''.

'''{{anchor|d30e8362}}Table 2. Summary of Assessment Preparation Phase'''

{| class="wikitable"
|-
! '''PURPOSE''' !! '''Address a range of issues pertaining to the cost, schedule, scope, and conduct of the assessment.'''
|-
| '''OUTCOMES''' || • The objective, scope, and time frame of the assessment are determined. • Key organizational stakeholders are notified, and the necessary resources are allocated. • Assessors are identified and selected. • Artifacts are collected and provided to assessors. • Mechanisms to minimize ambiguities and misunderstandings about the security requirements, implementation issues, and weaknesses/deficiencies identified during the assessment are established. • The organization’s operations, structure, objective, scope, and time frame of assessment are understood by assessors.
|}

=== {{anchor|sec-sec_C.2}}C.2 Developing Assessment Plans ===

The assessment plan establishes the objectives for the security requirement assessment and a detailed roadmap of how to conduct the assessment based on the system security plan. The following steps are considered by assessors when developing an assessment plan:

* Determine which security requirements are to be included in the assessment based on the contents of the system security plan and the purpose and scope of the assessment.
* Select the appropriate assessment procedures.
* Tailor the selected assessment procedures (e.g., select appropriate assessment methods and objects, and assign depth and coverage attribute values).{{anchor|footnote-8-backlink}}[[#footnote-8|8]]
* Optimize the assessment procedures to reduce the duplication of effort (e.g., sequence and consolidate assessment procedures) and provide a cost-effective assessment solution.
* Finalize the assessment plan, and obtain the necessary approvals to execute the plan.

[[#table-tab_3|Table 3]] provides a summary of the purpose and expected outcomes of the ''assessment plan development phase''.

'''{{anchor|d30e8446}}Table 3. Summary of Assessment Plan Development Phase'''

{| class="wikitable"
|-
! '''PURPOSE''' !! '''Establish the objectives for the security requirement assessment and a detailed roadmap of how to conduct the assessment based on the system security plan.'''
|-
| '''OUTCOMES''' || • Security requirements to be included in the assessment are determined. • Assessment procedures are selected and tailored. • Assessment procedures are optimized to reduce the duplication of effort. • The assessment plan is finalized, and organizational approvals are obtained.
|}

=== {{anchor|sec-sec_C.3}}C.3 Conducting Assessments ===

After the assessment plan is approved by the organization, the assessors execute the plan in accordance with the agreed-upon schedule. Assessment objectives are achieved by applying the designated assessment methods to selected assessment objects and compiling or producing the evidence necessary to make the determination associated with each assessment objective. Each determination statement contained within an assessment procedure executed by an assessor produces one of the following findings:

* Satisfied or
* Other than satisfied.

A finding of ''satisfied'' indicates that the assessment objective for the security requirement (or subset of the requirement) addressed by the determination statement has been met and produced an acceptable result. A finding of ''other than satisfied'' indicates that the assessment objective for the requirement has not been met and has produced an unacceptable result. A finding of ''other than satisfied'' may also indicate that the assessor was unable to obtain sufficient information to make the determination called for in the determination statement.

[[#table-tab_4|Table 4]] provides a summary of the purpose and expected outcomes of the ''assessment execution phase''.

'''{{anchor|d30e8523}}Table 4. Summary of Assessment Execution Phase'''

{| class="wikitable"
|-
! '''PURPOSE''' !! '''Conduct the assessment in accordance with the assessment plan, and document the results in an assessment report.'''
|-
| '''OUTCOMES''' || • Security requirements are assessed in accordance with the assessment plan. • An assessment report that documents whether the security requirements have been satisfied is produced.
|}

=== {{anchor|sec-sec_C.4}}C.4 Analyzing, Documenting, and Reporting Assessment Results ===

The assessment report includes information from assessors (in the form of findings) that is necessary to determine whether the security requirements in SP 800-171 have been satisfied.{{anchor|footnote-9-backlink}}[[#footnote-9|9]] The report conveys the results of the assessment to designated organizational officials. The report can also provide recommendations for correcting any deficiencies discovered during the assessment. Depending on the organization’s objective for the assessment, the assessment results can trigger a variety of risk response actions, including risk acceptance, risk mitigation, risk rejection, risk transfer, or risk sharing. The assessment results can also influence changes to the system security plan and plan of action and milestones.

[[#table-tab_5|Table 5]] provides a summary of the purpose and expected outcomes of the ''assessment analysis, documentation, and reporting phase''.

'''{{anchor|d30e8581}}Table 5. Summary of Assessment Analysis, Documentation, and Reporting Phase'''

{| class="wikitable"
|-
! '''PURPOSE''' !! '''Analyze the risks that result from the weaknesses and deficiencies identified during the assessment, and determine an approach to respond to those risks in accordance with organizational priorities.'''
|-
| '''OUTCOMES''' || • Assessment findings are reviewed and analyzed. • Subsequent risk responses are initiated to manage risks. • The system security plan and plan of action and milestones are updated to reflect the results of the assessment and any subsequent risk response actions.
|}

{{anchor|d30e8621-Appendix_Title}}{{anchor|sec-sec_D}}== Appendix D : Organization-Defined Parameters ==

This appendix lists the organization-defined parameters (ODPs) that are included in the assessment procedures in Sec. 3. The ODPs are listed sequentially by requirement family, beginning with the first requirement containing an ODP in the Access Control (AC) family and ending with the last requirement containing an ODP in the Supply Chain Risk Management (SR) family.

'''{{anchor|d30e8626}}Table 6. Organization-Defined Parameters'''

{| class="wikitable"
|-
! '''SECURITY REQUIREMENT''' !! colspan="2" | '''ORGANIZATION-DEFINED PARAMETER'''
|-
| [[#sec-sec_03.01.01|03.01.01]] || [[#A.03.01.01.ODP[01]|A.03.01.01.ODP[01]]] || ''the time period for account inactivity before disabling is defined.''
|-
| [[#sec-sec_03.01.01|03.01.01]] || [[#A.03.01.01.ODP[02]|A.03.01.01.ODP[02]]] || ''the time period within which to notify account managers and designated personnel or roles when accounts are no longer required is defined.''
|-
| [[#sec-sec_03.01.01|03.01.01]] || [[#A.03.01.01.ODP[03]|A.03.01.01.ODP[03]]] || ''the time period within which to notify account managers and designated personnel or roles when users are terminated or transferred is defined.''
|-
| [[#sec-sec_03.01.01|03.01.01]] || [[#A.03.01.01.ODP[04]|A.03.01.01.ODP[04]]] || ''the time period within which to notify account managers and designated personnel or roles when system usage or the need-to-know changes for an individual is defined.''
|-
| [[#sec-sec_03.01.01|03.01.01]] || [[#A.03.01.01.ODP[05]|A.03.01.01.ODP[05]]] || ''the time period of expected inactivity requiring users to log out of the system is defined.''
|-
| [[#sec-sec_03.01.01|03.01.01]] || [[#A.03.01.01.ODP[06]|A.03.01.01.ODP[06]]] || ''circumstances requiring users to log out of the system are defined.''
|-
| [[#sec-sec_03.01.05|03.01.05]] || [[#A.03.01.05.ODP[01]|A.03.01.05.ODP[01]]] || ''security functions for authorized access are defined.''
|-
| [[#sec-sec_03.01.05|03.01.05]] || [[#A.03.01.05.ODP[02]|A.03.01.05.ODP[02]]] || ''security-relevant information for authorized access is defined.''
|-
| [[#sec-sec_03.01.05|03.01.05]] || [[#A.03.01.05.ODP[03]|A.03.01.05.ODP[03]]] || ''the frequency at which to review the privileges assigned to roles or classes of users is defined.''
|-
| [[#sec-sec_03.01.06|03.01.06]] || [[#A.03.01.06.ODP[01]|A.03.01.06.ODP[01]]] || ''personnel or roles to which privileged accounts on the system are to be restricted are defined.''
|-
| [[#sec-sec_03.01.08|03.01.08]] || [[#A.03.01.08.ODP[01]|A.03.01.08.ODP[01]]] || ''the number of consecutive invalid logon attempts by a user allowed during a time period is defined.''
|-
| [[#sec-sec_03.01.08|03.01.08]] || [[#A.03.01.08.ODP[02]|A.03.01.08.ODP[02]]] || ''the time period to which the number of consecutive invalid logon attempts by a user is limited is defined.''
|-
| [[#sec-sec_03.01.08|03.01.08]] || [[#A.03.01.08.ODP[03]|A.03.01.08.ODP[03]]] || ''one or more of the following PARAMETER VALUES are selected: {the account or node is locked automatically for <A.03.01.08.ODP[04]: time period>; the account or node is locked automatically until released by an administrator; the next logon prompt is delayed automatically; the system administrator is notified automatically; other action is taken automatically}.''
|-
| [[#sec-sec_03.01.08|03.01.08]] || [[#A.03.01.08.ODP[04]|A.03.01.08.ODP[04]]] || ''the time period for an account or node to be locked is defined (if selected).''
|-
| [[#sec-sec_03.01.10|03.01.10]] || [[#A.03.01.10.ODP[01]|A.03.01.10.ODP[01]]] || ''one or more of the following PARAMETER VALUES are selected: {a device lock is initiated after <A.03.01.10.ODP[02]: time period> of inactivity; the user is required to initiate a device lock before leaving the system unattended}.''
|-
| [[#sec-sec_03.01.10|03.01.10]] || [[#A.03.01.10.ODP[02]|A.03.01.10.ODP[02]]] || ''the time period of inactivity after which a device lock is initiated is defined (if selected).''
|-
| [[#sec-sec_03.01.11|03.01.11]] || [[#A.03.01.11.ODP[01]|A.03.01.11.ODP[01]]] || ''conditions or trigger events that require session disconnect are defined.''
|-
| [[#sec-sec_03.01.20|03.01.20]] || [[#A.03.01.20.ODP[01]|A.03.01.20.ODP[01]]] || ''security requirements to be satisfied on external systems prior to allowing the use of or access to those systems by authorized individuals are defined.''
|-
| [[#sec-sec_03.02.01|03.02.01]] || [[#A.03.02.01.ODP[01]|A.03.02.01.ODP[01]]] || ''the frequency at which to provide security literacy training to system users after initial training is defined.''
|-
| [[#sec-sec_03.02.01|03.02.01]] || [[#A.03.02.01.ODP[02]|A.03.02.01.ODP[02]]] || ''events that require security literacy training for system users are defined.''
|-
| [[#sec-sec_03.02.01|03.02.01]] || [[#A.03.02.01.ODP[03]|A.03.02.01.ODP[03]]] || ''the frequency at which to update security literacy training content is defined.''
|-
| [[#sec-sec_03.02.01|03.02.01]] || [[#A.03.02.01.ODP[04]|A.03.02.01.ODP[04]]] || ''events that require security literacy training content updates are defined.''
|-
| [[#sec-sec_03.02.02|03.02.02]] || [[#A.03.02.02.ODP[01]|A.03.02.02.ODP[01]]] || ''the frequency at which to provide role-based security training to assigned personnel after initial training is defined.''
|-
| [[#sec-sec_03.02.02|03.02.02]] || [[#A.03.02.02.ODP[02]|A.03.02.02.ODP[02]]] || ''events that require role-based security training are defined.''
|-
| [[#sec-sec_03.02.02|03.02.02]] || [[#A.03.02.02.ODP[03]|A.03.02.02.ODP[03]]] || ''the frequency at which to update role-based security training content is defined.''
|-
| [[#sec-sec_03.02.02|03.02.02]] || [[#A.03.02.02.ODP[04]|A.03.02.02.ODP[04]]] || ''events that require role-based security training content updates are defined.''
|-
| [[#sec-sec_03.03.01|03.03.01]] || [[#A.03.03.01.ODP[01]|A.03.03.01.ODP[01]]] || ''event types selected for logging within the system are defined.''
|-
| [[#sec-sec_03.03.01|03.03.01]] || [[#A.03.03.01.ODP[02]|A.03.03.01.ODP[02]]] || ''the frequency of event types selected for logging are reviewed and updated.''
|-
| [[#sec-sec_03.03.04|03.03.04]] || [[#A.03.03.04.ODP[01]|A.03.03.04.ODP[01]]] || ''the time period for organizational personnel or roles receiving audit logging process failure alerts is defined.''
|-
| [[#sec-sec_03.03.04|03.03.04]] || [[#A.03.03.04.ODP[02]|A.03.03.04.ODP[02]]] || ''additional actions to be taken in the event of an audit logging process failure are defined.''
|-
| [[#sec-sec_03.03.05|03.03.05]] || [[#A.03.03.05.ODP[01]|A.03.03.05.ODP[01]]] || ''the frequency at which system audit records are reviewed and analyzed is defined.''
|-
| [[#sec-sec_03.03.07|03.03.07]] || [[#A.03.03.07.ODP[01]|A.03.03.07.ODP[01]]] || ''granularity of time measurement for audit record time stamps is defined.''
|-
| [[#sec-sec_03.04.01|03.04.01]] || [[#A.03.04.01.ODP[01]|A.03.04.01.ODP[01]]] || ''the frequency of baseline configuration review and update is defined.''
|-
| [[#sec-sec_03.04.02|03.04.02]] || [[#A.03.04.02.ODP[01]|A.03.04.02.ODP[01]]] || ''configuration settings for the system that reflect the most restrictive mode consistent with operational requirements are defined.''
|-
| [[#sec-sec_03.04.06|03.04.06]] || [[#A.03.04.06.ODP[01]|A.03.04.06.ODP[01]]] || ''functions to be prohibited or restricted are defined.''
|-
| [[#sec-sec_03.04.06|03.04.06]] || [[#A.03.04.06.ODP[02]|A.03.04.06.ODP[02]]] || ''ports to be prohibited or restricted are defined.''
|-
| [[#sec-sec_03.04.06|03.04.06]] || [[#A.03.04.06.ODP[03]|A.03.04.06.ODP[03]]] || ''protocols to be prohibited or restricted are defined.''
|-
| [[#sec-sec_03.04.06|03.04.06]] || [[#A.03.04.06.ODP[04]|A.03.04.06.ODP[04]]] || ''connections to be prohibited or restricted are defined.''
|-
| [[#sec-sec_03.04.06|03.04.06]] || [[#A.03.04.06.ODP[05]|A.03.04.06.ODP[05]]] || ''services to be prohibited or restricted are defined.''
|-
| [[#sec-sec_03.04.06|03.04.06]] || [[#A.03.04.06.ODP[06]|A.03.04.06.ODP[06]]] || ''the frequency at which to review the system to identify unnecessary or nonsecure functions, ports, protocols, connections, or services is defined. ''
|-
| [[#sec-sec_03.04.08|03.04.08]] || [[#A.03.04.08.ODP[01]|A.03.04.08.ODP[01]]] || ''the frequency at which to review and update the list of authorized software programs is defined.''
|-
| [[#sec-sec_03.04.10|03.04.10]] || [[#A.03.04.10.ODP[01]|A.03.04.10.ODP[01]]] || ''the frequency at which to review and update the system component inventory is defined.''
|-
| [[#sec-sec_03.04.12|03.04.12]] || [[#A.03.04.12.ODP[01]|A.03.04.12.ODP[01]]] || ''configurations for systems or system components to be issued to individuals traveling to high-risk locations are defined.''
|-
| [[#sec-sec_03.04.12|03.04.12]] || [[#A.03.04.12.ODP[02]|A.03.04.12.ODP[02]]] || ''security requirements to be applied to the system or system components when individuals return from travel are defined.''
|-
| [[#sec-sec_03.05.01|03.05.01]] || [[#A.03.05.01.ODP[01]|A.03.05.01.ODP[01]]] || ''circumstances or situations that require re-authentication are defined.''
|-
| [[#sec-sec_03.05.02|03.05.02]] || [[#A.03.05.02.ODP[01]|A.03.05.02.ODP[01]]] || ''devices or types of devices to be uniquely identified and authenticated before establishing a connection are defined.''
|-
| [[#sec-sec_03.05.05|03.05.05]] || [[#A.03.05.05.ODP[01]|A.03.05.05.ODP[01]]] || ''the time period for preventing the reuse of identifiers is defined.''
|-
| [[#sec-sec_03.05.05|03.05.05]] || [[#A.03.05.05.ODP[02]|A.03.05.05.ODP[02]]] || ''characteristics used to identify individual status are defined.''
|-
| [[#sec-sec_03.05.07|03.05.07]] || [[#A.03.05.07.ODP[01]|A.03.05.07.ODP[01]]] || ''the frequency at which to update the list of commonly used, expected, or compromised passwords is defined.''
|-
| [[#sec-sec_03.05.07|03.05.07]] || [[#A.03.05.07.ODP[02]|A.03.05.07.ODP[02]]] || ''password composition and complexity rules are defined.''
|-
| [[#sec-sec_03.05.12|03.05.12]] || [[#A.03.05.12.ODP[01]|A.03.05.12.ODP[01]]] || ''the frequency for changing or refreshing authenticators is defined.''
|-
| [[#sec-sec_03.05.12|03.05.12]] || [[#A.03.05.12.ODP[02]|A.03.05.12.ODP[02]]] || ''events that trigger the change or refreshment of authenticators are defined.''
|-
| [[#sec-sec_03.06.02|03.06.02]] || [[#A.03.06.02.ODP[01]|A.03.06.02.ODP[01]]] || ''the time period to report suspected incidents to the organizational incident response capability is defined.''
|-
| [[#sec-sec_03.06.02|03.06.02]] || [[#A.03.06.02.ODP[02]|A.03.06.02.ODP[02]]] || ''authorities to whom incident information is to be reported are defined.''
|-
| [[#sec-sec_03.06.03|03.06.03]] || [[#A.03.06.03.ODP[01]|A.03.06.03.ODP[01]]] || ''the frequency at which to test the effectiveness of the incident response capability for the system is defined.''
|-
| [[#sec-sec_03.06.04|03.06.04]] || [[#A.03.06.04.ODP[01]|A.03.06.04.ODP[01]]] || ''the time period within which incident response training is to be provided to system users is defined.''
|-
| [[#sec-sec_03.06.04|03.06.04]] || [[#A.03.06.04.ODP[02]|A.03.06.04.ODP[02]]] || ''the frequency at which to provide incident response training to users is defined.''
|-
| [[#sec-sec_03.06.04|03.06.04]] || [[#A.03.06.04.ODP[03]|A.03.06.04.ODP[03]]] || ''the frequency at which to review and update incident response training content is defined.''
|-
| [[#sec-sec_03.06.04|03.06.04]] || [[#A.03.06.04.ODP[04]|A.03.06.04.ODP[04]]] || ''events that initiate a review of the incident response training content are defined.''
|-
| [[#sec-sec_03.08.07|03.08.07]] || [[#A.03.08.07.ODP[01]|A.03.08.07.ODP[01]]] || ''types of system media with usage restrictions or that are prohibited from use are defined.''
|-
| [[#sec-sec_03.09.01|03.09.01]] || [[#A.03.09.01.ODP[01]|A.03.09.01.ODP[01]]] || ''conditions that require the rescreening of individuals are defined.''
|-
| [[#sec-sec_03.09.02|03.09.02]] || [[#A.03.09.02.ODP[01]|A.03.09.02.ODP[01]]] || ''the time period within which to disable system access is defined.''
|-
| [[#sec-sec_03.10.01|03.10.01]] || [[#A.03.10.01.ODP[01]|A.03.10.01.ODP[01]]] || ''the frequency at which to review the access list detailing authorized facility access by individuals is defined.''
|-
| [[#sec-sec_03.10.02|03.10.02]] || [[#A.03.10.02.ODP[01]|A.03.10.02.ODP[01]]] || ''the frequency at which to review physical access logs is defined.''
|-
| [[#sec-sec_03.10.02|03.10.02]] || [[#A.03.10.02.ODP[02]|A.03.10.02.ODP[02]]] || ''events or potential indications of events requiring physical access logs to be reviewed are defined.''
|-
| [[#sec-sec_03.10.06|03.10.06]] || [[#A.03.10.06.ODP[01]|A.03.10.06.ODP[01]]] || ''security requirements to be employed at alternate work sites are defined.''
|-
| [[#sec-sec_03.11.01|03.11.01]] || [[#A.03.11.01.ODP[01]|A.03.11.01.ODP[01]]] || ''the frequency at which to update the risk assessment is defined.''
|-
| [[#sec-sec_03.11.02|03.11.02]] || [[#A.03.11.02.ODP[01]|A.03.11.02.ODP[01]]] || ''the frequency at which the system is monitored and scanned for vulnerabilities is defined.''
|-
| [[#sec-sec_03.11.02|03.11.02]] || [[#A.03.11.02.ODP[02]|A.03.11.02.ODP[02]]] || ''response times to remediate system vulnerabilities are defined.''
|-
| [[#sec-sec_03.11.02|03.11.02]] || [[#A.03.11.02.ODP[03]|A.03.11.02.ODP[03]]] || ''the frequency at which to update system vulnerabilities to be scanned is defined.''
|-
| [[#sec-sec_03.12.01|03.12.01]] || [[#A.03.12.01.ODP[01]|A.03.12.01.ODP[01]]] || ''the frequency at which to assess the security requirements for the system and its environment of operation is defined.''
|-
| [[#sec-sec_03.12.05|03.12.05]] || [[#A.03.12.05.ODP[01]|A.03.12.05.ODP[01]]] || ''one or more of the following PARAMETER VALUES are selected: {interconnection security agreements; information exchange security agreements; memoranda of understanding or agreement; service-level agreements; user agreements; non-disclosure agreements; other types of agreements}.''
|-
| [[#sec-sec_03.12.05|03.12.05]] || [[#A.03.12.05.ODP[02]|A.03.12.05.ODP[02]]] || ''the frequency at which to review and update agreements is defined.''
|-
| [[#sec-sec_03.13.09|03.13.09]] || [[#A.03.13.09.ODP[01]|A.03.13.09.ODP[01]]] || ''the time period of inactivity after which the system terminates a network connection associated with a communications session is defined.''
|-
| [[#sec-sec_03.13.10|03.13.10]] || [[#A.03.13.10.ODP[01]|A.03.13.10.ODP[01]]] || ''requirements for key generation, distribution, storage, access, and destruction are defined.''
|-
| [[#sec-sec_03.13.11|03.13.11]] || [[#A.03.13.11.ODP[01]|A.03.13.11.ODP[01]]] || ''the types of cryptography for protecting the confidentiality of CUI are defined.''
|-
| [[#sec-sec_03.13.12|03.13.12]] || [[#A.03.13.12.ODP[01]|A.03.13.12.ODP[01]]] || ''exceptions where remote activation is to be allowed are defined.''
|-
| [[#sec-sec_03.14.01|03.14.01]] || [[#A.03.14.01.ODP[01]|A.03.14.01.ODP[01]]] || ''the time period within which to install security-relevant software updates after the release of the updates is defined.''
|-
| [[#sec-sec_03.14.01|03.14.01]] || [[#A.03.14.01.ODP[02]|A.03.14.01.ODP[02]]] || ''the time period within which to install security-relevant firmware updates after the release of the updates is defined.''
|-
| [[#sec-sec_03.14.02|03.14.02]] || [[#A.03.14.02.ODP[01]|A.03.14.02.ODP[01]]] || ''the frequency at which malicious code protection mechanisms perform scans is defined.''
|-
| [[#sec-sec_03.15.01|03.15.01]] || [[#A.03.15.01.ODP[01]|A.03.15.01.ODP[01]]] || ''the frequency at which the policies and procedures for implementing security requirements are reviewed and updated is defined.''
|-
| [[#sec-sec_03.15.02|03.15.02]] || [[#A.03.15.02.ODP[01]|A.03.15.02.ODP[01]]] || ''the frequency at which the system security plan is reviewed and updated is defined.''
|-
| [[#sec-sec_03.15.03|03.15.03]] || [[#A.03.15.03.ODP[01]|A.03.15.03.ODP[01]]] || ''the frequency at which the rules of behavior are reviewed and updated is defined.''
|-
| [[#sec-sec_03.16.01|03.16.01]] || [[#A.03.16.01.ODP[01]|A.03.16.01.ODP[01]]] || ''systems security engineering principles to be applied to the development or modification of the system and system components are defined.''
|-
| [[#sec-sec_03.16.03|03.16.03]] || [[#A.03.16.03.ODP[01]|A.03.16.03.ODP[01]]] || ''security requirements to be satisfied by external system service providers are defined.''
|-
| [[#sec-sec_03.17.01|03.17.01]] || [[#A.03.17.01.ODP[01]|A.03.17.01.ODP[01]]] || ''the frequency at which to review and update the supply chain risk management plan is defined.''
|-
| [[#sec-sec_03.17.03|03.17.03]] || [[#A.03.17.03.ODP[01]|A.03.17.03.ODP[01]]] || ''security requirements to protect against supply chain risks to the system, system components, or system services and to limit the harm or consequences from supply chain-related events are defined.''
|}

{{anchor|d30e10309-Appendix_Title}}{{anchor|sec-sec_E}}== Appendix E : Change Log ==

This publication incorporates the following changes from the original edition (June 2018):

* Assessment procedures have been updated to be consistent with SP 800-171r3 (Revision 3) [[[#bibr-ref_3|3]]].
* Organization-defined parameters (ODPs) have been added to determination statements.
* A references section has been added to each assessment procedure to provide a hyperlink to the source assessment procedure in SP 800-53A [[[#bibr-ref_5|5]]].

[[#table-tab_7|Table 7]] shows the changes incorporated into this publication. Errata updates can include corrections, clarifications, or other minor changes in the publication that are either ''editorial'' or ''substantive'' in nature. Any potential updates to this document that are not yet published in an errata update or a formal revision, including additional issues and potential corrections, will be posted as they are identified. See the [https://csrc.nist.gov/pubs/sp/800/171/a/r3/final publication details] for this report. The current release of this publication does not include any errata updates.

'''{{anchor|d30e10348}}Table 7. Change Log'''

{| class="wikitable"
|-
| '''Publication ID''' || '''Date''' || '''Type of Edit''' || '''Change''' || '''Location'''
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| || || || ||
|}

== Footnotes ==

{{anchor|footnote-1}}[[#footnote-1-backlink|1]] The term ''risk'' refers to risks to organizational operations (i.e., mission, functions, image, and reputation), organizational assets, individuals, other organizations, and the Nation. See SP 800-39 [[[#bibr-ref_4|4]]] for additional information on organizational risk management and risk tolerance.

{{anchor|footnote-2}}[[#footnote-2-backlink|2]] SP 800-53A [[[#bibr-ref_5|5]]] provides additional information on the assessment process and the individuals steps listed above.

{{anchor|footnote-3}}[[#footnote-3-backlink|3]] Artifacts may be in formats other than documents (e.g., databases, Governance, Risk, and Compliance [GRC] tools, or Open Security Controls Assessment Language [OSCAL]).

{{anchor|footnote-4}}[[#footnote-4-backlink|4]] A ''designated official'' is an official, either internal or external to a nonfederal organization, with the responsibility to determine organizational compliance with the security requirements.

{{anchor|footnote-5}}[[#footnote-5-backlink|5]] Examples of third-party testing organizations include Common Criteria Testing Laboratories that evaluate IT products in accordance with ISO/IEC 15408 [[[#bibr-ref_6|6]]] and Cryptographic Module Validation Program Testing Laboratories that evaluate cryptographic modules in accordance with Federal Information Processing Standard (FIPS) 140 [[[#bibr-ref_7|7]]].

{{anchor|footnote-6}}[[#footnote-6-backlink|6]] For additional detail and guidance, see SP 800-53A, Section 3.

{{anchor|footnote-7}}[[#footnote-7-backlink|7]] Previous assessment results that may be reused for the current assessment include Inspector General reports, audits, vulnerability scans, physical security inspections, developmental testing and evaluation, vendor flaw remediation activities, and ISO 15408 [[[#bibr-ref_6|6]]] evaluations.

{{anchor|footnote-8}}[[#footnote-8-backlink|8]] In addition to selecting assessment methods and objects, each assessment method (i.e., examine, interview, and test) is associated with depth and coverage attributes. The attribute values identify the rigor (depth) and scope (coverage) of the assessment procedures executed by the assessor. The depth and coverage attribute values are associated with the assurance requirements specified by the organization. SP 800-53A, Appendix C provides additional guidance on depth and coverage attributes.

{{anchor|footnote-9}}[[#footnote-9-backlink|9]] SP 800-53A, Appendix E provides additional guidance on security assessment reports.

NIST SP 800-17 R3

2026-07-27T03:00:10Z

David: Created page with "'''NIST SP 800-171r3''' == Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations == Ron Ross Victoria Pillitteri ''Computer Security Division, Information Technology Laboratory'' ''Computer Security Division, Information Technology Laboratory'' [https://doi.org/10.6028/NIST.SP.800-171r3] May 2024 == Abstract == The protection of Controlled Unclassified Information (CUI) is of paramount impo..."

'''NIST SP 800-171r3'''

== Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations ==

Ron Ross

Victoria Pillitteri

''Computer Security Division, Information Technology Laboratory''

''Computer Security Division, Information Technology Laboratory''

[https://doi.org/10.6028/NIST.SP.800-171r3]

May 2024


== Abstract ==

The protection of Controlled Unclassified Information (CUI) is of paramount importance to federal agencies and can directly impact the ability of the Federal Government to successfully conduct its essential missions and functions. This publication provides federal agencies with recommended security requirements for protecting the confidentiality of CUI when the information is resident in nonfederal systems and organizations. The requirements apply to components of nonfederal systems that process, store, or transmit CUI ''or'' that provide protection for such components. The security requirements are intended for use by federal agencies in contractual vehicles or other agreements established between those agencies and nonfederal organizations. This publication can be used in conjunction with its companion publication, NIST Special Publication 800-171A, which provides a comprehensive set of procedures to assess the security requirements.


== Keywords ==

Controlled Unclassified Information, Executive Order 13556, FIPS Publication 199, FIPS Publication 200, FISMA, NIST Special Publication 800-53, nonfederal organizations, nonfederal systems, organization-defined parameter, security assessment, security control, security requirement.


== Disclaimer ==

Certain equipment, instruments, software, or materials, commercial or non-commercial, are identified in this paper in order to specify the experimental procedure adequately. Such identification does not imply recommendation or endorsement of any product or service by NIST, nor does it imply that the materials or equipment identified are necessarily the best available for the purpose.

There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST.

Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at [https://csrc.nist.gov/publications].


== Authority ==

This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.


== NIST Technical Series Policies ==

[https://doi.org/10.6028/NIST-TECHPUBS.CROSSMARK-POLICY Copyright, Use, and Licensing Statements]

[https://www.nist.gov/document/publication-identifier-syntax-nist-technical-series-publications NIST Technical Series Publication Identifier Syntax]


== Publication History ==

Approved by the NIST Editorial Review Board on 2024-04-23

Supersedes NIST Special Publication 800-171r2 (February 2020; Includes updates as of 01-28-2021) [https://doi.org/10.6028/NIST.SP.800-171r2]


== How to Cite this NIST Technical Series Publication: ==

Ross R, Pillitteri V (2024) Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-171r3. [https://doi.org/10.6028/NIST.SP.800-171r3]


== Author ORCID iDs ==

Ron Ross: 0000-0002-1099-9757

Victoria Pillitteri: 0000-0002-7446-7506


== Submit Comments ==

800-171comments@list.nist.gov

National Institute of Standards and Technology

Attn: Computer Security Division, Information Technology Laboratory

100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930


== Additional Information ==

Additional information about this publication is available at [https://csrc.nist.gov/pubs/sp/800/171/r3/final], including related content, potential updates, and document history.

'''All comments are subject to release under the Freedom of Information Act (FOIA).'''


== Reports on Computer Systems Technology ==

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.


== Audience ==

This publication serves a diverse group of individuals and organizations in the public and private sectors, including:

* Federal agencies responsible for managing and protecting CUI
* Nonfederal organizations responsible for protecting CUI
* Individuals with system development life cycle responsibilities (e.g., program managers, mission/business owners, information owners/stewards, system designers and developers, system/security engineers, systems integrators)
* Individuals with acquisition or procurement responsibilities (e.g., contracting officers)
* Individuals with system, security, or risk management and oversight responsibilities (e.g., authorizing officials, chief information officers, chief information security officers, system owners, information security managers)
* Individuals with security assessment and monitoring responsibilities (e.g., auditors, system evaluators, assessors, analysts, independent verifiers and validators)

The above roles and responsibilities can be viewed from two perspectives:

* ''Federal perspective'': The entity establishing and conveying the security requirements in contractual vehicles or other types of agreements
* ''Nonfederal perspective'': The entity responding to and complying with the security requirements set forth in contracts or agreements


== Patent Disclosure Notice ==

NOTICE: ITL has requested that holders of patent claims whose use may be required for compliance with the guidance or requirements of this publication disclose such patent claims to ITL. However, holders of patents are not obligated to respond to ITL calls for patents and ITL has not undertaken a patent search in order to identify which, if any, patents may apply to this publication.

As of the date of publication and following call(s) for the identification of patent claims whose use may be required for compliance with the guidance or requirements of this publication, no such patent claims have been identified to ITL.

No representation is made or implied by ITL that licenses are not required to avoid patent infringement in the use of this publication.


== Acknowledgments ==

The authors gratefully acknowledge and appreciate the significant contributions from individuals and organizations in the public and private sectors whose constructive comments improved the overall quality, thoroughness, and usefulness of this publication. The authors also wish to thank the NIST technical editing and production staff – Jim Foti, Jeff Brewer, Eduardo Takamura, Isabel Van Wyk, Cristina Ritfeld, Derek Sappington, and Carolyn Schmidt – for their outstanding support in preparing this document for publication. Finally, a special note of thanks goes out to Kelley Dempsey for the initial research and development of the content used in the prototype CUI overlay.


==== Historical Contributions ====

The authors also wish to acknowledge the following organizations and individuals for their historic contributions to this publication:

* ''Organizations:'' National Archives and Records Administration, Department of Defense
* ''Individuals:'' Carol Bales, Matthew Barrett, Jon Boyens, Devin Casey, Christian Enloe, Gary Guissanie, Peggy Himes, Robert Glenn, Elizabeth Lennon, Vicki Michetti, Dorian Pappas, Karen Quigg, Mark Riddle, Matthew Scholl, Mary Thomas, Murugiah Souppaya, Patricia Toth, and Patrick Viscuso


== 1 Introduction ==

Executive Order (EO) 13556 [[#bibr-ref_1|1]] established a government-wide program to standardize the way the executive branch handles Controlled Unclassified Information (CUI).[[#footnote-1|1]] EO 13556 required that the CUI program emphasize openness, transparency, and uniformity of government-wide practices and that the program implementation take place in a manner consistent with Office of Management and Budget (OMB) policies and National Institute of Standards and Technology (NIST) standards and guidelines. As the CUI program Executive Agent, the National Archives and Records Administration (NARA) provides information, guidance, policy, and requirements on handling CUI [[#bibr-ref_4|4]]. This includes approved CUI categories and descriptions, the basis for safeguarding and dissemination controls, and procedures for the use of CUI.[[#footnote-2|2]] The CUI federal regulation [[#bibr-ref_5|5]] provides guidance to federal agencies on the designation, safeguarding, marking, dissemination, decontrolling, and disposition of CUI; establishes self-inspection and oversight requirements; and delineates other facets of the program.

The CUI regulation requires federal agencies that use federal information systems[[#footnote-3|3]] to process, store, or transmit CUI to comply with NIST standards and guidelines. The responsibility of federal agencies to protect CUI does not change when such information is shared with nonfederal organizations.[[#footnote-4|4]] Therefore, a similar level of protection is needed when CUI is processed, stored, or transmitted by nonfederal organizations using nonfederal systems.[[#footnote-5|5]] To maintain a consistent level of protection, the security requirements for safeguarding CUI in nonfederal systems and organizations must comply with Federal Information Processing Standards (FIPS 199) publication [[#bibr-ref_6|6]] and FIPS 200 [[#bibr-ref_7|7]]. The requirements are derived from the controls in NIST Special Publication (SP) 800-53 [[#bibr-ref_8|8]].


=== 1.1 Purpose and Applicability ===

This publication provides federal agencies with recommended security requirements[[#footnote-6|6]] for protecting the ''confidentiality'' of CUI[[#footnote-7|7]] when such information is resident in nonfederal systems and organizations and where there are no specific safeguarding requirements prescribed by the authorizing law, regulation, or government-wide policy for the CUI category listed in the CUI registry [[#bibr-ref_4|4]]. The requirements do not apply to nonfederal organizations that are collecting or maintaining information on behalf of a federal agency or using or operating a system on behalf of an agency.[[#footnote-8|8]]

The security requirements in this publication are ''only'' applicable to components of nonfederal systems that process, store, or transmit CUI ''or'' that provide protection for such components.[[#footnote-9|9]] The requirements are intended for use by federal agencies in contractual vehicles or other agreements that are established between those agencies and nonfederal organizations.

Appropriately scoping requirements is an important factor in determining protection-related investment decisions and managing security risks for nonfederal organizations. If nonfederal organizations designate system components for the processing, storage, or transmission of CUI, those organizations may limit the scope of the security requirements by isolating the system components in a separate security domain. Isolation can be achieved by applying architectural and design concepts (e.g., implementing subnetworks with firewalls or other boundary protection devices and using information flow control mechanisms). Security domains may employ physical separation, logical separation, or a combination of both. This approach can provide adequate security for CUI and avoid increasing the organization’s security posture beyond what it requires for protecting its missions, operations, and assets.


=== 1.2 Organization of This Publication ===

The remainder of this special publication is organized as follows:

• [[#sec-sec_2|Section 2]] describes the assumptions and methodology used to develop the security requirements for protecting the confidentiality of CUI, the format of the requirements, and the tailoring criteria applied to the NIST guidelines to obtain the requirements.

• [[#sec-sec_3|Section 3]] lists the security requirements for protecting the confidentiality of CUI in nonfederal systems and organizations.

The following sections provide additional information to support the protection of CUI:

* References
* Appendix A: Acronyms
* Appendix B: Glossary
* Appendix C: Tailoring Criteria
* Appendix D: Organization-Defined Parameters
* Appendix E: Change Log


== 2 The Fundamentals ==

This section describes the assumptions and methodology used to develop the requirements to protect the confidentiality of CUI in nonfederal systems and organizations. It also includes the tailoring[[#footnote-10|10]] criteria applied to the controls in SP 800-53 [[#bibr-ref_8|8]].


=== 2.1 Security Requirement Assumptions ===

The security requirements in this publication are based on the following assumptions:

* Federal information designated as CUI has the same value, whether such information resides in a federal or nonfederal system or organization.
* Statutory and regulatory requirements for the protection of CUI are consistent in federal and nonfederal systems and organizations.
* Safeguards implemented to protect CUI are consistent in federal and nonfederal systems and organizations.
* The confidentiality impact value for CUI is no less than ''moderate''.[[#footnote-11|11]]
* Nonfederal organizations can directly implement a variety of potential security solutions or use external service providers to satisfy security requirements.


=== 2.2 Security Requirement Development Methodology ===

Starting with the SP 800-53 controls in the SP 800-53B [[#bibr-ref_12|12]] moderate baseline, the controls are ''tailored'' to eliminate selected controls or parts of controls that are:

* Primarily the responsibility of the Federal Government,
* Not directly related to protecting the confidentiality of CUI,
* Adequately addressed by other related controls,[[#footnote-12|12]] or
* Not applicable.

SP 800-171 security requirements represent a subset of the controls that are necessary to protect the confidentiality of CUI. The security requirements are organized into 17 families, as illustrated in [[#table-tab_1|Table 1]]. Each family contains the requirements related to the general security topic of the family. Certain families from SP 800-53 are not included due to the tailoring criteria. For example, the PII Processing and Transparency (PT) family is not included because personally identifiable information (PII) is a category of CUI, and therefore, no additional requirements are specified for confidentiality protection. The Program Management (PM) family is not included because it is not associated with any control baseline. Finally, the Contingency Planning (CP) family is not included because it addresses availability.[[#footnote-13|13]]

Table 1. Security Requirement Families

{|
|-
| Access Control
| Maintenance
| Security Assessment and Monitoring
|-
| Awareness and Training
| Media Protection
| System and Communications Protection
|-
| Audit and Accountability
| Personnel Security
| System and Information Integrity
|-
| Configuration Management
| Physical Protection
| Planning
|-
| Identification and Authentication
| Risk Assessment
| System and Services Acquisition
|-
| Incident Response
|
| Supply Chain Risk Management
|}

''Organization-defined parameters'' (ODPs) are included in certain security requirements. ODPs provide flexibility through the use of ''assignment'' and ''selection'' operations to allow federal agencies and nonfederal organizations to specify values for the designated parameters in the requirements.[[#footnote-14|14]] Assignment and selection operations provide the capability to customize the security requirements based on specific protection needs. The determination of ODP values can be guided and informed by laws, Executive Orders, directives, regulations, policies, standards, guidance, or mission and business needs. Once specified, the values for the organization-defined parameters become part of the requirement.

ORGANIZATION-DEFINED PARAMETERS

Organization-defined parameters are an important part of a security requirement specification. ODPs provide both the flexibility and specificity needed by organizations to clearly define their CUI security requirements, given the diverse nature of their missions, business functions, operational environments, and risk tolerance. In addition, ODPs support consistent security assessments in determining whether specified security requirements have been satisfied. If a federal agency or a consortium of agencies do not specify a particular value or range of values for an ODP, nonfederal organizations must assign the value or values to complete the security requirement.

A discussion section is included with each requirement. It is derived from the control discussion sections in SP 800-53 and provides additional information to facilitate the implementation and assessment of the requirements. The discussion section is informative, not normative. It is not intended to extend the scope of a requirement or influence the solutions that organizations may use to satisfy a requirement. The use of examples is notional, not exhaustive, and does not reflect the potential options available to organizations. A ''references'' section provides the source controls[[#footnote-15|15]] from SP 800-53 and a list of NIST Special Publications with additional information on the topic described in the security requirement. The structure and content of a typical security requirement is provided in the example below.

03.13.11 Cryptographic Protection

Implement the following types of cryptography when used to protect the confidentiality of CUI: [''Assignment: organization-defined types of cryptography''].

'''DISCUSSION'''

Cryptography is implemented in accordance with applicable laws, Executive Orders, directives, policies, regulations, standards, and guidelines. FIPS-validated cryptography is recommended for the protection of CUI.

'''REFERENCES'''

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-13 SC-13]

Supporting Publications: FIPS 140-3 [[#bibr-ref_38|38]]

The term ''organization'' is used in many security requirements, and its meaning depends on context. For example, in a security requirement with an ODP, an organization can refer to either the federal agency or the nonfederal organization establishing the parameter values for the requirement.

[[#sec-sec_C|Appendix C]] describes the security control tailoring criteria used to develop the security requirements and the results of the tailoring process. The appendix provides a list of controls from SP 800-53 that support the requirements and the controls that have been eliminated from the moderate baseline in accordance with the tailoring criteria.

ASSESSING SECURITY REQUIREMENTS

SP 800-171A [[#bibr-ref_84|84]] provides a set of procedures to assess the security requirements described in this publication. The assessment procedures are based on the procedures described in SP 800-53A [[#bibr-ref_57|57]].


== 3 The Security Requirements ==

This section describes 17 families of security requirements for protecting the confidentiality of CUI in nonfederal systems and organizations. When used in the context of the requirements in Sec. 3, the term ''system'' is defined to be nonfederal systems or system components that process, store, or transmit CUI or that provide protection for such systems or components. Not all security requirements mention CUI explicitly. However, the requirements are included because they directly affect the protection of CUI during processing, while in storage, and when in transmission between different locations.

Some systems, including specialized systems (e.g., industrial/process control systems, medical devices, computer numerical control machines), may have limitations on the application of certain security requirements. To accommodate such issues, the system security plan — as reflected in requirement [[#sec-sec_03.15.02|03.15.02]] — is used to describe any ''enduring exceptions'' to the security requirements. Individual, isolated, or temporary deficiencies are managed though plans of action and milestones, as reflected in requirement [[#sec-sec_03.12.02|03.12.02]].

 SCOPE AND APPLICABILITY OF SECURITY REQUIREMENTS

The security requirements in this section are only applicable to components of nonfederal systems that process, store, or transmit CUI ''or'' that provide protection for such components.


=== 3.1 Access Control ===


==== 03.01.01 Account Management ====

# Define the types of system accounts allowed and prohibited.
# Create, enable, modify, disable, and remove system accounts in accordance with policy, procedures, prerequisites, and criteria.
# Specify:
## Authorized users of the system,
## Group and role membership, and
## Access authorizations (i.e., privileges) for each account.
# Authorize access to the system based on:
## A valid access authorization and
## Intended system usage.
# Monitor the use of system accounts.
# Disable system accounts when:
## The accounts have expired,
## The accounts have been inactive for [''Assignment: organization-defined time period''],
## The accounts are no longer associated with a user or individual,
## The accounts are in violation of organizational policy, or
## Significant risks associated with individuals are discovered.
# Notify account managers and designated personnel or roles within:
## [''Assignment: organization-defined time period''] when accounts are no longer required.
## [''Assignment: organization-defined time period''] when users are terminated or transferred.
## [''Assignment: organization-defined time period''] when system usage or the need-to-know changes for an individual.
# Require that users log out of the system after [''Assignment: organization-defined time period''] of expected inactivity or when [''Assignment: organization-defined circumstances''].

===== DISCUSSION =====

This requirement focuses on account management for systems and applications. The definition and enforcement of access authorizations other than those determined by account type (e.g., privileged access, non-privileged access) are addressed in [[#sec-sec_03.01.02|03.01.02]]. System account types include individual, group, temporary, system, guest, anonymous, emergency, developer, and service. Users who require administrative privileges on system accounts receive additional scrutiny by personnel responsible for approving such accounts and privileged access. Types of accounts that organizations may prohibit due to increased risk include group, emergency, guest, anonymous, and temporary.

Organizations may choose to define access privileges or other attributes by account, type of account, or a combination of both. Other attributes required for authorizing access include restrictions on the time of day, day of the week, and point of origin. When defining other system account attributes, organizations consider system requirements (e.g., system upgrades, scheduled maintenance) and mission and business requirements (e.g., time zone differences, remote access to facilitate travel requirements).

Users who pose a significant security risk include individuals for whom reliable evidence indicates either the intention to use authorized access to the system to cause harm or that adversaries will cause harm through them. Close coordination among mission and business owners, system administrators, human resource managers, and legal staff is essential when disabling system accounts for high-risk individuals. Time periods for the notification of organizational personnel or roles may vary.

Inactivity logout is behavior- or policy-based and requires users to take physical action to log out when they are expecting inactivity longer than the defined period. Automatic enforcement of inactivity logout is addressed by [[#sec-sec_03.01.10|03.01.10]].

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-02 AC-02], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-02 AC-02(03)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-02 AC-02(05)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-02 AC-02(13)]

Supporting Publications: SP 800-46 [[#bibr-ref_14|14]], SP 800-57-1 [[#bibr-ref_15|15]], SP 800-57-2 [[#bibr-ref_16|16]], SP 800-57-3 [[#bibr-ref_17|17]], SP 800-77 [[#bibr-ref_18|18]], SP 800-113 [[#bibr-ref_19|19]], SP 800-114 [[#bibr-ref_20|20]], SP 800-121 [[#bibr-ref_21|21]], SP 800-162 [[#bibr-ref_22|22]], SP 800-178 [[#bibr-ref_23|23]], SP 800-192 [[#bibr-ref_24|24]], IR 7874 [[#bibr-ref_25|25]], IR 7966 [[#bibr-ref_26|26]]


==== 03.01.02 Access Enforcement ====

Enforce approved authorizations for logical access to CUI and system resources in accordance with applicable access control policies.

===== DISCUSSION =====

Access control policies control access between active entities or subjects (i.e., users or system processes acting on behalf of users) and passive entities or objects (i.e., devices, files, records, domains) in organizational systems. Types of system access include remote access and access to systems that communicate through external networks, such as the internet. Access enforcement mechanisms can also be employed at the application and service levels to provide increased protection for CUI. This recognizes that the system can host many applications and services in support of mission and business functions. Access control policies are defined in [[#sec-sec_03.15.01|03.15.01]].

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-03 AC-03]

Supporting Publications: SP 800-46 [[#bibr-ref_14|14]], SP 800-57-1 [[#bibr-ref_15|15]], SP 800-57-2 [[#bibr-ref_16|16]], SP 800-57-3 [[#bibr-ref_17|17]], SP 800-77 [[#bibr-ref_18|18]], SP 800-113 [[#bibr-ref_19|19]], SP 800-114 [[#bibr-ref_20|20]], SP 800-121 [[#bibr-ref_21|21]], SP 800-162 [[#bibr-ref_22|22]], SP 800-178 [[#bibr-ref_23|23]], SP 800-192 [[#bibr-ref_24|24]], IR 7874 [[#bibr-ref_25|25]], IR 7966 [[#bibr-ref_26|26]]


==== 03.01.03 Information Flow Enforcement ====

Enforce approved authorizations for controlling the flow of CUI within the system and between connected systems.

===== DISCUSSION =====

Information flow control regulates where CUI can transit within a system and between systems (in contrast to who is allowed to access the information) and without regard to subsequent accesses to that information. Flow control restrictions include keeping CUI from being transmitted in the clear to the internet, blocking external communications traffic that claims to be sourced from within the organization, restricting requests to the internet that are not from the internal web proxy server, and limiting CUI transfers between organizations based on data structures and content.

Transferring CUI between organizations may require an agreement that specifies how the information flow is enforced (see [[#sec-sec_03.12.05|03.12.05]]). Transferring CUI between systems that represent different security domains with different security policies introduces the risk that such transfers violate one or more domain security policies. In such situations, information owners or stewards provide guidance at designated policy enforcement points between interconnected systems. Organizations consider mandating specific architectural solutions when required to enforce specific security policies. Enforcement includes prohibiting CUI transfers between interconnected systems (i.e., allowing information access only), employing hardware mechanisms to enforce one-way information flows, and implementing trustworthy regrading mechanisms to reassign security attributes and security labels.

Organizations commonly use information flow control policies and enforcement mechanisms to control the flow of CUI between designated sources and destinations (e.g., networks, individuals, and devices) within systems and between interconnected systems. Flow control is based on characteristics of the information or the information path. Enforcement occurs in boundary protection devices (e.g., encrypted tunnels, routers, gateways, and firewalls) that use rule sets or establish configuration settings that restrict system services, provide a packet-filtering capability based on header information, or provide a message-filtering capability based on message content (e.g., implementing key word searches or using document characteristics). Organizations also consider the trustworthiness of filtering and inspection mechanisms (i.e., hardware, firmware, and software components) that are critical to information flow enforcement.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-04 AC-04]

Supporting Publications: SP 800-160-1 [[#bibr-ref_11|11]], SP 800-162 [[#bibr-ref_22|22]], SP 800-178 [[#bibr-ref_23|23]]


==== 03.01.04 Separation of Duties ====

# Identify the duties of individuals requiring separation.
# Define system access authorizations to support separation of duties.

===== DISCUSSION =====

Separation of duties addresses the potential for abuse of authorized privileges and reduces the risk of malevolent activity without collusion. Separation of duties includes dividing mission functions and support functions among different individuals or roles, conducting system support functions with different individuals or roles (e.g., quality assurance, configuration management, network security, system management, assessments, and programming), and ensuring that personnel who administer access control functions do not also administer audit functions. Because separation of duty violations can span systems and application domains, organizations consider the entirety of their systems and system components when developing policies on separation of duties. This requirement is enforced by [[#sec-sec_03.01.02|03.01.02]].

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-05 AC-05]

Supporting Publications: SP 800-162 [[#bibr-ref_22|22]], SP 800-178 [[#bibr-ref_23|23]]


==== 03.01.05 Least Privilege ====

# Allow only authorized system access for users (or processes acting on behalf of users) that is necessary to accomplish assigned organizational tasks.
# Authorize access to [''Assignment: organization-defined security functions''] and [''Assignment: organization-defined security-relevant information''].
# Review the privileges assigned to roles or classes of users [''Assignment: organization-defined frequency''] to validate the need for such privileges.
# Reassign or remove privileges, as necessary.

===== DISCUSSION =====

Organizations employ the principle of least privilege for specific duties and authorized access for users and system processes. Least privilege is applied to the development, implementation, and operation of the system. Organizations consider creating additional processes, roles, and system accounts to achieve least privilege. Security functions include establishing system accounts and assigning privileges, installing software, configuring access authorizations, configuring settings for events to be audited, establishing vulnerability scanning parameters, establishing intrusion detection parameters, and managing audit information. Security-relevant information includes threat and vulnerability information, filtering rules for routers or firewalls, configuration parameters for security services, security architecture, cryptographic key management information, access control lists, and audit information.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-06 AC-06], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-06 AC-06(01)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-06 AC-06(07)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-09 AU-09(04)]

Supporting Publications: None


==== 03.01.06 Least Privilege – Privileged Accounts ====

# Restrict privileged accounts on the system to [''Assignment: organization-defined personnel or roles''].
# Require that users (or roles) with privileged accounts use non-privileged accounts when accessing non-security functions or non-security information.

===== DISCUSSION =====

Privileged accounts refer to accounts that are granted elevated privileges to access resources (including security functions or security-relevant information) that are otherwise restricted for non-privileged accounts. These accounts are typically described as system administrator or super user accounts. For example, a privileged account is often required in order to perform privileged functions such as executing commands that could modify system behavior. Restricting privileged accounts to specific personnel or roles ensures that only those authorized users can access and manipulate security functions or security-relevant information. Requiring the use of non-privileged accounts when such access is not needed can limit unauthorized access to and manipulation of security functions or security-relevant information.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-06 AC-06(02)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-06 AC-06(05)]

Supporting Publications: None


==== 03.01.07 Least Privilege – Privileged Functions ====

# Prevent non-privileged users from executing privileged functions.
# Log the execution of privileged functions.

===== DISCUSSION =====

Privileged functions include establishing system accounts, performing system integrity checks, conducting patching operations, changing system configuration settings, or administering cryptographic key management activities. Non-privileged users do not possess the authorizations to execute privileged functions. Bypassing intrusion detection and prevention mechanisms or malicious code protection mechanisms are examples of privileged functions that require protection from non-privileged users. This requirement represents a condition achieved by the definition of authorized privileges in [[#sec-sec_03.01.01|03.01.01]] and privilege enforcement in [[#sec-sec_03.01.02|03.01.02]].

The misuse of privileged functions — whether intentionally or unintentionally by authorized users or by unauthorized external entities that have compromised system accounts — is a serious and ongoing concern that can have significant adverse impacts on organizations. Logging the use of privileged functions is one way to detect such misuse and mitigate risks from advanced persistent threats and insider threats.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-06 AC-06(09)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-06 AC-06(10)]

Supporting Publications: None


==== 03.01.08 Unsuccessful Logon Attempts ====

# Enforce a limit of [''Assignment: organization-defined number''] consecutive invalid logon attempts by a user during a [''Assignment: organization-defined time period''].
# Automatically [''Selection (one or more): lock the account or node for an'' [''Assignment: organization-defined time period'']''; lock the account or node until released by an administrator; delay next logon prompt; notify system administrator; take other action''] when the maximum number of unsuccessful attempts is exceeded.

===== DISCUSSION =====

Due to the potential for denial of service, automatic system lockouts are in most cases, temporary and automatically release after a predetermined time period established by the organization (i.e., using a delay algorithm). Organizations may employ different delay algorithms for different system components based on the capabilities of the respective components. Responses to unsuccessful system logon attempts may be implemented at the system and application levels.

Organization-defined actions that may be taken include prompting the user to answer a secret question in addition to the username and password, invoking a lockdown mode with limited user capabilities (instead of a full lockout), allowing users to only logon from specified Internet Protocol (IP) addresses, requiring a CAPTCHA to prevent automated attacks, or applying user profiles, such as location, time of day, IP address, device, or Media Access Control (MAC) address.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-07 AC-07]

Supporting Publications: SP 800-63-3 [[#bibr-ref_27|27]], SP 800-124 [[#bibr-ref_28|28]]


==== 03.01.09 System Use Notification ====

Display a system use notification message with privacy and security notices consistent with applicable CUI rules before granting access to the system.

===== DISCUSSION =====

System use notifications can be implemented using messages or warning banners. The messages or warning banners are displayed before individuals log in to a system that processes, stores, or transmits CUI. System use notifications are used for access via logon interfaces with human users and are not required when human interfaces do not exist. Organizations consider whether a secondary use notification is needed to access applications or other system resources after the initial network logon. Posters or other printed materials may be used in lieu of an automated system message. This requirement is related to [[#sec-sec_03.15.03|03.15.03]].

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-08 AC-08]

Supporting Publications: None


==== 03.01.10 Device Lock ====

# Prevent access to the system by [''Selection (one or more): initiating a device lock after'' [''Assignment: organization-defined time period''] ''of inactivity; requiring the user to initiate a device lock before leaving the system unattended''].
# Retain the device lock until the user reestablishes access using established identification and authentication procedures.
# Conceal, via the device lock, information previously visible on the display with a publicly viewable image.

===== DISCUSSION =====

Device locks are temporary actions taken to prevent access to the system when users depart from the immediate vicinity of the system but do not want to log out due to the temporary nature of their absences. Device locks can be implemented at the operating system level or application level. User-initiated device locking is behavior- or policy-based and requires users to take physical action to initiate the device lock. Device locks are not an acceptable substitute for logging out of the system (e.g., when organizations require users to log out at the end of workdays). Publicly viewable images can include static or dynamic images, such as patterns used with screen savers, solid colors, photographic images, a clock, a battery life indicator, or a blank screen with the caveat that controlled unclassified information is not displayed.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-11 AC-11], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-11 AC-11(01)]

Supporting Publications: None


==== 03.01.11 Session Termination ====

Terminate a user session automatically after [''Assignment: organization-defined conditions or trigger events requiring session disconnect''].

===== DISCUSSION =====

This requirement addresses the termination of user-initiated logical sessions in contrast to the termination of network connections that are associated with communications sessions (i.e., disconnecting from the network) in [[#sec-sec_03.13.09|03.13.09]]. A logical session is initiated whenever a user (or processes acting on behalf of a user) accesses a system. Logical sessions can be terminated (and thus terminate user access) without terminating network sessions. Session termination ends all system processes associated with a user’s logical session except those processes that are created by the user (i.e., session owner) to continue after the session is terminated. Conditions or trigger events that require automatic session termination can include organization-defined periods of user inactivity, time-of-day restrictions on system use, and targeted responses to certain types of incidents.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-12 AC-12]

Supporting Publications: None


==== 03.01.12 Remote Access ====

# Establish usage restrictions, configuration requirements, and connection requirements for each type of allowable remote system access.
# Authorize each type of remote system access prior to establishing such connections.
# Route remote access to the system through authorized and managed access control points.
# Authorize the remote execution of privileged commands and remote access to security-relevant information.

===== DISCUSSION =====

Remote access is access to systems (or processes acting on behalf of users) that communicate through external networks, such as the internet. Monitoring and controlling remote access methods allows organizations to detect attacks and ensure compliance with remote access policies. Routing remote access through managed access control points enhances explicit control over such connections and reduces susceptibility to unauthorized access to the system, which could result in the unauthorized disclosure of CUI.

Remote access to the system represents a significant potential vulnerability that can be exploited by adversaries. Restricting the execution of privileged commands and access to security-relevant information via remote access reduces the exposure of the organization and its susceptibility to threats by adversaries. A privileged command is a human-initiated command executed on a system that involves the control, monitoring, or administration of the system, including security functions and security-relevant information. Security-relevant information is information that can potentially impact the operation of security functions or the provision of security services in a manner that could result in failure to enforce the system security policy or maintain isolation of code and data. Privileged commands give individuals the ability to execute sensitive, security-critical, or security-relevant system functions.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-17 AC-17], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-17 AC-17(03)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-17 AC-17(04)]

Supporting Publications: SP 800-46 [[#bibr-ref_14|14]], SP 800-77 [[#bibr-ref_18|18]], SP 800-113 [[#bibr-ref_19|19]], SP 800-114 [[#bibr-ref_20|20]], SP 800-121 [[#bibr-ref_21|21]], IR 7966 [[#bibr-ref_26|26]]


==== 03.01.13 Withdrawn ====

Addressed by [[#sec-sec_03.13.08|03.13.08]].


==== 03.01.14 Withdrawn ====

Incorporated into [[#sec-sec_03.01.12|03.01.12]].


==== 03.01.15 Withdrawn ====

Incorporated into [[#sec-sec_03.01.12|03.01.12]].


==== 03.01.16 Wireless Access ====

# Establish usage restrictions, configuration requirements, and connection requirements for each type of wireless access to the system.
# Authorize each type of wireless access to the system prior to establishing such connections.
# Disable, when not intended for use, wireless networking capabilities prior to issuance and deployment.
# Protect wireless access to the system using authentication and encryption.

===== DISCUSSION =====

Wireless networking capabilities represent a significant potential vulnerability that can be exploited by adversaries. Establishing usage restrictions, configuration requirements, and connection requirements for wireless access to the system provides criteria to support access authorization decisions. These restrictions and requirements reduce susceptibility to unauthorized system access through wireless technologies. Wireless networks use authentication protocols that provide credential protection and mutual authentication. Organizations authenticate individuals and devices to protect wireless access to the system. Special attention is given to the variety of devices with potential wireless access to the system, including small form factor mobile devices (e.g., smart phones, tablets, smart watches). Wireless networking capabilities that are embedded within system components represent a potential vulnerability that can be exploited by adversaries. Strong authentication of users and devices, strong encryption, and disabling wireless capabilities that are not needed for essential mission or business functions can reduce susceptibility to threats by adversaries involving wireless technologies.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-18 AC-18], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-18 AC-18(01)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-18 AC-18(03)]

Supporting Publications: SP 800-94 [[#bibr-ref_29|29]], SP 800-97 [[#bibr-ref_30|30]], SP 800-124 [[#bibr-ref_28|28]]


==== 03.01.17 Withdrawn ====

Incorporated into [[#sec-sec_03.01.16|03.01.16]].


==== 03.01.18 Access Control for Mobile Devices ====

# Establish usage restrictions, configuration requirements, and connection requirements for mobile devices.
# Authorize the connection of mobile devices to the system.
# Implement full-device or container-based encryption to protect the confidentiality of CUI on mobile devices.

===== DISCUSSION =====

A mobile device is a computing device with a small form factor such that it can be carried by a single individual; is designed to operate without a physical connection; possesses local, non-removable, or removable data storage; and includes a self-contained power source. Mobile device functionality may include on-board sensors that allow the device to capture information, voice communication capabilities, and/or built-in features for synchronizing local data with remote locations. Examples include smart phones, smart watches, and tablets. Mobile devices are typically associated with a single individual. The processing, storage, and transmission capabilities of mobile devices may be comparable to or a subset of notebook or desktop systems, depending on the nature and intended purpose of the device. Some organizations may consider notebook computers to be mobile devices. The protection and control of mobile devices are behavior- or policy-based and require users to take physical action to protect and control such devices when outside of controlled areas. Controlled areas are spaces for which the organization provides physical or procedural controls to meet the requirements established for protecting CUI.

Due to the large variety of mobile devices with different characteristics and capabilities, organizational restrictions may vary for the different classes or types of such devices. Usage restrictions, configuration requirements, and connection requirements for mobile devices include configuration management, device identification and authentication, implementing mandatory protective software, scanning devices for malicious code, updating virus protection software, scanning for critical software updates and patches, conducting operating system and possibly other software integrity checks, and disabling unnecessary hardware. On mobile devices, secure containers provide software-based data isolation designed to segment enterprise applications and information from personal apps and data. Containers may present multiple user interfaces, one of the most common being a mobile application that acts as a portal to a suite of business productivity apps, such as email, contacts, and calendar. Organizations can employ full-device encryption or container-based encryption to protect the confidentiality of CUI on mobile devices.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-19 AC-19], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-19 AC-19(05)]

Supporting Publications: SP 800-46 [[#bibr-ref_14|14]], SP 800-114 [[#bibr-ref_31|31]], SP 800-124 [[#bibr-ref_28|28]]


==== 03.01.19 Withdrawn ====

Incorporated into [[#sec-sec_03.01.18|03.01.18]].


==== 03.01.20 Use of External Systems ====

# Prohibit the use of external systems unless the systems are specifically authorized.
# Establish the following security requirements to be satisfied on external systems prior to allowing use of or access to those systems by authorized individuals: [''Assignment: organization-defined security requirements''].
# Permit authorized individuals to use external systems to access the organizational system or to process, store, or transmit CUI only after:
## Verifying that the security requirements on the external systems as specified in the organization’s system security plans have been satisfied and
## Retaining approved system connection or processing agreements with the organizational entities hosting the external systems.
# Restrict the use of organization-controlled portable storage devices by authorized individuals on external systems.

===== DISCUSSION =====

External systems are systems that are used by but are not part of the organization. These systems include personally owned systems, system components, or devices; privately owned computing and communication devices in commercial or public facilities; systems owned or controlled by nonfederal organizations; and systems managed by contractors. Organizations have the option to prohibit the use of any type of external system or specified types of external systems (e.g., prohibit the use of external systems that are not organizationally owned). Terms and conditions are consistent with the trust relationships established with the entities that own, operate, or maintain external systems and include descriptions of shared responsibilities.

Authorized individuals include organizational personnel, contractors, or other individuals with authorized access to the organizational system and over whom organizations have the authority to impose specific rules of behavior regarding system access. Restrictions that organizations impose on authorized individuals may vary depending on the trust relationships between organizations. Organizations need assurance that external systems satisfy the necessary security requirements so as not to compromise, damage, or harm the system. This requirement is related to [[#sec-sec_03.16.03|03.16.03]].

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-20 AC-20], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-20 AC-20(01)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-20 AC-20(02)]

Supporting Publications: None


==== 03.01.21 Withdrawn ====

Incorporated into [[#sec-sec_03.01.20|03.01.20]].


==== 03.01.22 Publicly Accessible Content ====

# Train authorized individuals to ensure that publicly accessible information does not contain CUI.
# Review the content on publicly accessible systems for CUI and remove such information, if discovered.

===== DISCUSSION =====

In accordance with applicable laws, Executive Orders, directives, policies, regulations, standards, and guidelines, the public is not authorized to have access to nonpublic information, including CUI.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-22 AC-22]

Supporting Publications: None


=== 3.2 Awareness and Training ===


==== 03.02.01 Literacy Training and Awareness ====

# Provide security literacy training to system users:
## As part of initial training for new users and [''Assignment: organization-defined frequency''] thereafter,
## When required by system changes or following [''Assignment: organization-defined events''], and
## On recognizing and reporting indicators of insider threat, social engineering, and social mining.
# Update security literacy training content [''Assignment: organization-defined frequency''] and following [''Assignment: organization-defined events''].

===== DISCUSSION =====

Organizations provide basic and advanced levels of security literacy training to system users (including managers, senior executives, system administrators, and contractors) and measures to test the knowledge level of users. Organizations determine the content of literacy training based on specific organizational requirements, the systems to which personnel have authorized access, and work environments (e.g., telework). The content includes an understanding of the need for security and the actions required of users to maintain security and respond to incidents. The content also addresses the need for operations security and the handling of CUI.

Security awareness techniques include displaying posters, offering supplies inscribed with security reminders, generating email advisories or notices from organizational officials, displaying logon screen messages, and conducting awareness events using podcasts, videos, and webinars. Security literacy training is conducted at a frequency consistent with applicable laws, directives, regulations, and policies. Updating literacy training content on a regular basis ensures that the content remains relevant. Events that may precipitate an update to literacy training content include assessment or audit findings, security incidents or breaches, or changes in applicable laws, Executive Orders, directives, regulations, policies, standards, and guidelines.

Potential indicators and possible precursors of insider threats include behaviors such as inordinate, long-term job dissatisfaction; attempts to gain access to information that is not required for job performance; unexplained access to financial resources; sexual harassment or bullying of fellow employees; workplace violence; and other serious violations of the policies, procedures, rules, directives, or practices of organizations. Organizations may consider tailoring insider threat awareness topics to roles (e.g., training for managers may be focused on specific changes in the behavior of team members, while training for employees may be focused on more general observations).

Social engineering is an attempt to deceive an individual into revealing information or taking an action that can be used to breach, compromise, or otherwise adversely impact a system. Social engineering includes phishing, pretexting, impersonation, baiting, quid pro quo, threadjacking, social media exploitation, and tailgating. Social mining is an attempt to gather information about the organization that may be used to support future attacks. Security literacy training includes how to communicate employee and management concerns regarding potential indicators of insider threat and potential and actual instances of social engineering and data mining through appropriate organizational channels in accordance with established policies and procedures.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AT-02 AT-02], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AT-02 AT-02(02)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AT-02 AT-02(03)]

Supporting Publications: SP 800-50 [[#bibr-ref_32|32]], SP 800-160-2 [[#bibr-ref_10|10]]


==== 03.02.02 Role-Based Training ====

# Provide role-based security training to organizational personnel:
## Before authorizing access to the system or CUI, before performing assigned duties, and [''Assignment: organization-defined frequency''] thereafter
## When required by system changes or following [''Assignment: organization-defined events''].
# Update role-based training content [''Assignment: organization-defined frequency''] and following [''Assignment: organization-defined events''].

===== DISCUSSION =====

Organizations determine the content and frequency of security training based on the assigned duties, roles, and responsibilities of individuals and the security requirements of the systems to which personnel have authorized access. In addition, organizations provide system developers, enterprise architects, security architects, software developers, systems integrators, acquisition/procurement officials, system and network administrators, personnel conducting configuration management and auditing activities, personnel performing independent verification and validation, security assessors, and personnel with access to system-level software with security-related technical training specifically tailored for their assigned duties.

Comprehensive role-based training addresses management, operational, and technical roles and responsibilities that cover physical, personnel, and technical controls. Such training can include policies, procedures, tools, and artifacts for the security roles defined. Organizations also provide the training necessary for individuals to carry out their responsibilities related to operations and supply chain security within the context of organizational information security programs.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AT-03 AT-03]

Supporting Publications: SP 800-161 [[#bibr-ref_33|33]], SP 800-181 [[#bibr-ref_34|34]]


==== 03.02.03 Withdrawn ====

Incorporated into [[#sec-sec_03.02.01|03.02.01]].


=== 3.3 Audit and Accountability ===


==== 03.03.01 Event Logging ====

# Specify the following event types selected for logging within the system: [''Assignment: organization-defined event types''].
# Review and update the event types selected for logging [''Assignment: organization-defined frequency''].

===== DISCUSSION =====

An event is any observable occurrence in a system, including unlawful or unauthorized system activity. Organizations identify event types for which a logging functionality is needed. This includes events that are relevant to the security of systems and the environments in which those systems operate to meet specific and ongoing auditing needs. Event types can include password changes, the execution of privileged functions, failed logons or accesses related to systems, administrative privilege usage, or third-party credential usage. In determining event types that require logging, organizations consider the system monitoring and auditing that are appropriate for each of the security requirements. When defining event types, organizations consider the logging necessary to cover related events, such as the steps in distributed, transaction-based processes (e.g., processes that are distributed across multiple organizations) and actions that occur in service-oriented or cloud-based architectures.

Monitoring and auditing requirements can be balanced with other system needs. For example, organizations may determine that systems must have the capability to log every file access — both successful and unsuccessful — but only activate that capability under specific circumstances due to the potential burden on system performance. The event types that are logged by organizations may change over time. Reviewing and updating the set of logged event types are necessary to ensure that the current set of event types remains relevant.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-02 AU-02]

Supporting Publications: SP 800-92 [[#bibr-ref_35|35]]


==== 03.03.02 Audit Record Content ====

# Include the following content in audit records:
## What type of event occurred
## When the event occurred
## Where the event occurred
## Source of the event
## Outcome of the event
## Identity of the individuals, subjects, objects, or entities associated with the event
# Provide additional information for audit records as needed.

===== DISCUSSION =====

Audit record content that may be necessary to support the auditing function includes time stamps, source and destination addresses, user or process identifiers, event descriptions, file names, and the access control or flow control rules that are invoked. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the system after the event occurred). Detailed information that organizations consider in audit records may include a full text recording of privileged commands or the individual identities of group account users.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-03 AU-03], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-03 AU-03(01)]

Supporting Publications: None


==== 03.03.03 Audit Record Generation ====

# Generate audit records for the selected event types and audit record content specified in [[#sec-sec_03.03.01|03.03.01]] and [[#sec-sec_03.03.02|03.03.02]].
# Retain audit records for a time period consistent with the records retention policy.

===== DISCUSSION =====

Audit records can be generated at various levels of abstraction, including at the packet level as information traverses the network. Selecting the appropriate level of abstraction is a critical aspect of an audit logging capability and can facilitate the identification of root causes to problems. The ability to add information generated in audit records is dependent on system functionality to configure the audit record content. Organizations may consider additional information in audit records, including the access control or flow control rules invoked and the individual identities of group account users. Organizations may also consider limiting additional audit record information to only information that is explicitly needed for audit requirements.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-11 AU-11], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-12 AU-12]

Supporting Publications: SP 800-92 [[#bibr-ref_35|35]]


==== 03.03.04 Response to Audit Logging Process Failures ====

# Alert organizational personnel or roles within [''Assignment: organization-defined time period''] in the event of an audit logging process failure.
# Take the following additional actions: [''Assignment: organization-defined additional actions''].

===== DISCUSSION =====

Audit logging process failures include software and hardware errors, failures in audit log capturing mechanisms, and reaching or exceeding audit log storage capacity. Response actions include overwriting the oldest audit records, shutting down the system, and stopping the generation of audit records. Organizations may choose to define additional actions for audit logging process failures based on the type of failure, the location of the failure, the severity of the failure, or a combination of such factors. When the audit logging process failure is related to storage, the response is carried out for the audit log storage repository (i.e., the distinct system component where the audit logs are stored), the system on which the audit logs reside, the total audit log storage capacity of the organization (i.e., all audit log storage repositories combined), or all three. Organizations may decide to take no additional actions after alerting designated roles or personnel.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-05 AU-05]

Supporting Publications: None


==== 03.03.05 Audit Record Review, Analysis, and Reporting ====

# Review and analyze system audit records [''Assignment: organization-defined frequency''] for indications and the potential impact of inappropriate or unusual activity.
# Report findings to organizational personnel or roles.
# Analyze and correlate audit records across different repositories to gain organization-wide situational awareness.

===== DISCUSSION =====

Audit record review, analysis, and reporting cover information security logging performed by organizations and can include logging that results from the monitoring of account usage, remote access, wireless connectivity, configuration settings, the use of maintenance tools and nonlocal maintenance, system component inventory, mobile device connection, equipment delivery and removal, physical access, temperature and humidity, communications at system interfaces, and the use of mobile code. Findings can be reported to organizational entities, such as the incident response team, help desk, and security or privacy offices. If organizations are prohibited from reviewing and analyzing audit records or unable to conduct such activities, the review or analysis may be carried out by other organizations granted such authority. The scope, frequency, and/or depth of the audit record review, analysis, and reporting may be adjusted to meet organizational needs based on new information received. Correlating audit record review, analysis, and reporting processes helps to ensure that audit records collectively create a more complete view of events.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-06 AU-06], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-06 AU-06(03)]

Supporting Publications: SP 800-86 [[#bibr-ref_36|36]], SP 800-101 [[#bibr-ref_37|37]]


==== 03.03.06 Audit Record Reduction and Report Generation ====

# Implement an audit record reduction and report generation capability that supports audit record review, analysis, reporting requirements, and after-the-fact investigations of incidents.
# Preserve the original content and time ordering of audit records.

===== DISCUSSION =====

Audit records are generated in [[#sec-sec_03.03.03|03.03.03]]. Audit record reduction and report generation occur after audit record generation. Audit record reduction is a process that manipulates collected audit information and organizes it in a summary format that is more meaningful to analysts. Audit record reduction and report generation capabilities do not always come from the same system or organizational entities that conduct auditing activities. An audit record reduction capability can include, for example, modern data mining techniques with advanced data filters to identify anomalous behavior in audit records. The report generation capability provided by the system can help generate customizable reports. The time ordering of audit records can be a significant issue if the granularity of the time stamp in the record is insufficient.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-07 AU-07]

Supporting Publications: None


==== 03.03.07 Time Stamps ====

# Use internal system clocks to generate time stamps for audit records.
# Record time stamps for audit records that meet [''Assignment: organization-defined granularity of time measurement''] and that use Coordinated Universal Time (UTC), have a fixed local time offset from UTC, or include the local time offset as part of the time stamp.

===== DISCUSSION =====

Time stamps generated by the system include the date and time. Time is often expressed in Coordinated Universal Time (UTC) — a modern continuation of Greenwich Mean Time (GMT) — or local time with an offset from UTC. The granularity of time measurements refers to the degree of synchronization between system clocks and reference clocks (e.g., clocks synchronizing within hundreds or tens of milliseconds). Organizations may define different time granularities for system components. Time service can be critical to other security capabilities (e.g., access control and identification and authentication), depending on the nature of the mechanisms used to support those capabilities.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-08 AU-08]

Supporting Publications: None


==== 03.03.08 Protection of Audit Information ====

# Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
# Authorize access to management of audit logging functionality to only a subset of privileged users or roles.

===== DISCUSSION =====

Audit information includes the information needed to successfully audit system activity, such as audit records, audit log settings, audit reports, and personally identifiable information. Audit logging tools are programs and devices used to conduct audit and logging activities. The protection of audit information focuses on technical protection and limits the ability to access and execute audit logging tools to authorized individuals. The physical protection of audit information is addressed by media and physical protection requirements.

Individuals or roles with privileged access to a system and who are also the subject of an audit by that system may affect the reliability of the audit information by inhibiting audit activities or modifying audit records. Requiring privileged access to be further defined between audit-related privileges and other privileges limits the number of users or roles with audit-related privileges.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-09 AU-09], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-09 AU-09(04)]

Supporting Publications: None


==== 03.03.09 Withdrawn ====

Incorporated into [[#sec-sec_03.03.08|03.03.08]].


=== 3.4 Configuration Management ===


==== 03.04.01 Baseline Configuration ====

# Develop and maintain under configuration control, a current baseline configuration of the system.
# Review and update the baseline configuration of the system [''Assignment: organization-defined frequency''] and when system components are installed or modified.

===== DISCUSSION =====

Baseline configurations for the system and system components include aspects of connectivity, operation, and communications. Baseline configurations are documented, formally reviewed, and agreed-upon specifications for the system or configuration items within the system. Baseline configurations serve as a basis for future builds, releases, or changes to the system and include information about system components, operational procedures, network topology, and the placement of components in the system architecture. Maintaining baseline configurations requires creating new baselines as the system changes over time. Baseline configurations of the system reflect the current enterprise architecture.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-02 CM-02]

Supporting Publications: SP 800-124 [[#bibr-ref_28|28]], SP 800-128 [[#bibr-ref_41|41]], IR 8011-2 [[#bibr-ref_42|42]], IR 8011-3 [[#bibr-ref_43|43]]


==== 03.04.02 Configuration Settings ====

# Establish, document, and implement the following configuration settings for the system that reflect the most restrictive mode consistent with operational requirements: [''Assignment: organization-defined configuration settings''].
# Identify, document, and approve any deviations from established configuration settings.

===== DISCUSSION =====

Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the system and that affect the security posture or functionality of the system. Security-related configuration settings can be defined for systems (e.g., servers, workstations), input and output devices (e.g., scanners, copiers, printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications.

Security parameters are those parameters that impact the security state of the system, including the parameters required to satisfy other security requirements. Security parameters include registry settings; account, file, and directory permission settings (i.e., privileges); and settings for functions, ports, protocols, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific configuration settings for the system. The established settings become part of the system’s configuration baseline.

Common secure configurations (also referred to as security configuration checklists, lockdown and hardening guides, security reference guides, and security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations, including information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-06 CM-06]

Supporting Publications: SP 800-70 [[#bibr-ref_44|44]], SP 800-126 [[#bibr-ref_45|45]], SP 800-128 [[#bibr-ref_41|41]]


==== 03.04.03 Configuration Change Control ====

# Define the types of changes to the system that are configuration-controlled.
# Review proposed configuration-controlled changes to the system, and approve or disapprove such changes with explicit consideration for security impacts.
# Implement and document approved configuration-controlled changes to the system.
# Monitor and review activities associated with configuration-controlled changes to the system.

===== DISCUSSION =====

Configuration change control refers to tracking, reviewing, approving or disapproving, and logging changes to the system. Specifically, it involves the systematic proposal, justification, implementation, testing, review, and disposition of changes to the system, including system upgrades and modifications. Configuration change control includes changes to baseline configurations for system components (e.g., operating systems, applications, firewalls, routers, mobile devices) and configuration items of the system, changes to configuration settings, unscheduled and unauthorized changes, and changes to remediate vulnerabilities. This requirement is related to [[#sec-sec_03.04.04|03.04.04]].

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-03 CM-03]

Supporting Publications: SP 800-124 [[#bibr-ref_28|28]], SP 800-128 [[#bibr-ref_41|41]]


==== 03.04.04 Impact Analyses ====

# Analyze changes to the system to determine potential security impacts prior to change implementation.
# Verify that the security requirements for the system continue to be satisfied after the system changes have been implemented.

===== DISCUSSION =====

Organizational personnel with security responsibilities conduct impact analyses that include reviewing system security plans, policies, and procedures to understand security requirements; reviewing system design documentation and operational procedures to understand how system changes might affect the security state of the system; reviewing the impacts of system changes on supply chain partners with stakeholders; and determining how potential changes to a system create new risks and the ability to mitigate those risks. Impact analyses also include risk assessments to understand the impacts of changes and determine whether additional security requirements are needed. Changes to the system may affect the safeguards and countermeasures previously implemented. This requirement is related to [[#sec-sec_03.04.03|03.04.03]]. Not all changes to the system are configuration controlled.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-04 CM-04], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-04 CM-04(02)]

Supporting Publications: SP 800-128 [[#bibr-ref_41|41]]


==== 03.04.05 Access Restrictions for Change ====

Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system.

===== DISCUSSION =====

Changes to the hardware, software, or firmware components of the system or the operational procedures related to the system can have potentially significant effects on the security of the system. Therefore, organizations permit only qualified and authorized individuals to access the system for the purpose of initiating changes. Access restrictions include physical and logical access controls, software libraries, workflow automation, media libraries, abstract layers (i.e., changes implemented into external interfaces rather than directly into the system), and change windows (i.e., changes occur only during specified times).

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-05 CM-05]

Supporting Publications: FIPS 140-3 [[#bibr-ref_38|38]], FIPS 180-4 [[#bibr-ref_39|39]], SP 800-128 [[#bibr-ref_41|41]]


==== 03.04.06 Least Functionality ====

# Configure the system to provide only mission-essential capabilities.
# Prohibit or restrict use of the following functions, ports, protocols, connections, and services: [''Assignment: organization-defined functions, ports, protocols, connections, and services''].
# Review the system [''Assignment: organization-defined frequency''] to identify unnecessary or nonsecure functions, ports, protocols, connections, and services.
# Disable or remove functions, ports, protocols, connections, and services that are unnecessary or nonsecure.

===== DISCUSSION =====

Systems can provide a variety of functions and services. Some functions and services that are routinely provided by default may not be necessary to support essential organizational missions, functions, or operations. It may be convenient to provide multiple services from single system components. However, doing so increases risk over limiting the services provided by any one component. Where feasible, organizations limit functionality to a single function per component.

Organizations review the functions and services provided by the system or system components to determine which functions and services are candidates for elimination. Organizations disable unused or unnecessary physical and logical ports and protocols to prevent the unauthorized connection of devices, the transfer of information, and tunneling. Organizations can employ network scanning tools, intrusion detection and prevention systems, and endpoint protection systems (e.g., firewalls and host-based intrusion detection systems) to identify and prevent the use of prohibited functions, ports, protocols, system connections, and services. Bluetooth, File Transfer Protocol (FTP), and peer-to-peer networking are examples of the types of protocols that organizations consider eliminating, restricting, or disabling.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-07 CM-07], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-07 CM-07(01)]

Supporting Publications: SP 800-160-1 [[#bibr-ref_11|11]], SP 800-167 [[#bibr-ref_46|46]]


==== 03.04.07 Withdrawn ====

Incorporated into [[#sec-sec_03.04.06|03.04.06]] and [[#sec-sec_03.04.08|03.04.08]].


==== 03.04.08 Authorized Software – Allow by Exception ====

# Identify software programs authorized to execute on the system.
# Implement a deny-all, allow-by-exception policy for the execution of authorized software programs on the system.
# Review and update the list of authorized software programs [''Assignment: organization-defined frequency''].

===== DISCUSSION =====

If provided with the necessary privileges, users can install software in organizational systems. To maintain control over the software installed, organizations identify permitted and prohibited actions regarding software installation. Permitted software installations include updates and security patches to existing software and downloading new applications from organization-approved “app stores.” The policies selected for governing user-installed software are organization-developed or provided by some external entity. Policy enforcement methods can include procedural methods and automated methods.

Authorized software programs can be limited to specific versions or come from specific sources. To facilitate a comprehensive authorized software process and increase the strength of protection against attacks that bypass application-level authorized software, software programs may be decomposed into and monitored at different levels of detail. These levels include applications, application programming interfaces, application modules, scripts, system processes, system services, kernel functions, registries, drivers, and dynamic link libraries.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-07 CM-07(05)]

Supporting Publications: SP 800-160-1 [[#bibr-ref_11|11]], SP 800-167 [[#bibr-ref_46|46]]


==== 03.04.09 Withdrawn ====

Addressed by [[#sec-sec_03.01.05|03.01.05]], [[#sec-sec_03.04.08|03.04.08]], and [[#sec-sec_03.12.03|03.12.03]].


==== 03.04.10 System Component Inventory ====

# Develop and document an inventory of system components.
# Review and update the system component inventory [''Assignment: organization-defined frequency''].
# Update the system component inventory as part of installations, removals, and system updates.

===== DISCUSSION =====

System components are discrete, identifiable assets (i.e., hardware, software, and firmware elements) that compose a system. Organizations may implement centralized system component inventories that include components from all systems. In such situations, organizations ensure that the inventories include the system-specific information required for component accountability. The information necessary for effective accountability of system components includes the system name, software owners, software version numbers, software license information, hardware inventory specifications, and — for networked components — the machine names and network addresses for all implemented protocols (e.g., IPv4, IPv6). Inventory specifications include component type, physical location, date of receipt, manufacturer, cost, model, serial number, and supplier information.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-08 CM-08], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-08 CM-08(01)]

Supporting Publications: SP 800-124 [[#bibr-ref_28|28]], SP 800-128 [[#bibr-ref_41|41]], IR 8011-2 [[#bibr-ref_42|42]], IR 8011-3 [[#bibr-ref_43|43]]


==== 03.04.11 Information Location ====

# Identify and document the location of CUI and the system components on which the information is processed and stored.
# Document changes to the system or system component location where CUI is processed and stored.

===== DISCUSSION =====

Information location addresses the need to understand the specific system components where CUI is being processed and stored and the users who have access to CUI so that appropriate protection mechanisms can be provided, including information flow controls, access controls, and information management.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-12 CM-12]

Supporting Publications: None


==== 03.04.12 System and Component Configuration for High-Risk Areas ====

# Issue systems or system components with the following configurations to individuals traveling to high-risk locations: [''Assignment: organization-defined system configurations''].
# Apply the following security requirements to the systems or components when the individuals return from travel: [''Assignment: organization-defined security requirements''].

===== DISCUSSION =====

When it is known that a system or a system component will be in a high-risk area, additional security requirements may be needed to counter the increased threat. Organizations can implement protective measures on the systems or system components used by individuals departing on and returning from travel. Actions include determining whether the locations are of concern, defining the required configurations for the components, ensuring that the components are configured as intended before travel is initiated, and taking additional actions after travel is completed. For example, systems going into high-risk areas can be configured with sanitized hard drives, limited applications, and more stringent configuration settings. Actions applied to mobile devices upon return from travel include examining the device for signs of physical tampering and purging and reimaging the device storage.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-02 CM-02(07)]

Supporting Publications: SP 800-124 [[#bibr-ref_28|28]], SP 800-128 [[#bibr-ref_41|41]]


=== 3.5 Identification and Authentication ===


==== 03.05.01 User Identification and Authentication ====

# Uniquely identify and authenticate system users, and associate that unique identification with processes acting on behalf of those users.
# Re-authenticate users when [''Assignment: organization-defined circumstances or situations requiring re-authentication''].

===== DISCUSSION =====

System users include individuals (or system processes acting on behalf of individuals) who are authorized to access a system. Typically, individual identifiers are the usernames associated with the system accounts assigned to those individuals. Since system processes execute on behalf of groups and roles, organizations may require the unique identification of individuals in group accounts or the accountability of individual activity. The unique identification and authentication of users apply to all system accesses. Organizations use passwords, physical authenticators, biometrics, or some combination thereof to authenticate user identities. Organizations may re-authenticate individuals in certain situations, including when roles, authenticators, or credentials change; when the execution of privileged functions occurs; after a fixed time period; or periodically.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-02 IA-02], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-11 IA-11]

Supporting Publications: SP 800-63-3 [[#bibr-ref_27|27]]


==== 03.05.02 Device Identification and Authentication ====

Uniquely identify and authenticate [''Assignment: organization-defined devices or types of devices''] before establishing a system connection.

===== DISCUSSION =====

Devices that require unique device-to-device identification and authentication are defined by type, device, or a combination of type and device. Organization-defined device types include devices that are not owned by the organization. Systems use shared known information (e.g., Media Access Control [MAC], Transmission Control Protocol/Internet Protocol [TCP/IP] addresses) for device identification or organizational authentication solutions (e.g., Institute of Electrical and Electronics Engineers [IEEE] 802.1x and Extensible Authentication Protocol [EAP], RADIUS server with EAP-Transport Layer Security [TLS] authentication, Kerberos) to identify and authenticate devices on local and wide area networks. Public Key Infrastructure (PKI) and certificate revocation checking for the certificates exchanged can be included as part of device authentication.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-03 IA-03]

Supporting Publications: SP 800-63-3 [[#bibr-ref_27|27]]


==== 03.05.03 Multi-Factor Authentication ====

Implement multi-factor authentication for access to privileged and non-privileged accounts.

===== DISCUSSION =====

This requirement applies to user accounts. Multi-factor authentication requires the use of two or more different factors to achieve authentication. The authentication factors are defined as follows: something you know (e.g., a personal identification number [PIN]), something you have (e.g., a physical authenticator, such as a cryptographic private key), or something you are (e.g., a biometric). Multi-factor authentication solutions that feature physical authenticators include hardware authenticators that provide time-based or challenge-response outputs and smart cards. In addition to authenticating users at the system level, organizations may also employ authentication mechanisms at the application level to provide increased information security.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-02 IA-02(01)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-02 IA-02(02)]

Supporting Publications: SP 800-63-3 [[#bibr-ref_27|27]]


==== 03.05.04 Replay-Resistant Authentication ====

Implement replay-resistant authentication mechanisms for access to privileged and non-privileged accounts.

===== DISCUSSION =====

Authentication processes resist replay attacks if it is impractical to successfully authenticate by recording or replaying previous authentication messages. Replay-resistant techniques include protocols that use nonces or challenges, such as time synchronous or challenge-response one-time authenticators.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-02 IA-02(08)]

Supporting Publications: SP 800-63-3 [[#bibr-ref_27|27]]


==== 03.05.05 Identifier Management ====

# Receive authorization from organizational personnel or roles to assign an individual, group, role, service, or device identifier.
# Select and assign an identifier that identifies an individual, group, role, service, or device.
# Prevent the reuse of identifiers for [''Assignment: organization-defined time period''].
# Manage individual identifiers by uniquely identifying each individual as [''Assignment: organization-defined characteristic identifying individual status''].

===== DISCUSSION =====

Identifiers are provided for users, processes acting on behalf of users, and devices. Prohibiting the reuse of identifiers prevents the assignment of previously used individual, group, role, service, or device identifiers to different individuals, groups, roles, services, or devices.

Characteristics that identify the status of individuals include contractors, foreign nationals, and non-organizational users. Identifying the status of individuals by these characteristics provides information about the people with whom organizational personnel are communicating. For example, it is useful for an employee to know that one of the individuals on an email message is a contractor.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-04 IA-04], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-04 IA-04(04)]

Supporting Publications: SP 800-63-3 [[#bibr-ref_27|27]]


==== 03.05.06 Withdrawn ====

Consistency with SP 800-53 [[#bibr-ref_8|8]].


==== 03.05.07 Password Management ====

# Maintain a list of commonly-used, expected, or compromised passwords, and update the list [''Assignment: organization-defined frequency''] and when organizational passwords are suspected to have been compromised.
# Verify that passwords are not found on the list of commonly used, expected, or compromised passwords when users create or update passwords.
# Transmit passwords only over cryptographically protected channels.
# Store passwords in a cryptographically protected form.
# Select a new password upon first use after account recovery.
# Enforce the following composition and complexity rules for passwords: [''Assignment: organization-defined composition and complexity rules''].

===== DISCUSSION =====

Password-based authentication applies to passwords used in single-factor or multi-factor authentication. Long passwords or passphrases are preferable to shorter passwords. Enforced composition rules provide marginal security benefits while decreasing usability. However, organizations may choose to establish and enforce certain rules for password generation (e.g., minimum character length) under certain circumstances. For example, account recovery can occur when a password is forgotten. Cryptographically protected passwords include salted one-way cryptographic hashes of passwords. The list of commonly used, compromised, or expected passwords includes passwords obtained from previous breach corpuses, dictionary words, and repetitive or sequential characters. The list includes context-specific words, such as the name of the service, username, and derivatives thereof. Changing temporary passwords to permanent passwords immediately after system logon ensures that the necessary strength of the authentication mechanism is implemented at the earliest opportunity and reduces susceptibility to authenticator compromises. Long passwords and passphrases can be used to increase the complexity of passwords.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-05 IA-05(01)]

Supporting Publications: SP 800-63-3 [[#bibr-ref_27|27]]


==== 03.05.08 Withdrawn ====

Consistency with SP 800-53 [[#bibr-ref_8|8]].


==== 03.05.09 Withdrawn ====

Consistency with SP 800-53 [[#bibr-ref_8|8]].


==== 03.05.10 Withdrawn ====

Incorporated into [[#sec-sec_03.05.07|03.05.07]].


==== 03.05.11 Authentication Feedback ====

Obscure feedback of authentication information during the authentication process.

===== DISCUSSION =====

Authentication feedback does not provide information that would allow unauthorized individuals to compromise authentication mechanisms. For example, for desktop or notebook systems with relatively large monitors, the threat may be significant (commonly referred to as shoulder surfing). For mobile devices with small displays, this threat may be less significant and is balanced against the increased likelihood of input errors due to small keyboards. Therefore, the means of obscuring authenticator feedback is selected accordingly. Obscuring feedback includes displaying asterisks when users type passwords into input devices or displaying feedback for a limited time before fully obscuring it.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-06 IA-06]

Supporting Publications: None


==== 03.05.12 Authenticator Management ====

# Verify the identity of the individual, group, role, service, or device receiving the authenticator as part of the initial authenticator distribution.
# Establish initial authenticator content for any authenticators issued by the organization.
# Establish and implement administrative procedures for initial authenticator distribution; for lost, compromised, or damaged authenticators; and for revoking authenticators.
# Change default authenticators at first use.
# Change or refresh authenticators [''Assignment: organization-defined frequency''] or when the following events occur: [''Assignment: organization-defined events''].
# Protect authenticator content from unauthorized disclosure and modification.

===== DISCUSSION =====

Authenticators include passwords, cryptographic devices, biometrics, certificates, one-time password devices, and ID badges. The initial authenticator content is the actual content of the authenticator (e.g., the initial password). In contrast, requirements for authenticator content contain specific characteristics. Authenticator management is supported by organization-defined settings and restrictions for various authenticator characteristics (e.g., password complexity and composition rules, validation time window for time synchronous one-time tokens, and the number of allowed rejections during the verification stage of biometric authentication).

The requirement to protect individual authenticators may be implemented by [[#sec-sec_03.15.03|03.15.03]] for authenticators in the possession of individuals and by [[#sec-sec_03.01.01|03.01.01]], [[#sec-sec_03.01.02|03.01.02]], [[#sec-sec_03.01.05|03.01.05]], and [[#sec-sec_03.13.08|03.13.08]] for authenticators stored in organizational systems. This includes passwords stored in hashed or encrypted formats or files that contain hashed or encrypted passwords that are accessible with administrator privileges. Actions can be taken to protect authenticators, including maintaining possession of authenticators, not sharing authenticators with others, and immediately reporting lost, stolen, or compromised authenticators.

Developers may deliver system components with factory default authentication credentials to allow for initial installation and configuration. Default authentication credentials are often well-known, easily discoverable, and present a significant risk. Authenticator management includes issuing and revoking authenticators for temporary access when they are no longer needed. The use of long passwords or passphrases may obviate the need to periodically change authenticators.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-05 IA-05]

Supporting Publications: SP 800-63-3 [[#bibr-ref_27|27]]


=== 3.6 Incident Response ===


==== 03.06.01 Incident Handling ====

Implement an incident-handling capability that is consistent with the incident response plan and includes preparation, detection and analysis, containment, eradication, and recovery.

===== DISCUSSION =====

Incident-related information can be obtained from a variety of sources, including audit monitoring, network monitoring, physical access monitoring, user and administrator reports, and reported supply chain events. An effective incident handling capability involves coordination among many organizational entities, including mission and business owners, system owners, human resources offices, physical and personnel security offices, legal departments, operations personnel, and procurement offices.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IR-04 IR-04]

Supporting Publications: SP 800-50 [[#bibr-ref_32|32]], SP 800-61 [[#bibr-ref_47|47]], SP 800-161 [[#bibr-ref_33|33]]


==== 03.06.02 Incident Monitoring, Reporting, and Response Assistance ====

# Track and document system security incidents.
# [''Assignment: organization-defined time period''].
# Report incident information to [''Assignment: organization-defined authorities''].
# Provide an incident response support resource that offers advice and assistance to system users on handling and reporting incidents.

===== DISCUSSION =====

Documenting incidents includes maintaining records about each incident, the status of the incident, and other pertinent information necessary for forensics as well as evaluating incident details, trends, and handling. Incident information can be obtained from many sources, including network monitoring, incident reports, incident response teams, user complaints, supply chain partners, audit monitoring, physical access monitoring, and user and administrator reports. [[#sec-sec_03.06.01|03.06.01]] provides information on the types of incidents that are appropriate for monitoring. The types of incidents reported, the content and timeliness of the reports, and the reporting authorities reflect applicable laws, Executive Orders, directives, regulations, policies, standards, and guidelines. Incident information informs risk assessments, the effectiveness of security assessments, the security requirements for acquisitions, and the selection criteria for technology products. Incident response support resources provided by organizations include help desks, assistance groups, automated ticketing systems to open and track incident response tickets, and access to forensic services or consumer redress services, when required.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IR-05 IR-05], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IR-06 IR-06], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IR-07 IR-07]

Supporting Publications: SP 800-61 [[#bibr-ref_47|47]], SP 800-86 [[#bibr-ref_36|36]]


==== 03.06.03 Incident Response Testing ====

Test the effectiveness of the incident response capability [''Assignment: organization-defined frequency''].

===== DISCUSSION =====

Organizations test incident response capabilities to determine their effectiveness and identify potential weaknesses or deficiencies. Incident response testing includes the use of checklists, walk-through or tabletop exercises, and simulations. Incident response testing can include a determination of the effects of incident response on organizational operations, organizational assets, and individuals. Qualitative and quantitative data can help determine the effectiveness of incident response processes.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IR-03 IR-03]

Supporting Publications: SP 800-84 [[#bibr-ref_48|48]]


==== 03.06.04 Incident Response Training ====

# Provide incident response training to system users consistent with assigned roles and responsibilities:
## Within [''Assignment: organization-defined time period''] of assuming an incident response role or responsibility or acquiring system access,
## When required by system changes, and
## [''Assignment: organization-defined frequency''] thereafter.
# Review and update incident response training content [''Assignment: organization-defined frequency''] and following [''Assignment: organization-defined events''].

===== DISCUSSION =====

Incident response training is associated with the assigned roles and responsibilities of organizational personnel to ensure that the appropriate content and level of detail are included in such training. For example, users may only need to know how to recognize an incident or whom to call; system administrators may require additional training on how to handle incidents; and incident responders may receive specific training on data collection techniques, forensics, reporting, system recovery, and system restoration. Incident response training includes user training in identifying and reporting suspicious activities from external and internal sources. Incident response training for users may be provided as part of [[#sec-sec_03.02.02|03.02.02]]. Events that may cause an update to incident response training content include incident response plan testing, response to an actual incident, audit or assessment findings, or changes in applicable laws, Executive Orders, policies, directives, regulations, standards, and guidelines.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IR-02 IR-02]

Supporting Publications: SP 800-86 [[#bibr-ref_36|36]], SP 800-137 [[#bibr-ref_49|49]]


==== 03.06.05 Incident Response Plan ====

# Develop an incident response plan that:
## Provides the organization with a roadmap for implementing its incident response capability,
## Describes the structure and organization of the incident response capability,
## Provides a high-level approach for how the incident response capability fits into the overall organization,
## Defines reportable incidents,
## Addresses the sharing of incident information, and
## Designates responsibilities to organizational entities, personnel, or roles.
# Distribute copies of the incident response plan to designated incident response personnel (identified by name and/or by role) and organizational elements.
# Update the incident response plan to address system and organizational changes or problems encountered during plan implementation, execution, or testing.
# Protect the incident response plan from unauthorized disclosure.

===== DISCUSSION =====

It is important that organizations develop and implement a coordinated approach to incident response. Organizational mission and business functions determine the structure of incident response capabilities. As part of the incident response capabilities, organizations consider the coordination and sharing of information with external organizations, including external service providers and other organizations involved in the supply chain.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IR-08 IR-08]

Supporting Publications: SP 800-86 [[#bibr-ref_36|36]], SP 800-137 [[#bibr-ref_49|49]]


=== 3.7 Maintenance ===


==== 03.07.01 Withdrawn ====

Recategorized as NCO.


==== 03.07.02 Withdrawn ====

Incorporated into [[#sec-sec_03.07.04|03.07.04]] and [[#sec-sec_03.07.06|03.07.06]].


==== 03.07.03 Withdrawn ====

Incorporated into [[#sec-sec_03.08.03|03.08.03]].


==== 03.07.04 Maintenance Tools ====

# Approve, control, and monitor the use of system maintenance tools.
# Check media with diagnostic and test programs for malicious code before it is used in the system.

Prevent the removal of system maintenance equipment containing CUI by verifying that there is no CUI on the equipment, sanitizing or destroying the equipment, or retaining the equipment within the facility.

===== DISCUSSION =====

Approving, controlling, monitoring, and reviewing maintenance tools address security-related issues associated with the tools that are used for diagnostic and repair actions on the system. Maintenance tools can include hardware and software diagnostic and test equipment as well as packet sniffers. The tools may be pre-installed, brought in with maintenance personnel on media, cloud-based, or downloaded from a website. Diagnostic and test programs are potential vehicles for transporting malicious code into the system, either intentionally or unintentionally. Examples of media inspection include checking the cryptographic hash or digital signatures of diagnostic and test programs and media.

If organizations inspect media that contain diagnostic and test programs and determine that the media also contain malicious code, the incident is handled consistent with incident handling policies and procedures. A periodic review of system maintenance tools can result in the withdrawal of approval for outdated, unsupported, irrelevant, or no-longer-used tools. Maintenance tools do not address the hardware and software components that support maintenance and are considered a part of the system.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MA-03 MA-03], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MA-03 MA-03(01)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MA-03 MA-03(02)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MA-03 MA-03(03)]

Supporting Publications: SP 800-88 [[#bibr-ref_50|50]]


==== 03.07.05 Nonlocal Maintenance ====

# Approve and monitor nonlocal maintenance and diagnostic activities.
# Implement multi-factor authentication and replay resistance in the establishment of nonlocal maintenance and diagnostic sessions.
# Terminate session and network connections when nonlocal maintenance is completed.

===== DISCUSSION =====

Nonlocal maintenance and diagnostic activities are conducted by individuals who communicate through an external or internal network. Local maintenance and diagnostic activities are carried out by individuals who are physically present at the location of the system and not communicating across a network connection. Authentication techniques used to establish nonlocal maintenance and diagnostic sessions reflect the requirements in [[#sec-sec_03.05.01|03.05.01]].

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MA-04 MA-04]

Supporting Publications: SP 800-63-3 [[#bibr-ref_27|27]], SP 800-88 [[#bibr-ref_50|50]]


==== 03.07.06 Maintenance Personnel ====

# Establish a process for maintenance personnel authorization.
# Maintain a list of authorized maintenance organizations or personnel.
# Verify that non-escorted personnel who perform maintenance on the system possess the required access authorizations.
# Designate organizational personnel with required access authorizations and technical competence to supervise the maintenance activities of personnel who do not possess the required access authorizations.

===== DISCUSSION =====

Maintenance personnel refers to individuals who perform hardware or software maintenance on the system, while [[#sec-sec_03.10.01|03.10.01]] addresses physical access for individuals whose maintenance duties place them within the physical protection perimeter of the system. The technical competence of supervising individuals relates to the maintenance performed on the system, while having required access authorizations refers to maintenance on and near the system. Individuals who have not been previously identified as authorized maintenance personnel (e.g., manufacturers, consultants, systems integrators, and vendors) may require privileged access to the system, such as when they are required to conduct maintenance with little or no notice. Organizations may choose to issue temporary credentials to these individuals based on their risk assessments. Temporary credentials may be for one-time use or for very limited time periods.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MA-05 MA-05]

Supporting Publications: None


=== 3.8 Media Protection ===


==== 03.08.01 Media Storage ====

Physically control and securely store system media that contain CUI.

===== DISCUSSION =====

System media include digital and non-digital media. Digital media include diskettes, flash drives, magnetic tapes, external or removable solid state or magnetic drives, compact discs, and digital versatile discs. Non-digital media include paper and microfilm. Physically controlling stored media includes conducting inventories, establishing procedures to allow individuals to check out and return media to libraries, and maintaining accountability for stored media. Secure storage includes a locked drawer, desk, or cabinet or a controlled media library. Controlled areas provide physical and procedural controls to meet the requirements established for protecting information and systems. Sanitization techniques (e.g., destroying, cryptographically erasing, clearing, and purging) prevent the disclosure of CUI to unauthorized individuals. The sanitization process removes CUI from media such that the information cannot be retrieved or reconstructed.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MP-04 MP-04]

Supporting Publications: SP 800-88 [[#bibr-ref_50|50]], SP 800-111 [[#bibr-ref_51|51]]


==== 03.08.02 Media Access ====

Restrict access to CUI on system media to authorized personnel or roles.

===== DISCUSSION =====

System media include digital and non-digital media. Access to CUI on system media can be restricted by physically controlling such media. This includes conducting inventories, ensuring that procedures are in place to allow individuals to check out and return media to the media library, and maintaining accountability for stored media. For digital media, access to CUI can be restricted by using cryptographic means. Encrypting data in storage or at rest is addressed in [[#sec-sec_03.13.08|03.13.08]].

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MP-02 MP-02]

Supporting Publications: SP 800-111 [[#bibr-ref_51|51]]


==== 03.08.03 Media Sanitization ====

Sanitize system media that contain CUI prior to disposal, release out of organizational control, or release for reuse.

===== DISCUSSION =====

Media sanitization applies to digital and non-digital media that are subject to disposal or reuse, whether or not the media are considered removable. Examples include digital media in scanners, copiers, printers, notebook computers, mobile devices, workstations, network components, and non-digital media. The sanitization process removes CUI from media such that the information cannot be retrieved or reconstructed. Sanitization techniques (e.g., cryptographically erasing, clearing, purging, and destroying) prevent the disclosure of CUI to unauthorized individuals when such media are reused or released for disposal. NARA policies control the sanitization process for media that contain CUI and may require destruction when other methods cannot be applied to the media.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MP-06 MP-06]

Supporting Publications: SP 800-88 [[#bibr-ref_50|50]]


==== 03.08.04 Media Marking ====

Mark system media that contain CUI to indicate distribution limitations, handling caveats, and applicable CUI markings.

===== DISCUSSION =====

System media include digital and non-digital media. Marking refers to the use or application of human-readable security attributes. Labeling refers to the use of security attributes for internal system data structures. Digital media include diskettes, magnetic tapes, external or removable solid state or magnetic drives, flash drives, compact discs, and digital versatile discs. Non-digital media include paper and microfilm. CUI is defined by NARA along with marking, safeguarding, and dissemination requirements for such information.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MP-03 MP-03]

Supporting Publications: None


==== 03.08.05 Media Transport ====

# Protect and control system media that contain CUI during transport outside of controlled areas.
# Maintain accountability of system media that contain CUI during transport outside of controlled areas.
# Document activities associated with the transport of system media that contain CUI.

===== DISCUSSION =====

System media include digital and non-digital media. Digital media include flash drives, diskettes, magnetic tapes, external or removable solid state or magnetic drives, compact discs, and digital versatile discs. Non-digital media include microfilm and paper. Controlled areas are spaces for which organizations provide physical or procedural measures to meet the requirements established for protecting CUI and systems. Media protection during transport can include cryptography and/or locked containers. Activities associated with media transport include releasing media for transport, ensuring that media enter the appropriate transport processes, and the actual transport. Authorized transport and courier personnel may include individuals external to the organization. Maintaining accountability of media during transport includes restricting transport activities to authorized personnel and tracking or obtaining the records of transport activities as the media move through the transportation system to prevent and detect loss, destruction, or tampering. This requirement is related to [[#sec-sec_03.13.08|03.13.08]] and [[#sec-sec_03.13.11|03.13.11]].

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MP-05 MP-05], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-28 SC-28]

Supporting Publications: SP 800-111 [[#bibr-ref_51|51]]


==== 03.08.06 Withdrawn ====

Addressed by [[#sec-sec_03.13.08|03.13.08]].


==== 03.08.07 Media Use ====

# Restrict or prohibit the use of [''Assignment: organization-defined types of system media''].
# Prohibit the use of removable system media without an identifiable owner.

===== DISCUSSION =====

In contrast to requirement [[#sec-sec_03.08.01|03.08.01]], which restricts user access to media, this requirement restricts or prohibits the use of certain types of media, such as external hard drives, flash drives, or smart displays. Organizations can use technical and non-technical measures (e.g., policies, procedures, and rules of behavior) to control the use of system media. For example, organizations may control the use of portable storage devices by using physical cages on workstations to prohibit access to external ports or disabling or removing the ability to insert, read, or write to devices.

Organizations may limit the use of portable storage devices to only approved devices, including devices provided by the organization, devices provided by other approved organizations, and devices that are not personally owned. Organizations may also control the use of portable storage devices based on the type of device — prohibiting the use of writeable, portable devices — and implement this restriction by disabling or removing the capability to write to such devices. Limits on the use of organization-controlled system media in external systems include restrictions on how the media may be used and under what conditions. Requiring identifiable owners (e.g., individuals, organizations, or projects) for removable system media reduces the risk of using such technologies by allowing organizations to assign responsibility and accountability for addressing known vulnerabilities in the media (e.g., insertion of malicious code).

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MP-07 MP-07]

Supporting Publications: SP 800-111 [[#bibr-ref_51|51]]


==== 03.08.08 Withdrawn ====

Incorporated into [[#sec-sec_03.08.07|03.08.07]].


==== 03.08.09 System Backup – Cryptographic Protection ====

# Protect the confidentiality of backup information.
# Implement cryptographic mechanisms to prevent the unauthorized disclosure of CUI at backup storage locations.

===== DISCUSSION =====

The selection of cryptographic mechanisms is based on the need to protect the confidentiality of backup information. Hardware security module (HSM) devices safeguard and manage cryptographic keys and provide cryptographic processing. Cryptographic operations (e.g., encryption, decryption, and signature generation and verification) are typically hosted on the HSM device, and many implementations provide hardware-accelerated mechanisms for cryptographic operations. This requirement is related to [[#sec-sec_03.13.11|03.13.11]].

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-09 CP-09], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-09 CP-09(08)]

Supporting Publications: SP 800-34 [[#bibr-ref_52|52]], SP 800-130 [[#bibr-ref_53|53]], SP 800-152 [[#bibr-ref_54|54]]


=== 3.9 Personnel Security ===


==== 03.09.01 Personnel Screening ====

# Screen individuals prior to authorizing access to the system.
# Rescreen individuals in accordance with [''Assignment: organization-defined conditions requiring rescreening''].

===== DISCUSSION =====

Personnel security screening activities involve the assessment of the conduct, integrity, judgment, loyalty, reliability, and stability of an individual (i.e., the individual’s trustworthiness) prior to authorizing access to the system or when elevating system access. The screening and rescreening activities reflect applicable federal laws, Executive Orders, directives, policies, regulations, and criteria established for the level of access required for the assigned position.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PS-03 PS-03]

Supporting Publications: SP 800-181 [[#bibr-ref_34|34]]


==== 03.09.02 Personnel Termination and Transfer ====

# When individual employment is terminated:
## Disable system access within [''Assignment: organization-defined time period''],
## Terminate or revoke authenticators and credentials associated with the individual, and
## Retrieve security-related system property.
# When individuals are reassigned or transferred to other positions in the organization:
## Review and confirm the ongoing operational need for current logical and physical access authorizations to the system and facility, and
## Modify access authorization to correspond with any changes in operational need.

===== DISCUSSION =====

Security-related system property includes hardware authentication tokens, system administration technical manuals, keys, identification cards, and building passes. Exit interviews ensure that terminated individuals understand the security constraints imposed by being former employees and that accountability is achieved for the organizational property. Security topics at exit interviews include reminding individuals of potential limitations on future employment and non-disclosure agreements. Exit interviews may not always be possible for some individuals, including in cases related to the unavailability of supervisors, illnesses, or job abandonment.

The timely execution of termination actions is essential for individuals who have been terminated for cause. Organizations may consider disabling the accounts of individuals who are being terminated prior to the individuals being notified. This requirement applies to the reassignment or transfer of individuals when the personnel action is permanent or of such extended duration as to require protection. Protections that may be required for transfers or reassignments to other positions within organizations include returning old and issuing new identification cards, keys, and building passes; changing system access authorizations (i.e., privileges); closing system accounts and establishing new accounts; and providing access to official records to which individuals had access at previous work locations in previous system accounts.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PS-04 PS-04], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PS-05 PS-05]

Supporting Publications: None


=== 3.10 Physical Protection ===


==== 03.10.01 Physical Access Authorizations ====

# Develop, approve, and maintain a list of individuals with authorized access to the facility where the system resides.
# Issue authorization credentials for facility access.
# Review the facility access list [''Assignment: organization-defined frequency''].
# Remove individuals from the facility access list when access is no longer required.

===== DISCUSSION =====

A facility can include one or more physical locations containing systems or system components that process, store, or transmit CUI. Physical access authorizations apply to employees and visitors. Individuals with permanent physical access authorization credentials are not considered visitors. Authorization credentials include identification badges, identification cards, and smart cards. Organizations determine the strength of the authorization credentials consistent with applicable laws, Executive Orders, directives, regulations, policies, standards, and guidelines. Physical access authorizations may not be necessary to access certain areas within facilities that are designated as publicly accessible.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-02 PE-02]

Supporting Publications: None


==== 03.10.02 Monitoring Physical Access ====

# Monitor physical access to the facility where the system resides to detect and respond to physical security incidents.
# Review physical access logs [''Assignment: organization-defined frequency''] and upon occurrence of [''Assignment: organization-defined events or potential indications of events''].

===== DISCUSSION =====

A facility can include one or more physical locations containing systems or system components that process, store, or transmit CUI. Physical access monitoring includes publicly accessible areas within organizational facilities. Examples of physical access monitoring include guards, video surveillance equipment (i.e., cameras), and sensor devices. Reviewing physical access logs can help to identify suspicious activities, anomalous events, or potential threats. The reviews can be supported by audit logging controls if the access logs are part of an automated system. Incident response capabilities include investigations of physical security incidents and responses to those incidents. Incidents include security violations or suspicious physical access activities, such as access outside of normal work hours, repeated access to areas not normally accessed, access for unusual lengths of time, and out-of-sequence access.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-06 PE-06]

Supporting Publications: None


==== 03.10.03 Withdrawn ====

Incorporated into [[#sec-sec_03.10.07|03.10.07]].


==== 03.10.04 Withdrawn ====

Incorporated into [[#sec-sec_03.10.07|03.10.07]].


==== 03.10.05 Withdrawn ====

Incorporated into [[#sec-sec_03.10.07|03.10.07]].


==== 03.10.06 Alternate Work Site ====

# Determine alternate work sites allowed for use by employees.
# Employ the following security requirements at alternate work sites: [''Assignment: organization-defined security requirements''].

===== DISCUSSION =====

Alternate work sites include the private residences of employees or other facilities designated by the organization. Alternate work sites can provide readily available alternate locations during contingency operations. Organizations can define different security requirements for specific alternate work sites or types of sites, depending on the work-related activities conducted at the sites. Assessing the effectiveness of the requirements and providing a means to communicate incidents at alternate work sites supports the contingency planning activities of organizations.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-17 PE-17]

Supporting Publications: SP 800-46 [[#bibr-ref_14|14]], SP 800-114 [[#bibr-ref_20|20]]


==== 03.10.07 Physical Access Control ====

# Enforce physical access authorizations at entry and exit points to the facility where the system resides by:
## Verifying individual physical access authorizations before granting access to the facility and
## Controlling ingress and egress with physical access control systems, devices, or guards.
# Maintain physical access audit logs for entry or exit points.
# Escort visitors, and control visitor activity.
# Secure keys, combinations, and other physical access devices.
# Control physical access to output devices to prevent unauthorized individuals from obtaining access to CUI.

===== DISCUSSION =====

This requirement addresses physical locations containing systems or system components that process, store, or transmit CUI. Organizations determine the types of guards needed, including professional security staff or administrative staff. Physical access devices include keys, locks, combinations, biometric readers, and card readers. Physical access control systems comply with applicable laws, Executive Orders, directives, policies, regulations, standards, and guidelines. Organizations have flexibility in the types of audit logs employed. Audit logs can be procedural, automated, or some combination thereof. Physical access points can include exterior access points, interior access points to systems that require supplemental access controls, or both. Physical access control applies to employees and visitors. Individuals with permanent physical access authorizations are not considered visitors.

Controlling physical access to output devices includes placing output devices in locked rooms or other secured areas with keypad or card reader access controls and only allowing access to authorized individuals, placing output devices in locations that can be monitored by personnel, installing monitor or screen filters, and using headphones. Examples of output devices include monitors, printers, scanners, facsimile machines, audio devices, and copiers.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-03 PE-03], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-05 PE-05]

Supporting Publications: None


==== 03.10.08 Access Control for Transmission ====

Control physical access to system distribution and transmission lines within organizational facilities.

===== DISCUSSION =====

Safeguarding measures applied to system distribution and transmission lines prevent accidental damage, disruption, and physical tampering. Such measures may also be necessary to prevent eavesdropping or the modification of unencrypted transmissions. Safeguarding measures used to control physical access to system distribution and transmission lines include disconnected or locked spare jacks, locked wiring closets, cabling protection with conduit or cable trays, and wiretapping sensors.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-04 PE-04]

Supporting Publications: None


=== 3.11 Risk Assessment ===


==== 03.11.01 Risk Assessment ====

# Assess the risk (including supply chain risk) of unauthorized disclosure resulting from the processing, storage, or transmission of CUI.
# Update risk assessments [''Assignment: organization-defined frequency''].

===== DISCUSSION =====

Establishing the system boundary is a prerequisite to assessing the risk of the unauthorized disclosure of CUI. Risk assessments consider threats, vulnerabilities, likelihood, and adverse impacts to organizational operations and assets based on the operation and use of the system and the unauthorized disclosure of CUI. Risk assessments also consider risks from external parties (e.g., contractors operating systems on behalf of the organization, service providers, individuals accessing systems, and outsourcing entities). Risk assessments can be conducted at the organization level, the mission or business process level, or the system level and at any phase in the system development life cycle. Risk assessments include supply chain-related risks associated with suppliers or contractors and the system, system component, or system service that they provide.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=RA-03 RA-03], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=RA-03 RA-03(01)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SR-06 SR-06]

Supporting Publications: SP 800-30 [[#bibr-ref_55|55]], SP 800-161 [[#bibr-ref_33|33]]


==== 03.11.02 Vulnerability Monitoring and Scanning ====

# Monitor and scan the system for vulnerabilities [''Assignment: organization-defined frequency''] and when new vulnerabilities affecting the system are identified.
# Remediate system vulnerabilities within [''Assignment: organization-defined response times''].
# Update system vulnerabilities to be scanned [''Assignment: organization-defined frequency''] and when new vulnerabilities are identified and reported.

===== DISCUSSION =====

Organizations determine the required vulnerability scanning for system components and ensure that potential sources of vulnerabilities (e.g., networked printers, scanners, and copiers) are not overlooked. Vulnerability analyses for custom software may require additional approaches, such as static analysis, dynamic analysis, or binary analysis. Organizations can use these approaches in source code reviews and tools (e.g., static analysis tools, web-based application scanners, binary analyzers). Vulnerability scanning includes scanning for patch levels; scanning for functions, ports, protocols, and services that should not be accessible to users or devices; and scanning for improperly configured or incorrectly operating flow control mechanisms.

To facilitate interoperability, organizations consider using scanning tools that express vulnerabilities in the Common Vulnerabilities and Exposures (CVE) naming convention. Sources for vulnerability information also include the Common Weakness Enumeration (CWE) listing, the National Vulnerability Database (NVD), and the Common Vulnerability Scoring System (CVSS).

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=RA-05 RA-05], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=RA-05 RA-05(02)]

Supporting Publications: SP 800-40 [[#bibr-ref_56|56]], SP 800-53A [[#bibr-ref_57|57]], SP 800-70 [[#bibr-ref_44|44]], SP 800-115 [[#bibr-ref_58|58]], SP 800-126 [[#bibr-ref_45|45]]


==== 03.11.03 Withdrawn ====

Incorporated into [[#sec-sec_03.11.02|03.11.02]].


==== 03.11.04 Risk Response ====

Respond to findings from security assessments, monitoring, and audits.

===== DISCUSSION =====

This requirement addresses the need to determine an appropriate response to risk before generating a plan of action and milestones (POAM) entry. It may be possible to mitigate the risk immediately so that a POAM entry is not needed. However, a POAM entry is generated if the risk response is to mitigate the identified risk and the mitigation cannot be completed immediately.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=RA-07 RA-07]

Supporting Publications: SP 800-30 [[#bibr-ref_55|55]], SP 800-37 [[#bibr-ref_59|59]], SP 800-39 [[#bibr-ref_60|60]], SP 800-160-1 [[#bibr-ref_11|11]]


=== 3.12 Security Assessment and Monitoring ===


==== 03.12.01 Security Assessment ====

Assess the security requirements for the system and its environment of operation [''Assignment: organization-defined frequency''] to determine if the requirements have been satisfied.

===== DISCUSSION =====

By assessing the security requirements, organizations determine whether the necessary safeguards and countermeasures are implemented correctly, operating as intended, and producing the desired outcome. Security assessments identify weaknesses in the system and provide the essential information needed to make risk-based decisions. Security assessment reports document assessment results in sufficient detail as deemed necessary by the organization to determine the accuracy and completeness of the reports. Security assessment results are provided to the individuals or roles appropriate for the types of assessments being conducted.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CA-02 CA-02]

Supporting Publications: SP 800-53 [[#bibr-ref_8|8]], SP 800-53A [[#bibr-ref_57|57]], SP 800-37 [[#bibr-ref_59|59]], SP 800-115 [[#bibr-ref_58|58]]


==== 03.12.02 Plan of Action and Milestones ====

# Develop a plan of action and milestones for the system:
## To document the planned remediation actions to correct weaknesses or deficiencies noted during security assessments and
## To reduce or eliminate known system vulnerabilities.
# Update the existing plan of action and milestones based on the findings from:
## Security assessments,
## Audits or reviews, and
## Continuous monitoring activities.

===== DISCUSSION =====

Plans of action and milestones (POAMs) are important documents in organizational security programs. Organizations use POAMs to describe how unsatisfied security requirements will be met and how planned mitigations will be implemented. Organizations can document system security plans and POAMs as separate or combined documents in any format. Federal agencies may consider system security plans and POAMs as inputs to risk-based decisions on whether to process, store, or transmit CUI on a system hosted by a nonfederal organization.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CA-05 CA-05]

Supporting Publications: SP 800-37 [[#bibr-ref_59|59]]


==== 03.12.03 Continuous Monitoring ====

Develop and implement a system-level continuous monitoring strategy that includes ongoing monitoring and security assessments.

===== DISCUSSION =====

Continuous monitoring at the system level facilitates ongoing awareness of the system security posture to support risk management decisions. The terms ''continuous'' and ''ongoing'' imply that organizations assess and monitor their systems at a frequency that is sufficient to support risk-based decisions. Different types of security requirements may require different monitoring frequencies.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CA-07 CA-07]

Supporting Publications: SP 800-37 [[#bibr-ref_59|59]], SP 800-39 [[#bibr-ref_60|60]], SP 800-53A [[#bibr-ref_57|57]], SP 800-115 [[#bibr-ref_58|58]], SP 800-137 [[#bibr-ref_49|49]]


==== 03.12.04 Withdrawn ====

Incorporated into [[#sec-sec_03.15.02|03.15.02]].


==== 03.12.05 Information Exchange ====

# Approve and manage the exchange of CUI between the system and other systems using [''Selection (one or more): interconnection security agreements; information exchange security agreements; memoranda of understanding or agreement; service-level agreements; user agreements; non-disclosure agreements; other types of agreements''].
# Document interface characteristics, security requirements, and responsibilities for each system as part of the exchange agreements.
# Review and update the exchange agreements [''Assignment: organization-defined frequency''].

===== DISCUSSION =====

Information exchange applies to information exchanges between two or more systems, both internal and external to the organization. Organizations consider the risks related to new or increased threats that may be introduced when systems exchange information with other systems that may have different security requirements or policies. The types of agreements selected are based on factors such as the relationship between the organizations exchanging information (e.g., government to government, business to business, government to business, government or business, or government or business to individual) and the level of access to the organizational system by users of the other system. The types of agreements can include information exchange security agreements, interconnection security agreements, memoranda of understanding or agreement, service-level agreements, or other types of agreements.

Organizations may incorporate agreement information into formal contracts, especially for information exchanges established between federal agencies and nonfederal organizations (e.g., service providers, contractors, system developers, and system integrators). The types of information contained in exchange agreements include the interface characteristics, security requirements, controls, and responsibilities for each system.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CA-03 CA-03]

Supporting Publications: SP 800-47 [[#bibr-ref_83|83]]


=== 3.13 System and Communications Protection ===


==== 03.13.01 Boundary Protection ====

# Monitor and control communications at external managed interfaces to the system and key internal managed interfaces within the system.
# Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
# Connect to external systems only through managed interfaces that consist of boundary protection devices arranged in accordance with an organizational security architecture.

===== DISCUSSION =====

Managed interfaces include gateways, routers, firewalls, network-based malicious code analysis, virtualization systems, and encrypted tunnels implemented within a security architecture. Subnetworks that are either physically or logically separated from internal networks are referred to as demilitarized zones or DMZs. Restricting or prohibiting interfaces within organizational systems includes restricting external web traffic to designated web servers within managed interfaces, prohibiting external traffic that appears to be spoofing internal addresses, and prohibiting internal traffic that appears to be spoofing external addresses.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-07 SC-07]

Supporting Publications: SP 800-41 [[#bibr-ref_64|64]], SP 800-125B [[#bibr-ref_65|65]], SP 800-160-1 [[#bibr-ref_11|11]], SP 800-189 [[#bibr-ref_67|67]], SP 800-207 [[#bibr-ref_66|66]]


==== 03.13.02 Withdrawn ====

Recategorized as NCO.


==== 03.13.03 Withdrawn ====

Addressed by [[#sec-sec_03.01.01|03.01.01]], [[#sec-sec_03.01.02|03.01.02]], [[#sec-sec_03.01.03|03.01.03]], [[#sec-sec_03.01.04|03.01.04]], [[#sec-sec_03.01.05|03.01.05]], [[#sec-sec_03.01.06|03.01.06]], and [[#sec-sec_03.01.07|03.01.07]].


==== 03.13.04 Information in Shared System Resources ====

Prevent unauthorized and unintended information transfer via shared system resources.

===== DISCUSSION =====

Preventing unauthorized and unintended information transfer via shared system resources stops information produced by the actions of prior users or roles (or actions of processes acting on behalf of prior users or roles) from being available to current users or roles (or current processes acting on behalf of current users or roles) that obtain access to shared system resources after those resources have been released back to the system. Information in shared system resources also applies to encrypted representations of information. In other contexts, the control of information in shared system resources is referred to as object reuse and residual information protection. Information in shared system resources does not address information remanence, which refers to the residual representation of data that has been nominally deleted, covert channels (including storage and timing channels) in which shared system resources are manipulated to violate information flow restrictions, or components within systems for which there are only single users or roles.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-04 SC-04]

Supporting Publications: None


==== 03.13.05 Withdrawn ====

Incorporated into [[#sec-sec_03.13.01|03.13.01]].


==== 03.13.06 Network Communications – Deny by Default – Allow by Exception ====

Deny network communications traffic by default, and allow network communications traffic by exception.

===== DISCUSSION =====

This requirement applies to inbound and outbound network communications traffic at the system boundary and at identified points within the system. A deny-all, allow-by-exception network communications traffic policy ensures that only essential and approved connections are allowed.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-07 SC-07(05)]

Supporting Publications: SP 800-41 [[#bibr-ref_64|64]], SP 800-77 [[#bibr-ref_18|18]], SP 800-189 [[#bibr-ref_67|67]]


==== 03.13.07 Withdrawn ====

Addressed by [[#sec-sec_03.01.12|03.01.12]], [[#sec-sec_03.04.02|03.04.02]] and [[#sec-sec_03.04.06|03.04.06]].


==== 03.13.08 Transmission and Storage Confidentiality ====

Implement cryptographic mechanisms to prevent the unauthorized disclosure of CUI during transmission and while in storage.

===== DISCUSSION =====

This requirement applies to internal and external networks and any system components that can transmit CUI, including servers, notebook computers, desktop computers, mobile devices, printers, copiers, scanners, facsimile machines, and radios. Unprotected communication paths are susceptible to interception and modification. Encryption protects CUI from unauthorized disclosure during transmission and while in storage. Cryptographic mechanisms that protect the confidentiality of CUI during transmission include TLS and IPsec. Information in storage (i.e., information at rest) refers to the state of CUI when it is not in process or in transit and resides on internal or external storage devices, storage area network devices, and databases. Protecting CUI in storage does not focus on the type of storage device or the frequency of access to that device but rather on the state of the information. This requirement relates to [[#sec-sec_03.13.11|03.13.11]].

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-08 SC-08], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-08 SC-08(01)], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-28 SC-28], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-28 SC-28(01)]

Supporting Publications: FIPS 140-3 [[#bibr-ref_38|38]], FIPS 197 [[#bibr-ref_68|68]], SP 800-46 [[#bibr-ref_14|14]], SP 800-52 [[#bibr-ref_69|69]], SP 800-56A [[#bibr-ref_73|73]], SP 800-56B [[#bibr-ref_74|74]], SP 800-56C [[#bibr-ref_75|75]], SP 800-57-1 [[#bibr-ref_15|15]], SP 800-57-2 [[#bibr-ref_16|16]], SP 800-57-3 [[#bibr-ref_17|17]], SP 800-77 [[#bibr-ref_18|18]], SP 800-111 [[#bibr-ref_51|51]], SP 800-113 [[#bibr-ref_19|19]], SP 800-114 [[#bibr-ref_20|20]], SP 800-121 [[#bibr-ref_21|21]], SP 800-124 [[#bibr-ref_28|28]], SP 800-177 [[#bibr-ref_70|70]]


==== 03.13.09 Network Disconnect ====

Terminate the network connection associated with a communications session at the end of the session or after [''Assignment: organization-defined time period''] of inactivity.

===== DISCUSSION =====

This requirement applies to internal and external networks. Terminating network connections associated with communications sessions includes deallocating TCP/IP addresses or port pairs at the operating system level or deallocating networking assignments at the application level if multiple application sessions are using a single network connection. Time periods of inactivity may be established by organizations and include time periods by type of network access or for specific network accesses.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-10 SC-10]

Supporting Publications: None


==== 03.13.10 Cryptographic Key Establishment and Management ====

Establish and manage cryptographic keys in the system in accordance with the following key management requirements: [''Assignment: organization-defined requirements for key generation, distribution, storage, access, and destruction''].

===== DISCUSSION =====

Cryptographic keys can be established and managed using either manual procedures or automated mechanisms supported by manual procedures. Organizations satisfy key establishment and management requirements in accordance with applicable federal laws, Executive Orders, policies, directives, regulations, and standards that specify appropriate options, levels, and parameters. This requirement is related to [[#sec-sec_03.13.11|03.13.11]].

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-12 SC-12]

Supporting Publications: FIPS 140-3 [[#bibr-ref_38|38]], SP 800-56A [[#bibr-ref_73|73]], SP 800-56B [[#bibr-ref_74|74]], SP 800-56C [[#bibr-ref_75|75]], SP 800-57-1 [[#bibr-ref_15|15]], SP 800-57-2 [[#bibr-ref_16|16]], SP 800-57-3 [[#bibr-ref_17|17]], SP 800-63-3 [[#bibr-ref_27|27]]


==== 03.13.11 Cryptographic Protection ====

Implement the following types of cryptography to protect the confidentiality of CUI: [''Assignment: organization-defined types of cryptography''].

===== DISCUSSION =====

Cryptography is implemented in accordance with applicable laws, Executive Orders, directives, regulations, policies, standards, and guidelines. FIPS-validated cryptography is recommended for the protection of CUI.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-13 SC-13]

Supporting Publications: FIPS 140-3 [[#bibr-ref_38|38]]


==== 03.13.12 Collaborative Computing Devices and Applications ====

# Prohibit the remote activation of collaborative computing devices and applications with the following exceptions: [''Assignment: organization-defined exceptions where remote activation is to be allowed''].
# Provide an explicit indication of use to users physically present at the devices.

===== DISCUSSION =====

Collaborative computing devices include white boards, microphones, and cameras. Notebook computers, smartphones, display monitors, and tablets containing cameras and microphones are considered part of collaborative computing devices when conferencing software is in use. Indication of use includes notifying users (e.g., a pop-up menu stating that recording is in progress or that the microphone has been turned on) when collaborative computing devices are activated. Dedicated video conferencing systems, which typically rely on one of the participants calling or connecting to the other party to activate the video conference, are excluded. Solutions to prevent device usage include webcam covers and buttons to disable microphones.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-15 SC-15]

Supporting Publications: None


==== 03.13.13 Mobile Code ====

# Define acceptable mobile code and mobile code technologies.
# Authorize, monitor, and control the use of mobile code.

===== DISCUSSION =====

Mobile code includes software programs or parts of programs that are obtained from remote systems, transmitted across a network, and executed on a local system without explicit installation or execution by the recipient. Decisions regarding the use of mobile code are based on the potential for the code to cause damage to the system if used maliciously. Mobile code technologies include Java applets, JavaScript, HTML5, VBScript, and WebGL. Usage restrictions and implementation guidelines apply to the selection and use of mobile code installed on servers and downloaded and executed on individual workstations and devices, including notebook computers, smart phones, and smart devices. Mobile code policies and procedures address the actions taken to prevent the development, acquisition, and use of unacceptable mobile code within the system, including requiring mobile code to be digitally signed by a trusted source.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-18 SC-18]

Supporting Publications: SP 800-28 [[#bibr-ref_71|71]]


==== 03.13.14 Withdrawn ====

Technology-specific.


==== 03.13.15 Session Authenticity ====

Protect the authenticity of communications sessions.

===== DISCUSSION =====

Protecting session authenticity addresses communications protection at the session level, not at the packet level. Such protection establishes grounds for confidence at both ends of the communications sessions in the ongoing identities of other parties and the validity of the transmitted information. Authenticity protection includes protecting against adversary-in-the-middle attacks, session hijacking, and the insertion of false information into sessions.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-23 SC-23]

Supporting Publications: SP 800-52 [[#bibr-ref_69|69]], SP 800-77 [[#bibr-ref_18|18]], SP 800-95 [[#bibr-ref_72|72]], SP 800-113 [[#bibr-ref_19|19]]


==== 03.13.16 Withdrawn ====

Incorporated into [[#sec-sec_03.13.08|03.13.08]].


=== 3.14 System and Information Integrity ===


==== 03.14.01 Flaw Remediation ====

# Identify, report, and correct system flaws.
# Install security-relevant software and firmware updates within [''Assignment: organization-defined time period''] of the release of the updates.

===== DISCUSSION =====

Organizations identify systems that are affected by announced software and firmware flaws, including potential vulnerabilities that result from those flaws, and report this information to designated personnel with information security responsibilities. Security-relevant updates include patches, service packs, hot fixes, and anti-virus signatures. Organizations address the flaws discovered during security assessments, continuous monitoring, incident response activities, and system error handling. Organizations can take advantage of available resources (e.g., CWE or CVE databases) when remediating system flaws. Organization-defined time periods for updating security-relevant software and firmware may vary based on a variety of factors, including the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw). Some types of flaw remediation may require more testing than other types.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-02 SI-02]

Supporting Publications: SP 800-39 [[#bibr-ref_60|60]], SP 800-40 [[#bibr-ref_56|56]], SP 800-128 [[#bibr-ref_41|41]]


==== 03.14.02 Malicious Code Protection ====

# Implement malicious code protection mechanisms at system entry and exit points to detect and eradicate malicious code.
# Update malicious code protection mechanisms as new releases are available in accordance with configuration management policies and procedures.
# Configure malicious code protection mechanisms to:
## Perform scans of the system [''Assignment: organization-defined frequency''] and real-time scans of files from external sources at endpoints or system entry and exit points as the files are downloaded, opened, or executed; and
## Block malicious code, quarantine malicious code, or take other mitigation actions in response to malicious code detection.

===== DISCUSSION =====

Malicious code insertions occur through the exploitation of system vulnerabilities. Malicious code can be inserted into the system in a variety of ways, including email, the internet, and portable storage devices. Malicious code includes viruses, worms, Trojan horses, and spyware. Malicious code can be encoded in various formats, contained in compressed or hidden files, or hidden in files using techniques such as steganography. Malicious code may be present in commercial off-the-shelf software and custom-built software and could include logic bombs, backdoors, and other types of attacks that could affect organizational mission and business functions. Periodic scans of the system and real-time scans of files from external sources as files are downloaded, opened, or executed can detect malicious code. Malicious code protection mechanisms can also monitor systems for anomalous or unexpected behaviors and take appropriate actions.

Malicious code protection mechanisms include signature- and non-signature-based technologies. Non-signature-based detection mechanisms include artificial intelligence techniques that use heuristics to detect, analyze, and describe the characteristics or behavior of malicious code and to provide controls against such code for which signatures do not yet exist or for which existing signatures may not be effective. Malicious code for which active signatures do not yet exist or may be ineffective includes polymorphic malicious code (i.e., code that changes signatures when it replicates). Non-signature-based mechanisms include reputation-based technologies. Pervasive configuration management, anti-exploitation software, and software integrity controls may also be effective in preventing unauthorized code execution.

If malicious code cannot be detected by detection methods or technologies, organizations can rely on secure coding practices, configuration management and control, trusted procurement processes, and monitoring practices to help ensure that the software only performs intended functions. Organizations may determine that different actions are warranted in response to the detection of malicious code. For example, organizations can define actions to be taken in response to the detection of malicious code during scans, malicious downloads, or malicious activity when attempting to open or execute files.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-03 SI-03]

Supporting Publications: SP 800-83 [[#bibr-ref_76|76]], SP 800-125B [[#bibr-ref_65|65]], SP 800-177 [[#bibr-ref_70|70]]


==== 03.14.03 Security Alerts, Advisories, and Directives ====

# Receive system security alerts, advisories, and directives from external organizations on an ongoing basis.
# Generate and disseminate internal system security alerts, advisories, and directives, as necessary.

===== DISCUSSION =====

There are many publicly available sources of system security alerts and advisories. The Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA), the National Security Agency (NSA), and the Federal Bureau of Investigation (FBI) generate security alerts and advisories to maintain situational awareness across the Federal Government and in nonfederal organizations. Software vendors, subscription services, and industry Information Sharing and Analysis Centers (ISACs) may also provide security alerts and advisories. Compliance with security directives is essential due to the critical nature of many of these directives and the potential immediate adverse effects on organizational operations and assets, individuals, other organizations, and the Nation should the directives not be implemented in a timely manner.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-05 SI-05]

Supporting Publications: SP 800-161 [[#bibr-ref_33|33]]


==== 03.14.04 Withdrawn ====

Incorporated into [[#sec-sec_03.14.02|03.14.02]].


==== 03.14.05 Withdrawn ====

Addressed by [[#sec-sec_03.14.02|03.14.02]].


==== 03.14.06 System Monitoring ====

# Monitor the system to detect:
# Attacks and indicators of potential attacks and
# Unauthorized connections.
# Identify unauthorized use of the system.
# Monitor inbound and outbound communications traffic to detect unusual or unauthorized activities or conditions.

===== DISCUSSION =====

System monitoring involves external and internal monitoring. Internal monitoring includes the observation of events that occur within the system. External monitoring includes the observation of events that occur at the system boundary. Organizations can monitor the system by observing audit record activities in real time or by observing other system aspects, such as access patterns, characteristics of access, and other actions. The monitoring objectives may guide determination of the events.

A system monitoring capability is achieved through a variety of tools and techniques (e.g., audit record monitoring software, intrusion detection systems, intrusion prevention systems, malicious code protection software, scanning tools, network monitoring software). Strategic locations for monitoring devices include selected perimeter locations and near server farms that support critical applications with such devices being employed at managed system interfaces. The granularity of monitoring the information collected is based on organizational monitoring objectives and the capability of the system to support such objectives.

Systems connections can be network, remote, or local. A network connection is any connection with a device that communicates through a network (e.g., local area network, the internet). A remote connection is any connection with a device that communicates through an external network (e.g., the internet). Network, remote, and local connections can be either wired or wireless.

Unusual or unauthorized activities or conditions related to inbound and outbound communications traffic include internal traffic that indicates the presence of malicious code in the system or propagating among system components, the unauthorized export of information, or signaling to external systems. Evidence of malicious code is used to identify a potentially compromised system. System monitoring requirements, including the need for types of system monitoring, may be referenced in other requirements.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-04 SI-04], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-04 SI-04(04)]

Supporting Publications: SP 800-61 [[#bibr-ref_47|47]], SP 800-83 [[#bibr-ref_76|76]], SP 800-92 [[#bibr-ref_35|35]], SP 800-94 [[#bibr-ref_29|29]], SP 800-137 [[#bibr-ref_49|49]], SP 800-177 [[#bibr-ref_70|70]]


==== 03.14.07 Withdrawn ====

Incorporated into [[#sec-sec_03.14.06|03.14.06]].


==== 03.14.08 Information Management and Retention ====

Manage and retain CUI within the system and CUI output from the system in accordance with applicable laws, Executive Orders, directives, regulations, policies, standards, guidelines, and operational requirements.

===== DISCUSSION =====

Federal agencies consider data retention requirements for nonfederal organizations. Retaining CUI on nonfederal systems after contracts or agreements have concluded increases the attack surface for those systems and the risk of the information being compromised. NARA provides federal policy and guidance on records retention and schedules.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-12 SI-12]

Supporting Publications: None


=== 3.15 Planning ===


==== 03.15.01 Policy and Procedures ====

# Develop, document, and disseminate to organizational personnel or roles the policies and procedures needed to satisfy the security requirements for the protection of CUI.
# Review and update policies and procedures [''Assignment: organization-defined frequency''].

===== DISCUSSION =====

This requirement addresses policies and procedures for the protection of CUI. Policies and procedures contribute to security assurance and should address each family of the CUI security requirements. Policies can be included as part of the organizational security policy or be represented by separate policies that address each family of security requirements. Procedures describe how policies are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security plans or in one or more separate documents.

===== REFERENCES =====

Source Controls: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-01 AC-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AT-01 AT-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-01 AU-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CA-01 CA-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-01 CM-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-01 IA-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IR-01 IR-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MA-01 MA-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MP-01 MP-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-01 PE-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PL-01 PL-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PS-01 PS-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=RA-01 RA-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SA-01 SA-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-01 SC-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-01 SI-01], [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SR-01 SR-01]

Supporting Publications: SP 800-12 [[#bibr-ref_61|61]], SP 800-100 [[#bibr-ref_62|62]]


==== 03.15.02 System Security Plan ====

# Develop a system security plan that:
## Defines the constituent system components;
## Identifies the information types processed, stored, and transmitted by the system;
## Describes specific threats to the system that are of concern to the organization;
## Describes the operational environment for the system and any dependencies on or connections to other systems or system components;
## Provides an overview of the security requirements for the system;
## Describes the safeguards in place or planned for meeting the security requirements;
## Identifies individuals that fulfill system roles and responsibilities; and
## Includes other relevant information necessary for the protection of CUI.
# Review and update the system security plan [''Assignment: organization-defined frequency''].
# Protect the system security plan from unauthorized disclosure.

===== DISCUSSION =====

System security plans provide key characteristics of the system that is processing, storing, and transmitting CUI and how the system and information are protected. System security plans contain sufficient information to enable a design and implementation that are unambiguously compliant with the intent of the plans and the subsequent determinations of risk if the plan is implemented as intended. System security plans can be a collection of documents, including documents that already exist. Effective system security plans reference policies, procedures, and documents (e.g., design specifications) that provide additional detailed information. This reduces the documentation requirements associated with security programs and maintains security information in other established management or operational areas related to enterprise architecture, the system development life cycle, systems engineering, and acquisition.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PL-02 PL-02]

Supporting Publications: SP 800-18 [[#bibr-ref_63|63]]


==== 03.15.03 Rules of Behavior ====

# Establish rules that describe the responsibilities and expected behavior for system usage and protecting CUI.
# Provide rules to individuals who require access to the system.
# Receive a documented acknowledgement from individuals indicating that they have read, understand, and agree to abide by the rules of behavior before authorizing access to CUI and the system.
# Review and update the rules of behavior [''Assignment: organization-defined frequency''].

===== DISCUSSION =====

Rules of behavior represent a type of access agreement for system users. Organizations consider rules of behavior for the handling of CUI based on individual user roles and responsibilities and differentiate between rules that apply to privileged users and rules that apply to general users.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PL-04 PL-04]

Supporting Publications: SP 800-18 [[#bibr-ref_63|63]]


=== 3.16 System and Services Acquisition ===


==== 03.16.01 Security Engineering Principles ====

Apply the following systems security engineering principles to the development or modification of the system and system components: [''Assignment: organization-defined systems security engineering principles''].

===== DISCUSSION =====

Organizations apply systems security engineering principles to new development systems. For legacy systems, organizations apply systems security engineering principles to system modifications to the extent feasible, given the current state of hardware, software, and firmware components. The application of systems security engineering principles helps to develop trustworthy, secure, and resilient systems and reduce the susceptibility of organizations to disruptions, hazards, and threats. Examples include developing layered protections; establishing security policies, architectures, and controls as the foundation for system design; incorporating security requirements into the system development life cycle; delineating physical and logical security boundaries; ensuring that developers are trained on how to build trustworthy secure software; and performing threat modeling to identify use cases, threat agents, attack vectors and patterns, design patterns, and compensating controls needed to mitigate risk. Organizations that apply security engineering principles can facilitate the development of trustworthy, secure systems, system components, and system services; reduce risks to acceptable levels; and make informed risk-management decisions.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SA-08 SA-08]

Supporting Publications: SP 800-160-1 [[#bibr-ref_11|11]], SP 800-160-2 [[#bibr-ref_10|10]], SP 800-207 [[#bibr-ref_66|66]]


==== 03.16.02 Unsupported System Components ====

# Replace system components when support for the components is no longer available from the developer, vendor, or manufacturer.
# Provide options for risk mitigation or alternative sources for continued support for unsupported components that cannot be replaced.

===== DISCUSSION =====

Support for system components includes software patches, firmware updates, replacement parts, and maintenance contracts. An example of unsupported components includes when vendors no longer provide critical software patches or product updates, which can result in opportunities for adversaries to exploit weaknesses or deficiencies in the installed components. Exceptions to replacing unsupported system components include systems that provide critical mission or business capabilities when newer technologies are unavailable or when the systems are so isolated that installing replacement components is not an option.

Alternative sources of support address the need to provide continued support for system components that are no longer supported by the original manufacturers, developers, or vendors when such components remain essential to organizational missions and business functions. If necessary, organizations can establish in-house support by developing customized patches for critical software components or obtain the services of external service providers who provide ongoing support for unsupported components through contractual relationships. Such contractual relationships can include open-source software value-added vendors. The increased risk of using unsupported system components can be mitigated by prohibiting the connection of such components to public or uncontrolled networks or implementing other forms of isolation.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SA-22 SA-22]

Supporting Publications: None


==== 03.16.03 External System Services ====

# Require the providers of external system services used for the processing, storage, or transmission of CUI to comply with the following security requirements: [''Assignment: organization-defined security requirements''].
# Define and document user roles and responsibilities with regard to external system services, including shared responsibilities with external service providers.
# Implement processes, methods, and techniques to monitor security requirement compliance by external service providers on an ongoing basis.

===== DISCUSSION =====

External system services are provided by external service providers. Organizations establish relationships with external service providers in a variety of ways, including through business partnerships, contracts, interagency agreements, lines of business arrangements, licensing agreements, joint ventures, and supply chain exchanges. The responsibility for managing risks from the use of external system services remains with the organization charged with protecting CUI. Service-level agreements define expectations of performance, describe measurable outcomes, and identify remedies, mitigations, and response requirements for instances of noncompliance. Information from external service providers regarding the specific functions, ports, protocols, and services used in the provision of such services can be useful when there is a need to understand the trade-offs involved in restricting certain functions and services or blocking certain ports and protocols. This requirement is related to [[#sec-sec_03.01.20|03.01.20]].

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SA-09 SA-09]

Supporting Publications: SP 800-160-1 [[#bibr-ref_11|11]], SP 800-161 [[#bibr-ref_33|33]]


=== 3.17 Supply Chain Risk Management ===


==== 03.17.01 Supply Chain Risk Management Plan ====

# Develop a plan for managing supply chain risks associated with the research and development, design, manufacturing, acquisition, delivery, integration, operations, maintenance, and disposal of the system, system components, or system services.
# Review and update the supply chain risk management plan [''Assignment: organization-defined frequency''].
# Protect the supply chain risk management plan from unauthorized disclosure.

===== DISCUSSION =====

Dependence on the products, systems, and services of external providers and the nature of the relationships with those providers present an increasing level of risk to an organization. Threat actions that may increase security risks include unauthorized production, the insertion or use of counterfeits, tampering, poor manufacturing and development practices in the supply chain, theft, and the insertion of malicious software, firmware, and hardware. Supply chain risks can be endemic or systemic within a system, component, or service. Managing supply chain risks is a complex, multifaceted undertaking that requires a coordinated effort across an organization to build trust relationships and communicate with internal and external stakeholders.

Supply chain risk management (SCRM) activities include identifying and assessing risks, determining appropriate risk response actions, developing SCRM plans to document response actions, and monitoring performance against the plans. The system-level SCRM plan is implementation-specific and provides constraints, policy implementation, requirements, and implications. It can either be stand-alone or incorporated into system security plans. The SCRM plan addresses the management, implementation, and monitoring of SCRM requirements and the development or sustainment of systems across the system development life cycle to support mission and business functions. Because supply chains can differ significantly across and within organizations, SCRM plans are tailored to individual program, organizational, and operational contexts.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SR-02 SR-02]

Supporting Publications: SP 800-30 [[#bibr-ref_55|55]], SP 800-39 [[#bibr-ref_60|60]], SP 800-161 [[#bibr-ref_33|33]], SP 800-181 [[#bibr-ref_34|34]]


==== 03.17.02 Acquisition Strategies, Tools, and Methods ====

Develop and implement acquisition strategies, contract tools, and procurement methods to identify, protect against, and mitigate supply chain risks.

===== DISCUSSION =====

The acquisition process provides an important vehicle for protecting the supply chain. There are many useful tools and techniques available, including obscuring the end use of a system or system component, using blind purchases, requiring tamper-evident packaging, or using trusted or controlled distribution. The results from a supply chain risk assessment can inform the strategies, tools, and methods that are most applicable to the situation. Tools and techniques may provide protections against unauthorized production, theft, tampering, the insertion of counterfeits, the insertion of malicious software or backdoors, and poor development practices throughout the system life cycle.

Organizations also consider providing incentives for suppliers to implement safeguards, promote transparency in their processes and security practices, provide contract language that addresses the prohibition of tainted or counterfeit components, and restrict purchases from untrustworthy suppliers. Organizations consider providing training, education, and awareness programs for personnel regarding supply chain risks, available mitigation strategies, and when the programs should be employed. Methods for reviewing and protecting development plans, documentation, and evidence are commensurate with the security requirements of the organization. Contracts may specify documentation protection requirements.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SR-05 SR-05]

Supporting Publications: SP 800-30 [[#bibr-ref_55|55]], SP 800-161 [[#bibr-ref_33|33]]


==== 03.17.03 Supply Chain Requirements and Processes ====

# Establish a process for identifying and addressing weaknesses or deficiencies in the supply chain elements and processes.
# Enforce the following security requirements to protect against supply chain risks to the system, system components, or system services and to limit the harm or consequences from supply chain-related events: [''Assignment: organization-defined security requirements''].

===== DISCUSSION =====

Supply chain elements include organizations, entities, or tools that are employed for the research, development, design, manufacturing, acquisition, delivery, integration, operations, maintenance, and disposal of systems and system components. Supply chain processes include hardware, software, firmware, and systems development processes; shipping and handling procedures; physical security programs; personnel security programs; configuration management tools, techniques, and measures to maintain provenance; or other programs, processes, or procedures associated with the development, acquisition, maintenance, and disposal of systems and system components. Supply chain elements and processes are provided by organizations, system integrators, or external service providers. Weaknesses or deficiencies in supply chain elements or processes represent potential vulnerabilities that can be exploited by adversaries to harm the organization and affect its ability to carry out its core missions or business functions.

===== REFERENCES =====

Source Control: [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SR-03 SR-03]

Supporting Publications: SP 800-30 [[#bibr-ref_55|55]], SP 800-161 [[#bibr-ref_33|33]]

References

[1] Executive Order 13556 (2010) Controlled Unclassified Information. (The White House, Washington, DC), DCPD-201000942, November 4, 2010. Available at [https://www.govinfo.gov/app/details/DCPD-201000942]

[2] Executive Order 13526 (2009) Classified National Security Information. (The White House, Washington, DC), DCPD-200901022, December 29, 2009. Available at [https://www.govinfo.gov/app/details/DCPD-200901022]

[3] Atomic Energy Act (P.L. 83-703), August 1954. Available at [https://www.govinfo.gov/app/details/STATUTE-68/STATUTE-68-Pg919]

[4] National Archives and Records Administration (2019) Controlled Unclassified Information (CUI) Registry. Available at [https://www.archives.gov/cui]

[5] 32 CFR Part 2002 (2016), Controlled Unclassified Information (CUI), September 2016. Available at [https://www.govinfo.gov/content/pkg/CFR-2018-title32-vol6/pdf/CFR-2018-title32-vol6-part2002.pdf]

[6] National Institute of Standards and Technology (2004) Standards for Security Categorization of Federal Information and Information Systems. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 199. [https://doi.org/10.6028/NIST.FIPS.199]

[7] National Institute of Standards and Technology (2006) Minimum Security Requirements for Federal Information and Information Systems. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 200. [https://doi.org/10.6028/NIST.FIPS.200]

[8] Joint Task Force (2020) Security and Privacy Controls for Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53, Rev. 5, Includes updates as of December 10, 2020. [https://doi.org/10.6028/NIST.SP.800-53r5]

[9] Federal Information Security Modernization Act (P.L. 113-283), December 2014. Available at [https://www.govinfo.gov/app/details/PLAW-113publ283]

[10] Ross RS, Pillitteri VY, Graubart R, Bodeau D, McQuaid R, (2021) Developing Cyber-Resilient Systems: A Systems Security Engineering Approach. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-160, Vol. 2, Rev. 1. [https://doi.org/10.6028/NIST.SP.800-160v2r1]

[11] Ross R, Winstead M, McEvilley M, (2022) Engineering Trustworthy Secure Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-160, Vol. 1, Rev. 1. [https://doi.org/10.6028/NIST.SP.800-160v1r1]

[12] Joint Task Force (2020) Control Baselines for Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53B, Includes updates as of December 10, 2020. [https://doi.org/10.6028/NIST.SP.800-53B]

[13] Office of Management and Budget Circular A-130, Managing Information as a Strategic Resource, July 2016. Available at [https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf]

[14] Souppaya MP, Scarfone KA, (2016) Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-46, Rev. 2. [https://doi.org/10.6028/NIST.SP.800-46r2]

[15] Barker EB, (2020) Recommendation for Key Management: Part 1 – General. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-57 Part 1, Rev. 5. [https://doi.org/10.6028/NIST.SP.800-57pt1r5]

[16] Barker EB, Barker WC, (2019) Recommendation for Key Management: Part 2 – Best Practices for Key Management Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-57 Part 2, Rev. 1. [https://doi.org/10.6028/NIST.SP.800-57pt2r1]

[17] Barker EB, Dang QH, (2015) Recommendation for Key Management, Part 3: Application-Specific Key Management Guidance. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-57 Part 3, Rev. 1. [https://doi.org/10.6028/NIST.SP.800-57pt3r1]

[18] Barker EB, Dang QH, Frankel SE, Scarfone KA, Wouters P, (2020) Guide to IPsec VPNs. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-77, Rev. 1. [https://doi.org/10.6028/NIST.SP.800-77r1]

[19] Frankel SE, Hoffman P, Orebaugh AD, Park R, (2008) Guide to SSL VPNs. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication ( SP) 800-113. [https://doi.org/10.6028/NIST.SP.800-113]

[20] Souppaya MP, Scarfone KA, (2016) User’s Guide to Telework and Bring Your Own Device (BYOD) Security. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-114, Rev. 1. [https://doi.org/10.6028/NIST.SP.800-114r1]

[21] Padgette J, Bahr J, Holtmann M, Batra M, Chen L, Smithbey R, Scarfone KA, (2017) Guide to Bluetooth Security. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-121, Rev. 2, Includes updates as of January 19, 2022. [https://doi.org/10.6028/NIST.SP.800-121r2-upd1]

[22] Hu VC, Ferraiolo DF, Kuhn R, Schnitzer A, Sandlin K, Miller R, Scarfone KA, (2014) Guide to Attribute Based Access Control (ABAC) Definition and Considerations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-162, Includes updates as of August 2, 2019. [https://doi.org/10.6028/NIST.SP.800-162]

[23] Ferraiolo DF, Hu VC, Kuhn R, Chandramouli R, (2016) A Comparison of Attribute Based Access Control (ABAC) Standards for Data Service Applications: Extensible Access Control Markup Language (XACML) and Next Generation Access Control (NGAC). (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication ( SP) 800-178. [https://doi.org/10.6028/NIST.SP.800-178]

[24] Yaga DJ, Kuhn R, Hu VC, (2017) Verification and Test Methods for Access Control Policies/Models. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication ( SP) 800-192. [https://doi.org/10.6028/NIST.SP.800-192]

[25] Hu VC, Scarfone KA, (2012) Guidelines for Access Control System Evaluation Metrics. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) 7874. [https://doi.org/10.6028/NIST.IR.7874]

[26] Ylonen T, Turner P, Scarfone KA, Souppaya MP, (2015) Security of Interactive and Automated Access Management Using Secure Shell (SSH). (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) 7966. [https://doi.org/10.6028/NIST.IR.7966]

[27] Grassi PA, Garcia ME, Fenton JL, (2017) Digital Identity Guidelines. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-63-3, Includes updates as of March 2, 2020. [https://doi.org/10.6028/NIST.SP.800-63-3]

[28] Howell G, Franklin JM, Sritapan V, Souppaya M, Scarfone K, (2023) Guidelines for Managing the Security of Mobile Devices in the Enterprise. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-124, Rev. 2. [https://doi.org/10.6028/NIST.SP.800-124r2]

[29] Scarfone KA, Mell PM, (2007) Guide to Intrusion Detection and Prevention Systems (IDPS). (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication ( SP) 800-94. [https://doi.org/10.6028/NIST.SP.800-94]

[30] Frankel SE, Eydt B, Owens L, Scarfone KA, (2007) Establishing Wireless Robust Security Networks: A Guide to IEEE 802.11i. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication ( SP) 800-97. [https://doi.org/10.6028/NIST.SP.800-97]

[31] Souppaya MP, Scarfone KA, (2016) User’s Guide to Telework and Bring Your Own Device (BYOD) Security. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-114, Rev. 1. [https://doi.org/10.6028/NIST.SP.800-114r1]

[32] Wilson M, Hash J, (2003) Building an Information Technology Security Awareness and Training Program. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication ( SP) 800-50. [https://doi.org/10.6028/NIST.SP.800-50]

[33] Boyens JM, Smith A, Bartol N, Winkler K, Holbrook A, Fallon M, (2022) Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-161, Rev. 1. [https://doi.org/10.6028/NIST.SP.800-161r1]

[34] Petersen R, Santos D, Smith MC, Wetzel KA, Witte G, (2020) Workforce Framework for Cybersecurity (NICE Framework). (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-181, Rev. 1. [https://doi.org/10.6028/NIST.SP.800-181r1]

[35] Kent K, Souppaya MP, (2006) Guide to Computer Security Log Management. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication ( SP) 800-92. [https://doi.org/10.6028/NIST.SP.800-92]

[36] Kent K, Chevalier S, Grance T, Dang H, (2006) Guide to Integrating Forensic Techniques into Incident Response. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication ( SP) 800-86. [https://doi.org/10.6028/NIST.SP.800-86]

[37] Ayers RP, Brothers S, Jansen W, (2014) Guidelines on Mobile Device Forensics. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-101, Rev. 1. [https://doi.org/10.6028/NIST.SP.800-101r1]

[38] National Institute of Standards and Technology (2019) Security Requirements for Cryptographic Modules. (U.S. Department of Commerce, Washington, D.C.), Federal Information Processing Standards Publication (FIPS) 140-3. [https://doi.org/10.6028/NIST.FIPS.140-3]

[39] National Institute of Standards and Technology (2015) Secure Hash Standard (SHS). (U.S. Department of Commerce, Washington, D.C.), Federal Information Processing Standards Publication (FIPS) 180-4. [https://doi.org/10.6028/NIST.FIPS.180-4]

[40] National Institute of Standards and Technology (2015) SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions. (U.S. Department of Commerce, Washington, D.C.), Federal Information Processing Standards Publication (FIPS) 202. [https://doi.org/10.6028/NIST.FIPS.202]

[41] Johnson LA, Dempsey KL, Ross RS, Gupta S, Bailey D, (2011) Guide for Security-Focused Configuration Management of Information Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-128, Includes updates as of October 10, 2019. [https://doi.org/10.6028/NIST.SP.800-128]

[42] Dempsey KL, Eavy P, Moore G, (2017) Automation Support for Security Control Assessments: Volume 2: Hardware Asset Management. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) 8011, Volume 2. [https://doi.org/10.6028/NIST.IR.8011-2]

[43] Dempsey KL, Eavy P, Goren N, Moore G, (2018) Automation Support for Security Control Assessments: Volume 3: Software Asset Management. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) 8011, Volume 3. [https://doi.org/10.6028/NIST.IR.8011-3]

[44] Quinn SD, Souppaya MP, Cook MR, Scarfone KA, (2018) National Checklist Program for IT Products: Guidelines for Checklist Users and Developers. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-70, Rev. 4. [https://doi.org/10.6028/NIST.SP.800-70r4]

[45] Waltermire DA, Quinn SD, Booth H, Scarfone KA, Prisaca D, (2018) The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.3. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-126, Rev. 3. [https://doi.org/10.6028/NIST.SP.800-126r3]

[46] Sedgewick A, Souppaya MP, Scarfone KA, (2015) Guide to Application Whitelisting. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication ( SP) 800-167. [https://doi.org/10.6028/NIST.SP.800-167]

[47] Cichonski PR, Millar T, Grance T, Scarfone KA, (2012) Computer Security Incident Handling Guide. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-61, Rev. 2. [https://doi.org/10.6028/NIST.SP.800-61r2]

[48] Grance T, Nolan T, Burke K, Dudley R, White G, Good T, (2006) Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication ( SP) 800-84. [https://doi.org/10.6028/NIST.SP.800-84]

[49] Dempsey KL, Chawla NS, Johnson LA, Johnston R, Jones AC, Orebaugh AD, Scholl MA, Stine KM, (2011) Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication ( SP) 800-137. [https://doi.org/10.6028/NIST.SP.800-137]

[50] Kissel RL, Regenscheid AR, Scholl MA, Stine KM, (2014) Guidelines for Media Sanitization. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-88, Rev. 1. [https://doi.org/10.6028/NIST.SP.800-88r1]

[51] Scarfone KA, Souppaya MP, Sexton M, (2007) Guide to Storage Encryption Technologies for End User Devices. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication ( SP) 800-111. [https://doi.org/10.6028/NIST.SP.800-111]

[52] Swanson MA, Bowen P, Phillips AW, Gallup D, Lynes D, (2010) Contingency Planning Guide for Federal Information Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-34, Rev. 1, Includes updates as of November 11, 2010. [https://doi.org/10.6028/NIST.SP.800-34r1]

[53] Barker EB, Smid ME, Branstad DK, Chokhani S, (2013) A Framework for Designing Cryptographic Key Management Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication ( SP) 800-130. [https://doi.org/10.6028/NIST.SP.800-130]

[54] Barker EB, Branstad DK, Smid ME, (2015) A Profile for U.S. Federal Cryptographic Key Management Systems (CKMS). (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication ( SP) 800-152. [https://doi.org/10.6028/NIST.SP.800-152]

[55] Joint Task Force Transformation Initiative (2012) Guide for Conducting Risk Assessments. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-30, Rev. 1. [https://doi.org/10.6028/NIST.SP.800-30r1]

[56] Souppaya MP, Scarfone KA, (2022) Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-40, Rev. 4. [https://doi.org/10.6028/NIST.SP.800-40r4]

[57] Joint Task Force Transformation Initiative (2022) Assessing Security and Privacy Controls in Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53A, Rev. 5. [https://doi.org/10.6028/NIST.SP.800-53Ar5]

[58] Scarfone KA, Souppaya MP, Cody A, Orebaugh AD, (2008) Technical Guide to Information Security Testing and Assessment. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication ( SP) 800-115. [https://doi.org/10.6028/NIST.SP.800-115]

[59] Joint Task Force (2018) Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-37, Rev. 2. [https://doi.org/10.6028/NIST.SP.800-37r2]

[60] Joint Task Force Transformation Initiative (2011) Managing Information Security Risk: Organization, Mission, and Information System View. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication ( SP) 800-39. [https://doi.org/10.6028/NIST.SP.800-39]

[61] Nieles M, Pillitteri VY, Dempsey KL, (2017) An Introduction to Information Security. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-12, Rev. 1. [https://doi.org/10.6028/NIST.SP.800-12r1]

[62] Bowen P, Hash J, Wilson M, (2006) Information Security Handbook: A Guide for Managers. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-100, Includes updates as of March 7, 2007. [https://doi.org/10.6028/NIST.SP.800-100]

[63] Swanson MA, Hash J, Bowen P, (2006) Guide for Developing Security Plans for Federal Information Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-18, Rev. 1. [https://doi.org/10.6028/NIST.SP.800-18r1]

[64] Scarfone KA, Hoffman P, (2009) Guidelines on Firewalls and Firewall Policy. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-41, Rev. 1. [https://doi.org/10.6028/NIST.SP.800-41r1]

[65] Chandramouli R, (2016) Secure Virtual Network Configuration for Virtual Machine (VM) Protection. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication ( SP) 800-125B. [https://doi.org/10.6028/NIST.SP.800-125B]

[66] Rose S, Borchert O, Mitchell S, Connelly S, (2017) Zero Trust Architecture. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication ( SP) 800-207. [https://doi.org/10.6028/NIST.SP.800-207]

[67] Sriram K, Montgomery D, (2019) Resilient Interdomain Traffic Exchange: BGP Security and DDoS Mitigation. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication ( SP) 800-189. [https://doi.org/10.6028/NIST.SP.800-189]

[68] National Institute of Standards and Technology (2001) Advanced Encryption Standard (AES). (U.S. Department of Commerce, Washington, D.C.), Federal Information Processing Standards Publication (FIPS) 197, updated May 9, 2023. [https://doi.org/10.6028/NIST.FIPS.197-upd1]

[69] McKay KA, Cooper DA, (2019) Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-52, Rev. 2. [https://doi.org/10.6028/NIST.SP.800-52r2]

[70] Rose SW, Nightingale S, Garfinkel SL, Chandramouli R, (2019) Trustworthy Email. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-177, Rev. 1. [https://doi.org/10.6028/NIST.SP.800-177r1]

[71] Jansen W, Winograd T, Scarfone KA, (2008) Guidelines on Active Content and Mobile Code. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-28, Version 2. [https://doi.org/10.6028/NIST.SP.800-28ver2]

[72] Singhal A, Winograd T, Scarfone KA, (2007) Guide to Secure Web Services. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication ( SP) 800-95. [https://doi.org/10.6028/NIST.SP.800-95]

[73] Barker EB, Chen L, Roginsky A, Vassilev A, Davis R, (2018) Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-56A, Rev. 3. [https://doi.org/10.6028/NIST.SP.800-56Ar3]

[74] Barker EB, Chen L, Roginsky A, Vassilev A, Davis R, Simon S, (2019) Recommendation for Pair-Wise Key-Establishment Using Integer Factorization Cryptography. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-56B, Rev. 2. [https://doi.org/10.6028/NIST.SP.800-56Br2]

[75] Barker EB, Chen L, Davis R, (2020) Recommendation for Key-Derivation Methods in Key-Establishment Schemes. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-56C, Rev. 2. [https://doi.org/10.6028/NIST.SP.800-56Cr2]

[76] Souppaya MP, Scarfone KA, (2013) Guide to Malware Incident Prevention and Handling for Desktops and Laptops. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-83, Rev. 1. [https://doi.org/10.6028/NIST.SP.800-83r1]

[77] Tracy MC, Jansen W, Scarfone KA, Butterfield J, (2007) Guidelines on Electronic Mail Security. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-45, Version 2. [https://doi.org/10.6028/NIST.SP.800-45ver2]

[78] Committee on National Security Systems (2022) Committee on National Security Systems (CNSS) Glossary. (National Security Agency, Fort George G. Meade, MD), CNSS Instruction 4009. Available at [https://www.cnss.gov/CNSS/issuances/Instructions.cfm]

[79] Title 44 U.S. Code, Sec. 3552, Definitions. 2017 ed. Available at [https://www.govinfo.gov/app/details/USCODE-2017-title44/USCODE-2017-title44-chap35-subchapII-sec3552]

[80] Title 40 U.S. Code, Sec. 11331, Responsibilities for Federal information systems standards. 2017 ed. Available at [https://www.govinfo.gov/app/details/USCODE-2017-title40/USCODE-2017-title40-subtitleIII-chap113-subchapIII-sec11331]

[81] Title 44 U.S. Code, Sec. 3502, Definitions. 2017 ed. Available at [https://www.govinfo.gov/app/details/USCODE-2021-title44/USCODE-2021-title44-chap35-subchapI-sec3502]

[82] Chandramouli R, Rose SW, (2013) Secure Domain Name System (DNS) Deployment Guide. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-81-2. [https://doi.org/10.6028/NIST.SP.800-81-2]

[83] Dempsey K, Pillitteri V, Regenscheid A, (2021) Managing the Security of Information Exchanges. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-47, Rev. 1. [https://doi.org/10.6028/NIST.SP.800-47r1]

[84] Ross R, Pillitteri V, (2024) Assessing Security Requirements for Controlled Unclassified Information. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-171A, Rev. 3. [https://doi.org/10.6028/NIST.SP.800-171Ar3]


== Appendix A : Acronyms ==

;CFR
:Code of Federal Regulations
;CISA
:Cybersecurity and Infrastructure Security Agency
;CUI
:Controlled Unclassified Information
;CVE
:Common Vulnerabilities and Exposures
;CVSS
:Common Vulnerability Scoring System
;CWE
:Common Weakness Enumeration
;DMZ
:Demilitarized Zone
;EAP
:Extensible Authentication Protocol
;FIPS
:Federal Information Processing Standards
;FISMA
:Federal Information Security Modernization Act
;FTP
:File Transfer Protocol
;GMT
:Greenwich Mean Time
;HSM
:Hardware Security Module
;IEEE
:Institute of Electrical and Electronics Engineers
;IIoT
:Industrial Internet of Things
;IoT
:Internet of Things
;ISOO
:Information Security Oversight Office
;IT
:Information Technology
;LSI
:Large-Scale Integration
;MAC
:Media Access Control
;NARA
:National Archives and Records Administration
;NVD
:National Vulnerability Database
;ODP
:Organization-Defined Parameter
;OT
:Operational Technology
;PII
:Personally Identifiable Information
;PIN
:Personal Identification Number
;PROM
:Programmable Read-Only Memory
;ROM
:Read-Only Memory
;SCAP
:Security Content Automation Protocol
;SCRM
:Supply Chain Risk Management
;TCP/IP
:Transmission Control Protocol/Internet Protocol
;TLS
:Transport Layer Security
;UTC
:Coordinated Universal Time


== Appendix B : Glossary ==

[[#sec-sec_B|Appendix B]] provides definitions for the terminology used in SP 800-171r3. The definitions are consistent with the definitions contained in the National Information Assurance Glossary [[#bibr-ref_78|78]] unless otherwise noted.

;agency
:Any executive agency or department, military department, Federal Government corporation, Federal Government-controlled corporation, or other establishment in the Executive Branch of the Federal Government, or any independent regulatory agency. [[#bibr-ref_13|13]]
;assessment
:See ''security control assessment''.
;assessor
:See ''security control assessor''.
;audit log
:A chronological record of system activities, including records of system accesses and operations performed in a given period.
;audit record
:An individual entry in an audit log related to an audited event.
;authentication
:Verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in a system. [[#bibr-ref_7|7, adapted]].
;availability
:Ensuring timely and reliable access to and use of information. [[#bibr-ref_79|79]]
;advanced persistent threat
:An adversary that possesses sophisticated levels of expertise and significant resources which allow it to create opportunities to achieve its objectives by using multiple attack vectors including, for example, cyber, physical, and deception. These objectives typically include establishing and extending footholds within the IT infrastructure of the targeted organizations for purposes of exfiltrating information, undermining or impeding critical aspects of a mission, program, or organization; or positioning itself to carry out these objectives in the future. The advanced persistent threat pursues its objectives repeatedly over an extended period; adapts to defenders’ efforts to resist it; and is determined to maintain the level of interaction needed to execute its objectives. [[#bibr-ref_60|60]]
;authenticator
:Something the claimant possesses and controls (typically a cryptographic module or password) that is used to authenticate the claimant’s identity. This was previously referred to as a token.
;baseline configuration
:A documented set of specifications for a system or a configuration item within a system that has been formally reviewed and agreed upon at a given point in time, and that can only be changed through change control procedures.
;common secure configuration
:Recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those system components to meet operational requirements. These benchmarks are also referred to as security configuration checklists, lockdown and hardening guides, security reference guides, and security technical implementation guides.
;confidentiality
:Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information. [[#bibr-ref_79|79]]
;configuration management
:A collection of activities focused on establishing and maintaining the integrity of information technology products and systems through the control of processes for initializing, changing, and monitoring the configurations of those products and systems throughout the system development life cycle.
;configuration settings
:The set of parameters that can be changed in hardware, software, or firmware that affect the security posture and/or functionality of the system.
;controlled area
:Any area or space for which the organization has confidence that the physical and procedural protections provided are sufficient to meet the requirements established for protecting the information or system.
;controlled unclassified information
:Information that law, regulation, or governmentwide policy requires to have safeguarding or disseminating controls, excluding information that is classified under Executive Order 13526, Classified National Security Information, December 29, 2009, or any predecessor or successor order, or the Atomic Energy Act of 1954, as amended. [[#bibr-ref_1|1]]
;CUI Executive Agent
:The National Archives and Records Administration (NARA), which implements the executive branch-wide CUI Program and oversees federal agency actions to comply with Executive Order 13556. NARA has delegated this authority to the Director of the Information Security Oversight Office (ISOO). [[#bibr-ref_5|5]]
;CUI program
:The executive branch-wide program to standardize CUI handling by all federal agencies. The program includes the rules, organization, and procedures for CUI, established by Executive Order 13556, 32 CFR Part 2002, and the CUI Registry. [[#bibr-ref_5|5]]
;CUI registry
:The online repository for all information, guidance, policy, and requirements on handling CUI, including everything issued by the CUI Executive Agent other than 32 CFR Part 2002. Among other information, the CUI Registry identifies all approved CUI categories, provides general descriptions for each, identifies the basis for controls, establishes markings, and includes guidance on handling procedures. [[#bibr-ref_5|5]]
;cyber-physical systems
:Interacting digital, analog, physical, and human components engineered for function through integrated physics and logic.
;executive agency
:An executive department specified in 5 U.S.C. Sec. 101; a military department specified in 5 U.S.C. Sec. 102; an independent establishment as defined in 5 U.S.C. Sec. 104(1); and a wholly owned Government corporation fully subject to the provisions of 31 U.S.C. Chapter 91.
;external network
:A network not controlled by the organization.
;external service provider
:See ''external system service provider''.
;external system (or component)
:A system or component of a system that is outside of the authorization boundary established by the organization and for which the organization typically has no direct control over the application of required security controls or the assessment of security control effectiveness.
;external system service
:A system service that is implemented outside of the authorization boundary of the organizational system (i.e., a service that is used by but not a part of the organizational system) and for which the organization typically has no direct control over the application of required security controls or the assessment of security control effectiveness.
;external system service provider
:A provider of external system services to an organization through a variety of consumer-producer relationships, including joint ventures, business partnerships, outsourcing arrangements (i.e., through contracts, interagency agreements, lines of business arrangements), licensing agreements, and/or supply chain exchanges. [[#bibr-ref_8|8]]
;facility
:One or more physical locations containing systems or system components that process, store, or transmit information.
;federal agency
:See ''executive agency''.
;federal information system
:An information system used or operated by an executive agency, by a contractor of an executive agency, or by another organization on behalf of an executive agency. [[#bibr-ref_80|80]]
;FIPS-validated cryptography
:A cryptographic module validated by the Cryptographic Module Validation Program (CMVP) to meet the requirements specified in FIPS Publication 140-3 (as amended). As a prerequisite to CMVP validation, the cryptographic module is required to employ a cryptographic algorithm implementation that has successfully passed validation testing by the Cryptographic Algorithm Validation Program (CAVP). See ''NSA-approved cryptography''.
;firmware
:Computer programs and data stored in hardware – typically in read-only memory (ROM) or programmable read-only memory (PROM) – such that the programs and data cannot be dynamically written or modified during execution of the programs. See ''hardware'' and ''software''. [[#bibr-ref_78|78]]
;hardware
:The material physical components of a system. See ''software'' and ''firmware''. [[#bibr-ref_78|78]]
;identifier
:Unique data used to represent a person’s identity and associated attributes. A name or a card number are examples of identifiers.
:A unique label used by a system to indicate a specific entity, object, or group.
;impact
:With respect to security, the effect on organizational operations, organizational assets, individuals, other organizations, or the Nation (including the national security interests of the United States) of a loss of confidentiality, integrity, or availability of information or a system. With respect to privacy, the adverse effects that individuals could experience when an information system processes their PII.
;impact value
:The assessed worst-case potential impact that could result from a compromise of the confidentiality, integrity, or availability of information expressed as a value of low, moderate, or high. [[#bibr-ref_6|6]]
;incident
:An occurrence that actually or imminently jeopardizes, without lawful authority, the confidentiality, integrity, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies. [[#bibr-ref_79|79]]
;information
:Any communication or representation of knowledge such as facts, data, or opinions in any medium or form, including textual, numerical, graphic, cartographic, narrative, electronic, or audiovisual forms. [[#bibr-ref_13|13]]
;information flow control
:Procedure to ensure that information transfers within a system do not violate the security policy.
;information resources
:Information and related resources, such as personnel, equipment, funds, and information technology. [[#bibr-ref_81|81]]
;information security
:The protection of information and systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide confidentiality, integrity, and availability. [[#bibr-ref_79|79]]
;information system
:A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information. [[#bibr-ref_81|81]]
;information technology
:Any services, equipment, or interconnected system(s) or subsystem(s) of equipment, that are used in the automatic acquisition, storage, analysis, evaluation, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the agency. For purposes of this definition, such services or equipment if used by the agency directly or is used by a contractor under a contract with the agency that requires its use; or to a significant extent, its use in the performance of a service or the furnishing of a product. Information technology includes computers, ancillary equipment (including imaging peripherals, input, output, and storage devices necessary for security and surveillance), peripheral equipment designed to be controlled by the central processing unit of a computer, software, firmware and similar procedures, services (including cloud computing and help-desk services or other professional services which support any point of the life cycle of the equipment or service), and related resources. Information technology does not include any equipment that is acquired by a contractor incidental to a contract which does not require its use. [[#bibr-ref_13|13]]
;insider threat
:The threat that an insider will use her/his authorized access, wittingly or unwittingly, to do harm to the security of the United States. This threat can include damage to the United States through espionage, terrorism, unauthorized disclosure, or through the loss or degradation of departmental resources or capabilities.
;integrity
:Guarding against improper information modification or destruction and includes ensuring information non-repudiation and authenticity. [[#bibr-ref_79|79]]
;internal network
:A network in which the establishment, maintenance, and provisioning of security controls are under the direct control of organizational employees or contractors or in which the cryptographic encapsulation or similar security technology implemented between organization-controlled endpoints provides the same effect (with regard to confidentiality and integrity). An internal network is typically organization-owned yet may be organization-controlled while not being organization-owned.
;least privilege
:The principle that a security architecture is designed so that each entity is granted the minimum system authorizations and resources needed to perform its function.
;malicious code
:Software or firmware intended to perform an unauthorized process that will have an adverse impact on the confidentiality, integrity, or availability of a system. Examples of malicious code include viruses, worms, Trojan horses, spyware, some forms of adware, or other code-based entities that infect a host.
;media
:Physical devices or writing surfaces including, but not limited to, magnetic tapes, optical disks, magnetic disks, Large-Scale Integration (LSI) memory chips, and printouts (but not including display media) onto which information is recorded, stored, or printed within a system. [[#bibr-ref_7|7]]
;mobile code
:Software programs or parts of programs obtained from remote systems, transmitted across a network, and executed on a local system without explicit installation or execution by the recipient.
;mobile device
:A portable computing device that has a small form factor such that it can easily be carried by a single individual; is designed to operate without a physical connection (e.g., wirelessly transmit or receive information); possesses local, non-removable, or removable data storage; and includes a self-contained power source. Mobile devices may also include voice communication capabilities, on-board sensors that allow the devices to capture information, or built-in features that synchronize local data with remote locations. Examples include smartphones, tablets, and e-readers.
;multi-factor authentication
:Authentication using two or more different factors to achieve authentication. Factors include something you know (e.g., PIN, password), something you have (e.g., cryptographic identification device, token), or something you are (e.g., biometric). See ''authenticator''.
;network
:A system implemented with a collection of interconnected components. Such components may include routers, hubs, cabling, telecommunications controllers, key distribution centers, and technical control devices.
;network access
:Access to a system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, the internet).
;nonfederal organization
:An entity that owns, operates, or maintains a nonfederal system.
;nonfederal system
:A system that does not meet the criteria for a federal system.
;nonlocal maintenance
:Maintenance activities conducted by individuals communicating through an external network (e.g., the internet) or an internal network.
;NSA-approved cryptography
:Cryptography that consists of an approved algorithm, an implementation that has been approved for the protection of classified information and/or controlled unclassified information in a specific environment, and a supporting key management infrastructure. [[#bibr-ref_8|8]]
;on behalf of (an agency)
:A situation that occurs when: (i) a non-executive branch entity uses or operates an information system or maintains or collects information for the purpose of processing, storing, or transmitting Federal information; and (ii) those activities are not incidental to providing a service or product to the government. [[#bibr-ref_5|5]]
;organization
:An entity of any size, complexity, or positioning within an organizational structure. [[#bibr-ref_7|7, adapted]]
;organization-defined parameter
:The variable part of a security requirement that is instantiated by an organization during the tailoring process by assigning an organization-defined value as part of the requirement. [[#bibr-ref_8|8, adapted]]
;overlay
:A specification of security or privacy controls, control enhancements, supplemental guidance, and other supporting information employed during the tailoring process, that is intended to complement (and further refine) security control baselines. The overlay specification may be more stringent or less stringent than the original security control baseline specification and can be applied to multiple information systems. [[#bibr-ref_13|13]]
;personnel security
:The discipline of assessing the conduct, integrity, judgment, loyalty, reliability, and stability of individuals for duties and responsibilities requiring trustworthiness. [[#bibr-ref_8|8]]
;portable storage device
:A system component that can be inserted into and removed from a system and that is used to store information or data (e.g., text, video, audio, and/or image data). Such components are typically implemented on magnetic, optical, or solid-state devices (e.g., compact/digital video disks, flash/thumb drives, external solid-state drives, external hard disk drives, flash memory cards/drives that contain nonvolatile memory).
;potential impact
:The loss of confidentiality, integrity, or availability could be expected to have: (i) a limited adverse effect (FIPS Publication 199 low); (ii) a serious adverse effect (FIPS Publication 199 moderate); or (iii) a severe or catastrophic adverse effect (FIPS Publication 199 high) on organizational operations, organizational assets, or individuals. [[#bibr-ref_6|6]]
;privileged account
:A system account with the authorizations of a privileged user.
;privileged user
:A user who is authorized (and therefore, trusted) to perform security-relevant functions that ordinary users are not authorized to perform.
;records
:The recordings (automated and/or manual) of evidence of activities performed or results achieved (e.g., forms, reports, test results) that serve as a basis for verifying that the organization and the system are performing as intended. Also used to refer to units of related data fields (i.e., groups of data fields that can be accessed by a program and that contain a complete set of information on particular items).
;remote access
:Access to an organizational system by a user (or a process acting on behalf of a user) communicating through an external network (e.g., the internet). Remote access methods include dial-up, broadband, and wireless.
;remote maintenance
:Maintenance activities conducted by individuals communicating through an external network (e.g., the internet).
;replay resistance
:Protection against the capture of transmitted authentication or access control information and its subsequent retransmission with the intent of producing an unauthorized effect or gaining unauthorized access.
;risk
:A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically is a function of: (i) the adverse impact, or magnitude of harm, that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. [[#bibr-ref_13|13]]
;risk assessment
:The process of identifying risks to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation of a system. [[#bibr-ref_55|55]]
;sanitization
:Actions taken to render data written on media unrecoverable by ordinary and — for some forms of sanitization — extraordinary means.
:A process to remove information from media such that data recovery is not possible, including the removal of all classified labels, markings, and activity logs.
;security
:A condition that results from the establishment and maintenance of protective measures that enable an organization to perform its mission or critical functions despite risks posed by threats to its use of systems. Protective measures may involve a combination of deterrence, avoidance, prevention, detection, recovery, and correction that should form part of the organization’s risk management approach. [[#bibr-ref_78|78]]
;security assessment
:See ''security control assessment''.
;security control
:The safeguards or countermeasures prescribed for an information system or an organization to protect the confidentiality, integrity, and availability of the system and its information. [[#bibr-ref_13|13]]
;security control assessment
:The testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization. [[#bibr-ref_13|13]]
;security domain
:A domain that implements a security policy and is administered by a single authority. [[#bibr-ref_78|78, adapted]]
;security functions
:The hardware, software, or firmware of the system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based.
;security requirement
:A requirement levied on a system or an organization that is derived from applicable laws, Executive Orders, directives, regulations, policies, standards, procedures, or mission/business needs to ensure the confidentiality, integrity, and availability of information that is being processed, stored, or transmitted. [[#bibr-ref_7|7, adapted]] [[#bibr-ref_8|8, adapted]]
;system
:See ''information system''.
;system component
:A discrete identifiable information technology asset that represents a building block of a system and may include hardware, software, and firmware. [[#bibr-ref_41|41]]
;system security plan
:A document that describes how an organization meets or plans to meet the security requirements for a system. In particular, the system security plan describes the system boundary, the environment in which the system operates, how the security requirements are satisfied, and the relationships with or connections to other systems.
;system service
:A capability provided by a system that facilitates information processing, storage, or transmission.
;threat
:Any circumstance or event with the potential to adversely impact organizational operations, organizational assets, individuals, other organizations, or the Nation through a system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service. [[#bibr-ref_55|55]]
;system user
:An individual or (system) process acting on behalf of an individual that is authorized to access a system.


== Appendix C : Tailoring Criteria ==

This appendix describes the security control tailoring criteria used to develop the CUI security requirements. [[#table-tab_2|Table 2]] lists the available tailoring options and the shorthand tailoring symbols. [[#table-tab_3|Table 3]] through [[#table-tab_22|Table 22]] specify the tailoring actions applied to the controls in the SP 800-53 moderate baseline [[#bibr-ref_12|12]] to obtain the security requirements in Sec. 3. The controls and control enhancements are hyperlinked to the NIST [https://csrc.nist.gov/projects/cprt/catalog#/cprt/home Cybersecurity and Privacy Reference Tool], which provides online access to the specific control language and supplemental materials in SP 800-53.

Table 2. Security Control Tailoring Criteria

{|
|-
! '''TAILORING''' 
'''SYMBOL'''
! '''TAILORING CRITERIA'''
|-
| NCO
| The control is not directly related to protecting the confidentiality of CUI.
|-
| FED
| The control is primarily the responsibility of the Federal Government.
|-
| ORC
| The outcome of the control related to protecting the confidentiality of CUI is adequately covered by other related controls.[[#footnote-16|16]] 
The security controls in SP 800-53 provide a comprehensive set of security capabilities needed to protect organizational systems and support the concept of defense in depth. Some of the security controls may address similar or overlapping security topics that are covered by other related controls. These controls have been designated as ORC in the tailoring criteria.
|-
| N/A
| The control is not applicable.
|-
| CUI
| The control is directly related to protecting the confidentiality of CUI.
|}

Table 3. [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC Access Control (AC)]

{|
|-
! colspan="2" | '''NIST SP 800-53 CONTROLS MODERATE BASELINE'''
! '''TAILORING''' 
'''CRITERIA'''
! '''SECURITY''' 
'''REQUIREMENT'''
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-01 AC-01]
| Policy and Procedures
| CUI
| [[#sec-sec_03.15.01|03.15.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-02 AC-02]
| Account Management
| CUI
| [[#sec-sec_03.01.01|03.01.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-02 AC-02(01)]
| Account Management | Automated System Account Management
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-02 AC-02(02)]
| Account Management | Automated Temporary and Emergency Account Management
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-02 AC-02(03)]
| Account Management | Disable Accounts
| CUI
| [[#sec-sec_03.01.01|03.01.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-02 AC-02(04)]
| Account Management | Automated Audit Actions
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-02 AC-02(05)]
| Account Management | Inactivity Logout
| CUI
| [[#sec-sec_03.01.01|03.01.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-02 AC-02(13)]
| Account Management | Disable Accounts for High-Risk Individuals
| CUI
| [[#sec-sec_03.01.01|03.01.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-03 AC-03]
| Access Enforcement
| CUI
| [[#sec-sec_03.01.02|03.01.02]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-04 AC-04]
| Information Flow Enforcement
| CUI
| [[#sec-sec_03.01.03|03.01.03]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-05 AC-05]
| Separation of Duties
| CUI
| [[#sec-sec_03.01.04|03.01.04]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-06 AC-06]
| Least Privilege
| CUI
| [[#sec-sec_03.01.05|03.01.05]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-06 AC-06(01)]
| Least Privilege | Authorize Access to Security Functions
| CUI
| [[#sec-sec_03.01.05|03.01.05]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-06 AC-06(02)]
| Least Privilege | Non-Privileged Access for Non-Security Functions
| CUI
| [[#sec-sec_03.01.06|03.01.06]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-06 AC-06(05)]
| Least Privilege | Privileged Accounts
| CUI
| [[#sec-sec_03.01.06|03.01.06]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-06 AC-06(07)]
| Least Privilege | Review of User Privileges
| CUI
| [[#sec-sec_03.01.05|03.01.05]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-06 AC-06(09)]
| Least Privilege | Log Use of Privileged Functions
| CUI
| [[#sec-sec_03.01.07|03.01.07]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-06 AC-06(10)]
| Least Privilege | Prohibit Non-Privileged Users From Executing Privileged Functions
| CUI
| [[#sec-sec_03.01.07|03.01.07]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-07 AC-07]
| Unsuccessful Logon Attempts
| CUI
| [[#sec-sec_03.01.08|03.01.08]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-08 AC-08]
| System Use Notification
| CUI
| [[#sec-sec_03.01.09|03.01.09]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-11 AC-11]
| Device Lock
| CUI
| [[#sec-sec_03.01.10|03.01.10]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-11 AC-11(01)]
| Device Lock | Pattern-Hiding Displays
| CUI
| [[#sec-sec_03.01.10|03.01.10]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-12 AC-12]
| Session Termination
| CUI
| [[#sec-sec_03.01.11|03.01.11]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-12 AC-14]
| Permitted Actions Without Identification or Authentication
| FED
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-17 AC-17]
| Remote Access
| CUI
| [[#sec-sec_03.01.02|03.01.02]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-17 AC-17(01)]
| Remote Access | Monitoring and Control
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-17 AC-17(02)]
| Remote Access | Protection of Confidentiality and Integrity Using Encryption
| CUI
| [[#sec-sec_03.13.08|03.13.08]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-17 AC-17(03)]
| Remote Access | Managed Access Control Points
| CUI
| [[#sec-sec_03.01.12|03.01.12]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-17 AC-17(04)]
| Remote Access | Privileged Commands and Access
| CUI
| [[#sec-sec_03.01.12|03.01.12]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-18 AC-18]
| Wireless Access
| CUI
| [[#sec-sec_03.01.16|03.01.16]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-18 AC-18(01)]
| Wireless Access | Authentication and Encryption
| CUI
| [[#sec-sec_03.01.16|03.01.16]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-18 AC-18(03)]
| Wireless Access | Disable Wireless Networking
| CUI
| [[#sec-sec_03.01.16|03.01.16]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-19 AC-19]
| Access Control for Mobile Devices
| CUI
| [[#sec-sec_03.01.18|03.01.18]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-19 AC-19(05)]
| Access Control for Mobile Devices | Full Device or Container-Based Encryption
| CUI
| [[#sec-sec_03.01.18|03.01.18]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-20 AC-20]
| Use of External Systems
| CUI
| [[#sec-sec_03.01.20|03.01.20]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-20 AC-20(01)]
| Use of External Systems | Limits on Authorized Use
| CUI
| [[#sec-sec_03.01.20|03.01.20]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-20 AC-20(02)]
| Use of External Systems | Portable Storage Devices – Restricted Use
| CUI
| [[#sec-sec_03.01.20|03.01.20]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-21 AC-21]
| Information Sharing
| FED
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-22 AC-22]
| Publicly Accessible Content
| CUI
| [[#sec-sec_03.01.22|03.01.22]]
|}

Table 4. [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AT Awareness and Training (AT)]

{|
|-
! colspan="2" | '''NIST SP 800-53 CONTROLS MODERATE BASELINE'''
! '''TAILORING''' 
'''CRITERIA'''
! '''SECURITY''' 
'''REQUIREMENT'''
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AT-01 AT-01]
| Policy and Procedures
| CUI
| [[#sec-sec_03.15.01|03.15.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AT-02 AT-02]
| Literacy Training and Awareness
| CUI
| [[#sec-sec_03.02.01|03.02.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AT-02 AT-02(02)]
| Literacy Training and Awareness | Insider Threat
| CUI
| [[#sec-sec_03.02.01|03.02.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AT-02 AT-02(03)]
| Literacy Training and Awareness | Social Engineering and Mining
| CUI
| [[#sec-sec_03.02.01|03.02.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AT-03 AT-03]
| Role-Based Training
| CUI
| [[#sec-sec_03.02.02|03.02.02]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AT-04 AT-04]
| Training Records
| NCO
| —
|}

Table 5. [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU Audit and Accountability (AU)]

{|
|-
! colspan="2" | '''NIST SP 800-53 CONTROLS MODERATE BASELINE'''
! '''TAILORING''' 
'''CRITERIA'''
! '''SECURITY''' 
'''REQUIREMENT'''
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-01 AU-01]
| Policy and Procedures
| CUI
| [[#sec-sec_03.15.01|03.15.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-02 AU-02]
| Event Logging
| CUI
| [[#sec-sec_03.03.01|03.03.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-03 AU-03]
| Content of Audit Records
| CUI
| [[#sec-sec_03.03.02|03.03.02]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-03 AU-03(01)]
| Additional Audit Information
| CUI
| [[#sec-sec_03.03.02|03.03.02]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-04 AU-04]
| Audit Log Storage Capacity
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-05 AU-05]
| Response to Audit Logging Process Failures
| CUI
| [[#sec-sec_03.03.04|03.03.04]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-06 AU-06]
| Audit Record Review, Analysis, and Reporting
| CUI
| [[#sec-sec_03.03.05|03.03.05]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-06 AU-06(01)]
| Audit Record Review, Analysis, and Reporting | Automated Process Integration
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-06 AU-06(03)]
| Audit Record Review, Analysis, and Reporting | Correlate Audit Record Repositories
| CUI
| [[#sec-sec_03.03.05|03.03.05]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-07 AU-07]
| Audit Record Reduction and Report Generation
| CUI
| [[#sec-sec_03.03.06|03.03.06]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-07 AU-07(01)]
| Audit Record Reduction and Report Generation | Automatic Processing
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-08 AU-08]
| Time Stamps
| CUI
| [[#sec-sec_03.03.07|03.03.07]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-09 AU-09]
| Protection of Audit Information
| CUI
| [[#sec-sec_03.03.08|03.03.08]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-09 AU-09(04)]
| Protection of Audit Information | Access by Subset of Privileged Users
| CUI
| [[#sec-sec_03.03.08|03.03.08]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-11 AU-11]
| Audit Record Retention
| CUI
| [[#sec-sec_03.03.03|03.03.03]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AU-12 AU-12]
| Audit Record Generation
| CUI
| [[#sec-sec_03.03.03|03.03.03]]
|}

Table 6. [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CA Assessment, Authorization, and Monitoring (CA)]

{|
|-
! colspan="2" | '''NIST SP 800-53 CONTROLS MODERATE BASELINE'''
! '''TAILORING''' 
'''CRITERIA'''
! '''SECURITY''' 
'''REQUIREMENT'''
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CA-01 CA-01]
| Policy and Procedures
| CUI
| [[#sec-sec_03.15.01|03.15.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CA-02 CA-02]
| Control Assessments
| CUI
| [[#sec-sec_03.12.01|03.12.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CA-02 CA-02(01)]
| Control Assessments | Independent Assessors
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CA-03 CA-03]
| Information Exchange
| CUI
| [[#sec-sec_03.12.05|03.12.05]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CA-05 CA-05]
| Plan of Action and Milestones
| CUI
| [[#sec-sec_03.12.02|03.12.02]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CA-06 CA-06]
| Authorization
| FED
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CA-07 CA-07]
| Continuous Monitoring
| CUI
| [[#sec-sec_03.12.03|03.12.03]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CA-07 CA-07(01)]
| Continuous Monitoring | Independent Assessment
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CA-07 CA-07(04)]
| Continuous Monitoring | Risk Monitoring
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CA-09 CA-09]
| Internal System Connections
| NCO
| —
|}

Table 7. [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM Configuration Management (CM)]

{|
|-
! colspan="2" | '''NIST SP 800-53 CONTROLS MODERATE BASELINE'''
! '''TAILORING''' 
'''CRITERIA'''
! '''SECURITY''' 
'''REQUIREMENT'''
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-01 CM-01]
| Policy and Procedures
| CUI
| [[#sec-sec_03.15.01|03.15.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-02 CM-02]
| Baseline Configuration
| CUI
| [[#sec-sec_03.04.01|03.04.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-02 CM-02(02)]
| Baseline Configuration | Automation Support for Accuracy and Currency
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-02 CM-02(03)]
| Baseline Configuration | Retention of Previous Configurations
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-02 CM-02(07)]
| Baseline Configuration | Configure Systems and Components for High-Risk Areas
| CUI
| [[#sec-sec_03.04.12|03.04.12]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-03 CM-03]
| Configuration Change Control
| CUI
| [[#sec-sec_03.04.03|03.04.03]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-03 CM-03(02)]
| Configuration Change Control | Testing, Validation, and Documentation of Changes
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-03 CM-03(04)]
| Configuration Change Control | Security and Privacy Representatives
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-04 CM-04]
| Impact Analyses
| CUI
| [[#sec-sec_03.04.04|03.04.04]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-04 CM-04(02)]
| Impact Analyses | Verification of Controls
| CUI
| [[#sec-sec_03.04.04|03.04.04]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-05 CM-05]
| Access Restrictions for Change
| CUI
| [[#sec-sec_03.04.05|03.04.05]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-06 CM-06]
| Configuration Settings
| CUI
| [[#sec-sec_03.04.02|03.04.02]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-07 CM-07]
| Least Functionality
| CUI
| [[#sec-sec_03.04.06|03.04.06]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-07 CM-07(01)]
| Least Functionality | Periodic Review
| CUI
| [[#sec-sec_03.04.06|03.04.06]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-07 CM-07(02)]
| Least Functionality | Prevent Program Execution
| ORC
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-07 CM-07(05)]
| Least Functionality | Authorized Software – Allow by Exception
| CUI
| [[#sec-sec_03.04.08|03.04.08]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-08 CM-08]
| System Component Inventory
| CUI
| [[#sec-sec_03.04.10|03.04.10]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-08 CM-08(01)]
| System Component Inventory | Updates During Installation and Removal
| CUI
| [[#sec-sec_03.04.10|03.04.10]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-08 CM-08(03)]
| System Component Inventory | Automated Unauthorized Component Detection
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-09 CM-09]
| Configuration Management Plan
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-10 CM-10]
| Software Usage Restrictions
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-11 CM-11]
| User-Installed Software
| ORC
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-12 CM-12]
| Information Location
| CUI
| [[#sec-sec_03.04.11|03.04.11]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CM-12 CM-12(01)]
| Information Location | Automated Tools to Support Information Location
| NCO
| —
|}

Table 8. [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP Contingency Planning (CP)]

{|
|-
! colspan="2" | '''NIST SP 800-53 CONTROLS MODERATE BASELINE'''
! '''TAILORING''' 
'''CRITERIA'''
! '''SECURITY''' 
'''REQUIREMENT'''
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-01 CP-01]
| Policy and Procedures
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-02 CP-02]
| Contingency Plan
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-02 CP-02(01)]
| Contingency Plan | Coordinate With Related Plans
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-02 CP-02(03)]
| Contingency Plan | Resume Mission and Business Functions
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-02 CP-02(08)]
| Contingency Plan | Identify Critical Assets
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-03 CP-03]
| Contingency Training
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-04 CP-04]
| Contingency Plan Testing
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-04 CP-04(01)]
| Contingency Plan Testing | Coordinate Related Plans
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-06 CP-06]
| Alternate Storage Site
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-06 CP-06(01)]
| Alternate Storage Site | Separation of Primary Site
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-06 CP-06(03)]
| Alternate Storage Site | Accessibility
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-07 CP-07]
| Alternate Processing Site
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-07 CP-07(01)]
| Alternate Processing Site | Separation of Primary Site
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-07 CP-07(02)]
| Alternate Processing Site | Accessibility
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-07 CP-07(03)]
| Alternate Processing Site | Priority of Service
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-08 CP-08]
| Telecommunications Services
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-08 CP-08(01)]
| Telecommunications Services | Priority of Service Provisions
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-08 CP-08(02)]
| Telecommunications Services | Single Points of Failure
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-09 CP-09]
| System Backup
| CUI
| [[#sec-sec_03.08.09|03.08.09]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-09 CP-09(01)]
| System Backup | Testing for Reliability and Integrity
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-09 CP-09(08)]
| System Backup | Cryptographic Protection
| CUI
| [[#sec-sec_03.08.09|03.08.09]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-10 CP-10]
| System Recovery and Reconstitution
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-10 CP-10(02)]
| System Recovery and Reconstitution | Transaction Recovery
| NCO
| —
|}

Table 9. [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA Identification and Authentication (IA)]

{|
|-
! colspan="2" | '''NIST SP 800-53 CONTROLS MODERATE BASELINE'''
! '''TAILORING''' 
'''CRITERIA'''
! '''SECURITY''' 
'''REQUIREMENT'''
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-01 IA-01]
| Policy and Procedures
| CUI
| [[#sec-sec_03.15.01|03.15.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-02 IA-02]
| Identification and Authentication (Organizational Users)
| CUI
| [[#sec-sec_03.05.01|03.05.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-02 IA-02(01)]
| Identification and Authentication (Organizational Users) | Multi-Factor Authentication to Privileged Accounts
| CUI
| [[#sec-sec_03.05.03|03.05.03]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-02 IA-02(02)]
| Identification and Authentication (Organizational Users) | Multi-Factor Authentication to Non-Privileged Accounts
| CUI
| [[#sec-sec_03.05.03|03.05.03]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-02 IA-02(08)]
| Identification and Authentication (Organizational Users) | Access to Accounts – Replay Resistant
| CUI
| [[#sec-sec_03.05.04|03.05.04]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-02 IA-02(12)]
| Identification and Authentication (Organizational Users) | Acceptance of PIV Credentials
| FED
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-03 IA-03]
| Device Identification and Authentication
| CUI
| [[#sec-sec_03.05.02|03.05.02]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-04 IA-04]
| Identifier Management
| CUI
| [[#sec-sec_03.05.05|03.05.05]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-04 IA-04(04)]
| Identifier Management | Identify User Status
| CUI
| [[#sec-sec_03.05.05|03.05.05]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-05 IA-05]
| Authenticator Management
| CUI
| [[#sec-sec_03.05.12|03.05.12]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-05 IA-05(01)]
| Authenticator Management | Password-Based Authentication
| CUI
| [[#sec-sec_03.05.07|03.05.07]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-05 IA-05(02)]
| Authenticator Management | Public Key-Based Authentication
| FED
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-05 IA-05(06)]
| Authenticator Management | Protection of Authenticators
| FED
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-06 IA-06]
| Authentication Feedback
| CUI
| [[#sec-sec_03.05.11|03.05.11]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-07 IA-07]
| Cryptographic Module Authentication
| FED
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-08 IA-08]
| Identification and Authentication (Non-Organizational Users)
| FED
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-08 IA-08(01)]
| Identification and Authentication (Non-Organizational Users) | Acceptance of PIV Credentials From Other Agencies
| FED
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-08 IA-08(02)]
| Identification and Authentication (Non-Organizational Users) | Acceptance of External Authenticators
| FED
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-08 IA-08(04)]
| Identification and Authentication (Non-Organizational Users) | Use of Defined Profiles
| FED
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-11 IA-11]
| Re-Authentication
| CUI
| [[#sec-sec_03.05.01|03.05.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-12 IA-12]
| Identity Proofing
| FED
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-12 IA-12(02)]
| Identity Proofing | Identity Evidence
| FED
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-12 IA-12(03)]
| Identity Proofing | Identity Evidence Validation and Verification
| FED
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IA-12 IA-12(05)]
| Identity Proofing | Address Confirmation
| FED
| —
|}

Table 10. [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IR Incident Response (IR)]

{|
|-
! colspan="2" | '''NIST SP 800-53 CONTROLS MODERATE BASELINE'''
! '''TAILORING''' 
'''CRITERIA'''
! '''SECURITY''' 
'''REQUIREMENT'''
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IR-01 IR-01]
| Policy and Procedures
| CUI
| [[#sec-sec_03.15.01|03.15.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IR-02 IR-02]
| Incident Response Training
| CUI
| [[#sec-sec_03.06.04|03.06.04]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IR-03 IR-03]
| Incident Response Testing
| CUI
| [[#sec-sec_03.06.03|03.06.03]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IR-03 IR-03(02)]
| Incident Response Testing | Coordinate With Related Plans
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IR-04 IR-04]
| Incident Handling
| CUI
| [[#sec-sec_03.06.01|03.06.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IR-04 IR-04(01)]
| Incident Handling | Automated Incident Handling Processes
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IR-05 IR-05]
| Incident Monitoring
| CUI
| [[#sec-sec_03.06.02|03.06.02]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IR-06 IR-06]
| Incident Reporting
| CUI
| [[#sec-sec_03.06.02|03.06.02]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IR-06 IR-06(01)]
| Incident Reporting | Automated Reporting
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IR-06 IR-06(03)]
| Incident Reporting | Supply Chain Coordination
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IR-07 IR-07]
| Incident Response Assistance
| CUI
| [[#sec-sec_03.06.02|03.06.02]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IR-07 IR-07(01)]
| Incident Response Assistance | Automation Support for Availability of Information and Support
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=IR-08 IR-08]
| Incident Response Plan
| CUI
| [[#sec-sec_03.06.05|03.06.05]]
|}

Table 11. [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MA Maintenance (MA)]

{|
|-
! colspan="2" | '''NIST SP 800-53 CONTROLS MODERATE BASELINE'''
! '''TAILORING''' 
'''CRITERIA'''
! '''SECURITY''' 
'''REQUIREMENT'''
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MA-01 MA-01]
| System Maintenance Policy and Procedures
| CUI
| [[#sec-sec_03.15.01|03.15.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MA-02 MA-02]
| Controlled Maintenance
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MA-03 MA-03]
| Maintenance Tools
| CUI
| [[#sec-sec_03.07.04|03.07.04]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MA-03 MA-03(01)]
| Maintenance Tools | Inspect Tools
| CUI
| [[#sec-sec_03.07.04|03.07.04]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MA-03 MA-03(02)]
| Maintenance Tools | Inspect Media
| CUI
| [[#sec-sec_03.07.04|03.07.04]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MA-03 MA-03(03)]
| Maintenance Tools | Prevent Unauthorized Removal
| CUI
| [[#sec-sec_03.07.04|03.07.04]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MA-04 MA-04]
| Nonlocal Maintenance
| CUI
| [[#sec-sec_03.07.05|03.07.05]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MA-05 MA-05]
| Maintenance Personnel
| CUI
| [[#sec-sec_03.07.06|03.07.06]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MA-06 MA-06]
| Timely Maintenance
| NCO
| —
|}

Table 12. [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MP Media Protection (MP)]

{|
|-
! colspan="2" | '''NIST SP 800-53 CONTROLS MODERATE BASELINE'''
! '''TAILORING''' 
'''CRITERIA'''
! '''SECURITY''' 
'''REQUIREMENT'''
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MP-01 MP-01]
| Policy and Procedures
| CUI
| [[#sec-sec_03.15.01|03.15.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MP-02 MP-02]
| Media Access
| CUI
| [[#sec-sec_03.08.02|03.08.02]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MP-03 MP-03]
| Media Marking
| CUI
| [[#sec-sec_03.08.04|03.08.04]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MP-04 MP-04]
| Media Storage
| CUI
| [[#sec-sec_03.08.01|03.08.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MP-05 MP-05]
| Media Transport
| CUI
| [[#sec-sec_03.08.05|03.08.05]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MP-06 MP-06]
| Media Sanitization
| CUI
| [[#sec-sec_03.08.03|03.08.03]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=MP-07 MP-07]
| Media Use
| CUI
| [[#sec-sec_03.08.07|03.08.07]]
|}

Table 13. [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE Physical and Environmental Protection (PE)]

{|
|-
! colspan="2" | '''NIST SP 800-53 CONTROLS MODERATE BASELINE'''
! '''TAILORING''' 
'''CRITERIA'''
! '''SECURITY''' 
'''REQUIREMENT'''
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-01 PE-01]
| Policy and Procedures
| CUI
| [[#sec-sec_03.15.01|03.15.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-02 PE-02]
| Physical Access Authorizations
| CUI
| [[#sec-sec_03.10.01|03.10.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-03 PE-03]
| Physical Access Control
| CUI
| [[#sec-sec_03.10.07|03.10.07]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-04 PE-04]
| Access Control for Transmission
| CUI
| [[#sec-sec_03.10.08|03.10.08]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-05 PE-05]
| Access Control for Output Devices
| CUI
| [[#sec-sec_03.10.07|03.10.07]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-06 PE-06]
| Monitoring Physical Access
| CUI
| [[#sec-sec_03.10.02|03.10.02]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-06 PE-06(01)]
| Monitoring Physical Access | Intrusion Alarms and Surveillance Equipment
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-08 PE-08]
| Visitor Access Records
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-09 PE-09]
| Power Equipment and Cabling
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-10 PE-10]
| Emergency Shutoff
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-11 PE-11]
| Emergency Power
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-12 PE-12]
| Emergency Lighting
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-13 PE-13]
| Fire Protection
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-13 PE-13(01)]
| Fire Protection | Detection Systems – Automatic Activation and Notification
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-14 PE-14]
| Environmental Controls
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-15 PE-15]
| Water Damage Protection
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-16 PE-16]
| Delivery and Removal
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PE-17 PE-17]
| Alternate Work Site
| CUI
| [[#sec-sec_03.10.06|03.10.06]]
|}

Table 14. [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PL Planning (PL)]

{|
|-
! colspan="2" | '''NIST SP 800-53 CONTROLS MODERATE BASELINE'''
! '''TAILORING''' 
'''CRITERIA'''
! '''SECURITY''' 
'''REQUIREMENT'''
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PL-01 PL-01]
| Policy and Procedures
| CUI
| [[#sec-sec_03.15.01|03.15.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PL-02 PL-02]
| System Security and Privacy Plans
| CUI
| [[#sec-sec_03.15.02|03.15.02]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PL-04 PL-04]
| Rules of Behavior
| CUI
| [[#sec-sec_03.15.03|03.15.03]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PL-04 PL-04(01)]
| Rules of Behavior | Social Media and External Site/Application Usage Restrictions
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PL-08 PL-08]
| Security and Privacy Architectures
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PL-10 PL-10]
| Baseline Selection
| FED
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PL-11 PL-11]
| Baseline Tailoring
| FED
| —
|}

Table 15. [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM Program Management (PM)]

{|
|-
! colspan="2" | '''NIST SP 800-53 CONTROLS MODERATE BASELINE'''
! '''TAILORING''' 
'''CRITERIA'''
! '''SECURITY''' 
'''REQUIREMENT'''
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-01 PM-01]
| Information Security Program Plan
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-02 PM-02]
| Information Security Program Leadership Role
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-03 PM-03]
| Information Security and Privacy Resources
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-04 PM-04]
| Plan of Action and Milestones Process
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-05 PM-05]
| System Inventory
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-05 PM-05(01)]
| System Inventory | Inventory of Personally Identifiable Information
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-06 PM-06]
| Measures of Performance
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-07 PM-07]
| Enterprise Architecture
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-07 PM-07(01)]
| Enterprise Architecture | Offloading
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-08 PM-08]
| Critical Infrastructure Plan
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-09 PM-09]
| Risk Management Strategy
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-10 PM-10]
| Authorization Process
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-11 PM-11]
| Mission and Business Process Definition
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-12 PM-12]
| Insider Threat Program
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-13 PM-13]
| Security and Privacy Workforce
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-14 PM-14]
| Testing, Training, and Monitoring
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-15 PM-15]
| Security and Privacy Groups and Associations
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-16 PM-16]
| Threat Awareness Program
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-16 PM-16(01)]
| Threat Awareness Program | Automated Means for Sharing Threat Intelligence
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-17 PM-17]
| Protecting Controlled Unclassified Information on External Systems
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-18 PM-18]
| Privacy Program Plan
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-19 PM-19]
| Privacy Program Leadership Role
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-20 PM-20]
| Dissemination of Privacy Program Information
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-20 PM-20(01)]
| Dissemination of Privacy Program Information | Privacy Policies on Websites, Applications, and Digital Services
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-21 PM-21]
| Accounting of Disclosures
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-22 PM-22]
| Personally Identifiable Information Quality Management
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-23 PM-23]
| Data Governance Body
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-24 PM-24]
| Data Integrity Board
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-25 PM-25]
| Minimization of PII Used in Testing, Training, and Research
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-26 PM-26]
| Complaint Management
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-27 PM-27]
| Privacy Reporting
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-28 PM-28]
| Risk Framing
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-29 PM-29]
| Risk Management Program Leadership Roles
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-30 PM-30]
| Supply Chain Risk Management Strategy
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-30 PM-30(01)]
| Supply Chain Risk Management Strategy | Suppliers of Critical or Mission-Essential Items
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-31 PM-31]
| Continuous Monitoring Strategy
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PM-32 PM-32]
| Purposing
| N/A
| —
|}

Table 16. [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PS Personnel Security (PS)]

{|
|-
! colspan="2" | '''NIST SP 800-53 CONTROLS MODERATE BASELINE'''
! '''TAILORING''' 
'''CRITERIA'''
! '''SECURITY''' 
'''REQUIREMENT'''
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PS-01 PS-01]
| Policy and Procedures
| CUI
| [[#sec-sec_03.15.01|03.15.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PS-02 PS-02]
| Position Risk Designation
| FED
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PS-03 PS-03]
| Personnel Screening
| CUI
| [[#sec-sec_03.09.01|03.09.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PS-04 PS-04]
| Personnel Termination
| CUI
| [[#sec-sec_03.09.02|03.09.02]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PS-05 PS-05]
| Personnel Transfer
| CUI
| [[#sec-sec_03.09.02|03.09.02]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PS-06 PS-06]
| Access Agreements
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PS-07 PS-07]
| External Personnel Security
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PS-08 PS-08]
| Personnel Sanctions
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PS-09 PS-09]
| Position Descriptions
| FED
| —
|}

Table 17. [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PT PII Processing and Transparency (PT)]

{|
|-
! colspan="2" | '''NIST SP 800-53 CONTROLS MODERATE BASELINE'''
! '''TAILORING''' 
'''CRITERIA'''
! '''SECURITY''' 
'''REQUIREMENT'''
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PT-01 PT-01]
| Policy and Procedures
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PT-02 PT-02]
| Authority to Process Personally Identifiable Information
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PT-02 PT-02(01)]
| Authority to Process Personally Identifiable Information | Data Tagging
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PT-02 PT-02(02)]
| Authority to Process Personally Identifiable Information | Automation
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PT-03 PT-03]
| Personally Identifiable Information Processing Purposes
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PT-03 PT-03(01)]
| Personally Identifiable Information Processing Purposes | Data Tagging
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PT-03 PT-03(02)]
| Personally Identifiable Information Processing Purposes | Automation
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PT-04 PT-04]
| Consent
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PT-04 PT-04(01)]
| Consent | Tailored Consent
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PT-04 PT-04(02)]
| Consent | Just-in-Time Consent
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PT-04 PT-04(03)]
| Consent | Revocation
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PT-05 PT-05]
| Privacy Notice
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PT-05 PT-05(01)]
| Privacy Notice | Just-in-Time Notice
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PT-05 PT-05(02)]
| Privacy Notice | Privacy Act Statements
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PT-06 PT-06]
| System of Records Notice
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PT-06 PT-06(01)]
| System of Records Notice | Routine Uses
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PT-06 PT-06(02)]
| System of Records Notice | Exemption Rules
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PT-07 PT-07]
| Specific Categories of Personally Identifiable Information
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PT-07 PT-07(01)]
| Specific Categories of Personally Identifiable Information | Social Security Numbers
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PT-07 PT-07(02)]
| Specific Categories of Personally Identifiable Information | First Amendment Information
| N/A
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=PT-08 PT-08]
| Computer Matching Requirements
| N/A
| —
|}

Table 18. [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=RA Risk Assessment (RA)]

{|
|-
! colspan="2" | '''NIST SP 800-53 CONTROLS MODERATE BASELINE'''
! '''TAILORING''' 
'''CRITERIA'''
! '''SECURITY''' 
'''REQUIREMENT'''
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=RA-01 RA-01]
| Policy and Procedures
| CUI
| [[#sec-sec_03.15.01|03.15.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=RA-02 RA-02]
| Security Categorization
| FED
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=RA-03 RA-03]
| Risk Assessment
| CUI
| [[#sec-sec_03.11.01|03.11.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=RA-03 RA-03(01)]
| Risk Assessment | Supply Chain Risk Assessment
| CUI
| [[#sec-sec_03.11.01|03.11.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=RA-05 RA-05]
| Vulnerability Monitoring and Scanning
| CUI
| [[#sec-sec_03.11.02|03.11.02]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=RA-05 RA-05(02)]
| Vulnerability Monitoring and Scanning | Update Vulnerabilities to be Scanned
| CUI
| [[#sec-sec_03.11.02|03.11.02]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=RA-05 RA-05(05)]
| Vulnerability Monitoring and Scanning | Privileged Access
| ORC
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=RA-05 RA-05(11)]
| Vulnerability Monitoring and Scanning | Public Disclosure Program
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=RA-07 RA-07]
| Risk Response
| CUI
| [[#sec-sec_03.11.04|03.11.04]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=RA-09 RA-09]
| Criticality Analysis
| NCO
| —
|}

Table 19. [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SA System and Services Acquisition (SA)]

{|
|-
! colspan="2" | '''NIST SP 800-53 CONTROLS MODERATE BASELINE'''
! '''TAILORING''' 
'''CRITERIA'''
! '''SECURITY''' 
'''REQUIREMENT'''
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SA-01 SA-01]
| Policy and Procedures
| CUI
| [[#sec-sec_03.15.01|03.15.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SA-02 SA-02]
| Allocation of Resources
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SA-03 SA-03]
| System Development Life Cycle
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SA-04 SA-04]
| Acquisition Process
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SA-04 SA-04(01)]
| Acquisition Process | Functional Properties of Controls
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SA-04 SA-04(02)]
| Acquisition Process | Design and Implementation Information for Controls
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SA-04 SA-04(09)]
| Acquisition Process | Functions, Ports, Protocols, and Services in Use
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SA-04 SA-04(10)]
| Acquisition Process | Use of Approved PIV Products
| FED
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SA-05 SA-05]
| System Documentation
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SA-08 SA-08]
| Security and Privacy Engineering Principles
| CUI
| [[#sec-sec_03.16.01|03.16.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SA-09 SA-09]
| External System Services
| CUI
| [[#sec-sec_03.16.03|03.16.03]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SA-09 SA-09(02)]
| External System Services | Identification of Functions, Ports, Protocols, and Services
| ORC
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SA-10 SA-10]
| Developer Configuration Management
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SA-11 SA-11]
| Developer Testing and Evaluation
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SA-15 SA-15]
| Development Process, Standards, and Tools
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SA-15 SA-15(03)]
| Development Process, Standards, and Tools | Criticality Analysis
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SA-22 SA-22]
| Unsupported System Components
| CUI
| [[#sec-sec_03.16.02|03.16.02]]
|}

Table 20. [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC System and Communications Protection (SC)]

{|
|-
! colspan="2" | '''NIST SP 800-53 CONTROLS MODERATE BASELINE'''
! '''TAILORING''' 
'''CRITERIA'''
! '''SECURITY''' 
'''REQUIREMENT'''
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-01 SC-01]
| Policy and Procedures
| CUI
| [[#sec-sec_03.15.01|03.15.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-02 SC-02]
| Separation of System and User Functionality
| ORC
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-04 SC-04]
| Information in Shared System Resources
| CUI
| [[#sec-sec_03.13.04|03.13.04]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-05 SC-05]
| Denial-of-Service Protection
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-07 SC-07]
| Boundary Protection
| CUI
| [[#sec-sec_03.13.01|03.13.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-07 SC-07(03)]
| Boundary Protection | Access Points
| ORC
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-07 SC-07(04)]
| Boundary Protection | External Telecommunications Services
| ORC
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-07 SC-07(05)]
| Boundary Protection | Deny by Default – Allow by Exception
| CUI
| [[#sec-sec_03.13.06|03.13.06]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-07 SC-07(07)]
| Boundary Protection | Split Tunneling for Remote Devices
| ORC
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-07 SC-07(08)]
| Boundary Protection | Route Traffic to Authenticated Proxy Servers
| ORC
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-08 SC-08]
| Transmission Confidentiality and Integrity
| CUI
| [[#sec-sec_03.13.08|03.13.08]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-08 SC-08(01)]
| Transmission Confidentiality and Integrity | Cryptographic Protection
| CUI
| [[#sec-sec_03.13.08|03.13.08]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-10 SC-10]
| Network Disconnect
| CUI
| [[#sec-sec_03.13.09|03.13.09]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-12 SC-12]
| Cryptographic Key Establishment and Management
| CUI
| [[#sec-sec_03.13.10|03.13.10]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-13 SC-13]
| Cryptographic Protection
| CUI
| [[#sec-sec_03.13.11|03.13.11]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-15 SC-15]
| Collaborative Computing Devices and Applications
| CUI
| [[#sec-sec_03.13.12|03.13.12]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-17 SC-17]
| Public Key Infrastructure Certificates
| FED
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-18 SC-18]
| Mobile Code
| CUI
| [[#sec-sec_03.13.13|03.13.13]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-20 SC-20]
| Secure Name/Address Resolution Service (Authoritative Source)
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-21 SC-21]
| Secure Name/Address Resolution Service (Recursive or Caching Resolver)
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-22 SC-22]
| Architecture and Provisioning for Name/Address Resolution Service
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-23 SC-23]
| Session Authenticity
| CUI
| [[#sec-sec_03.13.15|03.13.15]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-28 SC-28]
| Protection of Information at Rest
| CUI
| [[#sec-sec_03.13.08|03.13.08]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-28 SC-28(01)]
| Protection of Information at Rest | Cryptographic Protection
| CUI
| [[#sec-sec_03.13.08|03.13.08]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SC-39 SC-39]
| Process Isolation
| NCO
| —
|}

Table 21. [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI System and Information Integrity (SI)]

{|
|-
! colspan="2" | '''NIST SP 800-53 CONTROLS MODERATE BASELINE'''
! '''TAILORING''' 
'''CRITERIA'''
! '''SECURITY''' 
'''REQUIREMENT'''
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-01 SI-01]
| Policy and Procedures
| CUI
| [[#sec-sec_03.15.01|03.15.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-02 SI-02]
| Flaw Remediation
| CUI
| [[#sec-sec_03.14.01|03.14.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-02 SI-02(02)]
| Flaw Remediation | Automated Flaw Remediation Status
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-03 SI-03]
| Malicious Code Protection
| CUI
| [[#sec-sec_03.14.02|03.14.02]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-04 SI-04]
| System Monitoring
| CUI
| [[#sec-sec_03.14.06|03.14.06]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-04 SI-04(02)]
| System Monitoring | Automated Tools and Mechanisms for Real-Time Analysis
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-04 SI-04(04)]
| System Monitoring | Inbound and Outbound Communications Traffic
| CUI
| [[#sec-sec_03.14.06|03.14.06]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-04 SI-04(05)]
| System Monitoring | System-Generated Alerts
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-05 SI-05]
| Security Alerts, Advisories, and Directives
| CUI
| [[#sec-sec_03.14.03|03.14.03]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-07 SI-07]
| Software, Firmware, and Information Integrity
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-07 SI-07(01)]
| Software, Firmware, and Information Integrity | Integrity Checks
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-07 SI-07(07)]
| Software, Firmware, and Information Integrity | Integration of Detection and Response
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-08 SI-08]
| Spam Protection
| ORC
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-08 SI-08(02)]
| Spam Protection | Automatic Updates
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-10 SI-10]
| Information Input Validation
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-11 SI-11]
| Error Handling
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-12 SI-12]
| Information Management and Retention
| CUI
| [[#sec-sec_03.14.08|03.14.08]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SI-16 SI-16]
| Memory Protection
| NCO
| —
|}

Table 22. [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SR Supply Chain Risk Management (SR)]

{|
|-
! colspan="2" | '''NIST SP 800-53 CONTROLS MODERATE BASELINE'''
! '''TAILORING''' 
'''CRITERIA'''
! '''SECURITY''' 
'''REQUIREMENT'''
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SR-01 SR-01]
| Policy and Procedures
| CUI
| [[#sec-sec_03.15.01|03.15.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SR-02 SR-02]
| Supply Chain Risk Management Plan
| CUI
| [[#sec-sec_03.17.01|03.17.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SR-02 SR-02(01)]
| Supply Chain Risk Management Plan | Establish SCRM Team
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SR-03 SR-03]
| Supply Chain Controls and Processes
| CUI
| [[#sec-sec_03.17.03|03.17.03]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SR-05 SR-05]
| Acquisition Strategies, Tools, and Methods
| CUI
| [[#sec-sec_03.17.02|03.17.02]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SR-06 SR-06]
| Supplier Assessments and Reviews
| CUI
| [[#sec-sec_03.11.01|03.11.01]]
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SR-08 SR-08]
| Notification Agreements
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SR-10 SR-10]
| Inspection of Systems or Components
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SR-11 SR-11]
| Component Authenticity
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SR-11 SR-11(01)]
| Component Authenticity | Anti-Counterfeit Training
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SR-11 SR-11(02)]
| Component Authenticity | Configuration Control for Component Service and Repair
| NCO
| —
|-
| [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=SR-12 SR-12]
| Component Disposal
| ORC
| —
|}


== Appendix D : Organization-Defined Parameters ==

This appendix lists the organization-defined parameters (ODPs) that are included in the security requirements in Sec. 3. The ODPs are listed sequentially by requirement family, beginning with the first requirement containing an ODP in the Access Control (AC) family and ending with the last requirement containing an ODP in the Supply Chain Risk Management (SR) family.

Table 23. Organization-Defined Parameters

{|
|-
! '''SECURITY''' 
'''REQUIREMENT'''
! colspan="2" | '''ORGANIZATION-DEFINED PARAMETER'''
|-
| [[#sec-sec_03.01.01|03.01.01]]
| [[#list_03.01.01.f.02|03.01.01.f.02]]
| [''Assignment: organization-defined time period'']
|-
| [[#sec-sec_03.01.01|03.01.01]]
| [[#list_03.01.01.g.01|03.01.01.g.01]]
| [''Assignment: organization-defined time period'']
|-
| [[#sec-sec_03.01.01|03.01.01]]
| [[#list_03.01.01.g.02|03.01.01.g.02]]
| [''Assignment: organization-defined time period'']
|-
| [[#sec-sec_03.01.01|03.01.01]]
| [[#list_03.01.01.g.03|03.01.01.g.03]]
| [''Assignment: organization-defined time period'']
|-
| [[#sec-sec_03.01.01|03.01.01]]
| [[#list_03.01.01.h|03.01.01.h]]
| [''Assignment: organization-defined time period'']
|-
| [[#sec-sec_03.01.01|03.01.01]]
| [[#list_03.01.01.h|03.01.01.h]]
| [''Assignment: organization-defined circumstances'']
|-
| [[#sec-sec_03.01.05|03.01.05]]
| [[#list_03.01.05.b|03.01.05.b]]
| [''Assignment: organization-defined security functions'']
|-
| [[#sec-sec_03.01.05|03.01.05]]
| [[#list_03.01.05.b|03.01.05.b]]
| [''Assignment: organization-defined security-relevant information'']
|-
| [[#sec-sec_03.01.05|03.01.05]]
| [[#list_03.01.05.c|03.01.05.c]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.01.06|03.01.06]]
| [[#list_03.01.06.a|03.01.06.a]]
| [''Assignment: organization-defined personnel or roles'']
|-
| [[#sec-sec_03.01.08|03.01.08]]
| [[#list_03.01.08.a|03.01.08.a]]
| [''Assignment: organization-defined number'']
|-
| [[#sec-sec_03.01.08|03.01.08]]
| [[#list_03.01.08.a|03.01.08.a]]
| [''Assignment: organization-defined time period'']
|-
| [[#sec-sec_03.01.08|03.01.08]]
| [[#list_03.01.08.b|03.01.08.b]]
| [''Selection (one or more): lock the account or node for an'' [''Assignment: organization-defined time period'']''; lock the account or node until released by an administrator; delay next logon prompt; notify system administrator; take other action'']
|-
| [[#sec-sec_03.01.10|03.01.10]]
| [[#list_03.01.10.a|03.01.10.a]]
| [''Selection (one or more): initiating a device lock after ''[''Assignment: organization-defined time period'']'' of inactivity; requiring the user to initiate a device lock before leaving the system unattended'']
|-
| [[#sec-sec_03.01.11|03.01.11]]
| [[#sec-sec_03.01.11|03.01.11]]
| [''Assignment: organization-defined conditions or trigger events requiring session disconnect'']
|-
| [[#sec-sec_03.01.20|03.01.20]]
| [[#list_03.01.20.b|03.01.20.b]]
| [''Assignment: organization-defined security requirements'']
|-
| [[#sec-sec_03.02.01|03.02.01]]
| [[#list_03.02.01.a.01|03.02.01.a.01]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.02.01|03.02.01]]
| [[#list_03.02.01.a.02|03.02.01.a.02]]
| [''Assignment: organization-defined events'']
|-
| [[#sec-sec_03.02.01|03.02.01]]
| [[#list_03.02.01.b|03.02.01.b]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.02.01|03.02.01]]
| [[#list_03.02.01.b|03.02.01.b]]
| [''Assignment: organization-defined events'']
|-
| [[#sec-sec_03.02.02|03.02.02]]
| [[#list_03.02.02.a.01|03.02.02.a.01]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.02.02|03.02.02]]
| [[#list_03.02.02.a.02|03.02.02.a.02]]
| [''Assignment: organization-defined events'']
|-
| [[#sec-sec_03.02.02|03.02.02]]
| [[#list_03.02.02.b|03.02.02.b]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.02.02|03.02.02]]
| [[#list_03.02.02.b|03.02.02.b]]
| [''Assignment: organization-defined events'']
|-
| [[#sec-sec_03.03.01|03.03.01]]
| [[#list_03.03.01.a|03.03.01.a]]
| [''Assignment: organization-defined event types'']
|-
| [[#sec-sec_03.03.01|03.03.01]]
| [[#list_03.03.01.b|03.03.01.b]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.03.04|03.03.04]]
| [[#list_03.03.04.a|03.03.04.a]]
| [''Assignment: organization-defined time period'']
|-
| [[#sec-sec_03.03.04|03.03.04]]
| [[#list_03.03.04.b|03.03.04.b]]
| [''Assignment: organization-defined additional actions'']
|-
| [[#sec-sec_03.03.05|03.03.05]]
| [[#list_03.03.05.a|03.03.05.a]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.03.07|03.03.07]]
| [[#list_03.03.07.b|03.03.07.b]]
| [''Assignment: organization-defined granularity of time measurement'']
|-
| [[#sec-sec_03.04.01|03.04.01]]
| [[#list_03.04.01.b|03.04.01.b]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.04.02|03.04.02]]
| [[#list_03.04.02.a|03.04.02.a]]
| [''Assignment: organization-defined configuration settings'']
|-
| [[#sec-sec_03.04.06|03.04.06]]
| [[#list_03.04.06.b|03.04.06.b]]
| [''Assignment: organization-defined functions, ports, protocols, connections, and/or services'']
|-
| [[#sec-sec_03.04.06|03.04.06]]
| [[#list_03.04.06.c|03.04.06.c]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.04.08|03.04.08]]
| [[#list_03.04.08.c|03.04.08.c]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.04.10|03.04.10]]
| [[#list_03.04.10.b|03.04.10.b]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.04.12|03.04.12]]
| [[#list_03.04.12.a|03.04.12.a]]
| [''Assignment: organization-defined system configurations'']
|-
| [[#sec-sec_03.04.12|03.04.12]]
| [[#list_03.04.12.b|03.04.12.b]]
| [''Assignment: organization-defined security requirements'']
|-
| [[#sec-sec_03.05.01|03.05.01]]
| [[#list_03.05.01.b|03.05.01.b]]
| [''Assignment: organization-defined circumstances or situations requiring re-authentication'']
|-
| [[#sec-sec_03.05.02|03.05.02]]
| [[#sec-sec_03.05.02|03.05.02]]
| [''Assignment: organization-defined devices or types of devices'']
|-
| [[#sec-sec_03.05.05|03.05.05]]
| [[#list_03.05.05.c|03.05.05.c]]
| [''Assignment: organization-defined time period'']
|-
| [[#sec-sec_03.05.05|03.05.05]]
| [[#list_03.05.05.d|03.05.05.d]]
| [''Assignment: organization-defined characteristic identifying individual status'']
|-
| [[#sec-sec_03.05.07|03.05.07]]
| [[#list_03.05.07.a|03.05.07.a]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.05.07|03.05.07]]
| [[#list_03.05.07.f|03.05.07.f]]
| [''Assignment: organization-defined composition and complexity rules'']
|-
| [[#sec-sec_03.05.12|03.05.12]]
| [[#list_03.05.12.e|03.05.12.e]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.05.12|03.05.12]]
| [[#list_03.05.12.e|03.05.12.e]]
| [''Assignment: organization-defined events'']
|-
| [[#sec-sec_03.06.02|03.06.02]]
| [[#list_03.06.02.b|03.06.02.b]]
| [''Assignment: organization-defined time period'']
|-
| [[#sec-sec_03.06.02|03.06.02]]
| [[#list_03.06.02.c|03.06.02.c]]
| [''Assignment: organization-defined authorities'']
|-
| [[#sec-sec_03.06.03|03.06.03]]
| [[#sec-sec_03.06.03|03.06.03]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.06.04|03.06.04]]
| [[#list_03.06.04.a.01|03.06.04.a.01]]
| [''Assignment: organization-defined time period'']
|-
| [[#sec-sec_03.06.04|03.06.04]]
| [[#list_03.06.04.a.03|03.06.04.a.03]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.06.04|03.06.04]]
| [[#list_03.06.04.b|03.06.04.b]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.06.04|03.06.04]]
| [[#list_03.06.04.b|03.06.04.b]]
| [''Assignment: organization-defined events'']
|-
| [[#sec-sec_03.08.07|03.08.07]]
| [[#list_03.08.07.a|03.08.07.a]]
| [''Assignment: organization-defined types of system media'']
|-
| [[#sec-sec_03.09.01|03.09.01]]
| [[#list_03.09.01.b|03.09.01.b]]
| [''Assignment: organization-defined conditions requiring rescreening'']
|-
| [[#sec-sec_03.09.02|03.09.02]]
| [[#list_03.09.02.a.01|03.09.02.a.01]]
| [''Assignment: organization-defined time period'']
|-
| [[#sec-sec_03.10.01|03.10.01]]
| [[#list_03.10.01.c|03.10.01.c]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.10.02|03.10.02]]
| [[#list_03.10.02.b|03.10.02.b]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.10.02|03.10.02]]
| [[#list_03.10.02.b|03.10.02.b]]
| [''Assignment: organization-defined events or potential indications of events'']
|-
| [[#sec-sec_03.10.06|03.10.06]]
| [[#list_03.10.06.b|03.10.06.b]]
| [''Assignment: organization-defined security requirements'']
|-
| [[#sec-sec_03.11.01|03.11.01]]
| [[#list_03.11.01.b|03.11.01.b]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.11.02|03.11.02]]
| [[#list_03.11.02.a|03.11.02.a]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.11.02|03.11.02]]
| [[#list_03.11.02.b|03.11.02.b]]
| [''Assignment: organization-defined response times'']
|-
| [[#sec-sec_03.11.02|03.11.02]]
| [[#list_03.11.02.c|03.11.02.c]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.12.01|03.12.01]]
| [[#sec-sec_03.12.01|03.12.01]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.12.05|03.12.05]]
| [[#list_03.12.05.a|03.12.05.a]]
| [''Selection (one or more): interconnection security agreements; information exchange security agreements; memoranda of understanding or agreement; service-level agreements; user agreements; nondisclosure agreements; other types of agreements'']
|-
| [[#sec-sec_03.12.05|03.12.05]]
| [[#list_03.12.05.c|03.12.05.c]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.13.09|03.13.09]]
| [[#sec-sec_03.13.09|03.13.09]]
| [''Assignment: organization-defined time period'']
|-
| [[#sec-sec_03.13.10|03.13.10]]
| [[#sec-sec_03.13.10|03.13.10]]
| [''Assignment: organization-defined requirements for key establishment and management'']
|-
| [[#sec-sec_03.13.11|03.13.11]]
| [[#sec-sec_03.13.11|03.13.11]]
| [''Assignment: organization-defined types of cryptography'']
|-
| [[#sec-sec_03.13.12|03.13.12]]
| [[#list_03.13.12.a|03.13.12.a]]
| [''Assignment: organization-defined exceptions where remote activation is to be allowed'']
|-
| [[#sec-sec_03.14.01|03.14.01]]
| [[#list_03.14.01.b|03.14.01.b]]
| [''Assignment: organization-defined time period'']
|-
| [[#sec-sec_03.14.02|03.14.02]]
| [[#list_03.14.02.c.01|03.14.02.c.01]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.15.01|03.15.01]]
| [[#list_03.15.01.b|03.15.01.b]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.15.02|03.15.02]]
| [[#list_03.15.02.b|03.15.02.b]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.15.03|03.15.03]]
| [[#list_03.15.03.d|03.15.03.d]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.16.01|03.16.01]]
| [[#sec-sec_03.16.01|03.16.01]]
| [''Assignment: organization-defined systems security engineering principles'']
|-
| [[#sec-sec_03.16.03|03.16.03]]
| [[#list_03.16.03.a|03.16.03.a]]
| [''Assignment: organization-defined security requirements'']
|-
| [[#sec-sec_03.17.01|03.17.01]]
| [[#list_03.17.01.b|03.17.01.b]]
| [''Assignment: organization-defined frequency'']
|-
| [[#sec-sec_03.17.03|03.17.03]]
| [[#list_03.17.03.b|03.17.03.b]]
| [''Assignment: organization-defined security requirements'']
|}


== Appendix E : Change Log ==

This publication incorporates the following changes from the original edition (February 2020; updated January 28, 2021):

* Streamlined introductory information in Sec. 1 and Sec. 2 to improve clarity and understanding
* Modified the security requirements and families in Sec. 3 to reflect the security controls in the SP 800-53B [[#bibr-ref_12|12]] moderate baseline and the tailoring actions in [[#sec-sec_C|Appendix C]]
* Eliminated the distinction between basic and derived security requirements
* Increased the specificity of security requirements to remove ambiguity, improve the effectiveness of implementation, and clarify the scope of assessments
* Introduced organization-defined parameters (ODPs) in selected security requirements to increase flexibility and help organizations better manage risk
* Grouped security requirements, where possible, to improve understanding and the efficiency of implementations and assessments
* Removed outdated and redundant security requirements
* Added new security requirements
* Added titles to the security requirements
* Restructured and streamlined the security requirement discussion sections
* Added new tailoring categories: Other Related Controls (ORC) and Not Applicable (N/A)
* Recategorized selected controls in the SP 800-53B moderate baseline using the tailoring criteria in [[#sec-sec_C|Appendix C]]
* Revised the security requirements for consistency with the security control language in SP 800-53
* Revised the structure of the References, Acronyms, and Glossary sections for greater clarity and ease of use
* Revised the tailoring tables in [[#sec-sec_C|Appendix C]] to be consistent with the changes to the security requirements
* Added new appendix listing organization-defined parameters for security requirements

[[#table-tab_24|Table 24]] shows the changes incorporated into this publication. Errata updates can include corrections, clarifications, or other minor changes in the publication that are either ''editorial'' or ''substantive'' in nature. Any potential updates to this document that are not yet published in an errata update or a formal revision, including additional issues and potential corrections, will be posted as they are identified. See the [https://csrc.nist.gov/pubs/sp/800/171/r3/final publication details] for this report. The current release of this publication does not include any errata updates.

Table 24. Change Log

{|
|-
| '''PUBLICATION ID'''
| '''DATE'''
| '''TYPE OF EDIT'''
| '''CHANGE'''
| '''LOCATION'''
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|-
|
|
|
|
|
|}

== Footnotes ==

[[#footnote-1-backlink|1]] CUI is any information that a law, regulation, or government-wide policy requires to have safeguarding or disseminating controls, excluding information that is classified under EO 13526 [[#bibr-ref_2|2]], any predecessor or successor order, or the Atomic Energy Act [[#bibr-ref_3|3]] as amended.

[[#footnote-2-backlink|2]] Procedures for the use of CUI include marking, safeguarding, transporting, disseminating, reusing, and disposing of the information.

[[#footnote-3-backlink|3]] A ''federal information system'' is a system that is used or operated by an executive agency, by a contractor of an executive agency, or by another organization on behalf of an executive agency. The term ''system'' is used in this publication to represent people, processes, and technologies involved in the processing, storage, or transmission of CUI. Systems can include operational technology (OT), information technology (IT), Internet of Things (IoT) devices, Industrial IoT (IIoT) devices, specialized systems, cyber-physical systems, embedded systems, and sensors.

[[#footnote-4-backlink|4]] A ''nonfederal organization'' is any entity that owns, operates, or maintains a nonfederal system.

[[#footnote-5-backlink|5]] A ''nonfederal system'' is any system that does not meet the criteria for a federal information system.

[[#footnote-6-backlink|6]] The term ''security requirement'' refers to the protection needs for a system or organization. Security requirements may be derived from laws, Executive Orders, directives, regulations, policies, standards, mission and business needs, or risk assessments.

[[#footnote-7-backlink|7]] In accordance with EO 13526 [[#bibr-ref_2|2]] and 32 CFR 2002 [[#bibr-ref_5|5]], the scope of CUI protection is primarily focused on ''confidentiality''. However, the security objectives of confidentiality and integrity are closely related since many of the underlying security mechanisms support both objectives. Therefore, the security requirements in this publication address the protection of CUI from unauthorized disclosure and modification.

[[#footnote-8-backlink|8]] Nonfederal organizations that collect or maintain information on behalf of a federal agency or that use or operate a system on behalf of an agency must comply with the requirements in FISMA [[#bibr-ref_9|9]].

[[#footnote-9-backlink|9]] System ''components'' include workstations, servers, notebook computers, smartphones, tablets, input and output devices, network components, operating systems, virtual machines, database management systems, and applications.

''[[#footnote-10-backlink|10]]Tailoring'' is the process by which control baselines are modified to achieve certain organizational goals and objectives [[#bibr-ref_13|13]].

[[#footnote-11-backlink|11]] In accordance with 32 CFR 2002 [[#bibr-ref_5|5]], CUI is categorized at no less than the FIPS 199 [[#bibr-ref_6|6]] moderate confidentiality impact value. However, when federal law, regulation, or government-wide policy establishing the control of CUI specifies controls that differ from those of the moderate control baseline, then the applicable law, regulation, or government-wide policy is followed.

[[#footnote-12-backlink|12]] “Adequately addressed by other related controls” means that the protection capability offered by the control is provided by another control in the same or different control family. Using this tailoring option helps to eliminate potential redundancy in requirements without affecting the protection of CUI in nonfederal systems and organizations.

[[#footnote-13-backlink|13]] [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-09 CP-09] and [https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=CP-09 CP-09(08)] are included by exception to ensure the confidentiality of backup information is projected.

[[#footnote-14-backlink|14]] NIST does not establish or assign values for ODPs. If ODP values for selected security requirements are not formally established or assigned by a federal agency or a consortium of federal agencies, nonfederal organizations must assign those values to complete the requirements.

[[#footnote-15-backlink|15]] With few exceptions, the security controls in SP 800-53 are policy-, technology-, and sector-neutral, meaning that the controls focus on the fundamental measures necessary to protect information across the information life cycle.

[[#footnote-16-backlink|16]] The security controls in SP 800-53 provide a comprehensive set of security capabilities needed to protect organizational systems and support the concept of defense in depth. Some of the security controls may address similar or overlapping security topics that are covered by other related controls. These controls have been designated as ORC in the tailoring criteria.

NIST SP 800-171A

2026-07-27T02:58:59Z

David: Created page with "{{Infobox document | title = NIST Special Publication 800-171A | subtitle = Assessing Security Requirements for Controlled Unclassified Information | authors = Ron Ross, Kelley Dempsey, Victoria Pillitteri | publisher = Computer Security Division, National Institute of Standards and Technology | pub_date = June 2018 | pages = 92 | coden = NSPUE2 | doi = https://doi.org/10.6028/NIST.SP.800-171A }} {{No..."

{{Infobox document
| title = NIST Special Publication 800-171A
| subtitle = Assessing Security Requirements for Controlled Unclassified Information
| authors = Ron Ross, Kelley Dempsey, Victoria Pillitteri
| publisher = Computer Security Division, National Institute of Standards and Technology
| pub_date = June 2018
| pages = 92
| coden = NSPUE2
| doi = https://doi.org/10.6028/NIST.SP.800-171A
}}

{{Notice|type=warning|'''WITHDRAWN NIST TECHNICAL SERIES PUBLICATION'''

The attached publication has been withdrawn (archived), and is provided solely for historical purposes. It may have been superseded by another publication (indicated below).

{| class="wikitable"
|-
! Series/Number || NIST SP 800-171A
|-
! Title || Assessing Security Requirements for Controlled Unclassified Information
|-
! Publication Date(s) || June 2018
|-
! Withdrawal Date || May 14, 2024
|-
! Withdrawal Note || NIST SP 800-171A is withdrawn and superseded in its entirety by NIST SP 800-171Ar3.
|}

'''Superseding Publication'''

{| class="wikitable"
|-
! Series/Number || NIST SP 800-171Ar3
|-
! Title || Assessing Security Requirements for Controlled Unclassified Information
|-
! Author(s) || Ron Ross; Victoria Pillitteri
|-
! Publication Date(s) || May 2024
|-
! URL/DOI || https://doi.org/10.6028/NIST.SP.800-171Ar3
|}

'''Additional Information'''

{| class="wikitable"
|-
! Contact || Computer Security Division (Information Technology Laboratory)
|-
! Related Information || https://csrc.nist.gov/pubs/sp/800/171/a/final
|}

Date updated: May 14, 2024
}}

== Front Matter ==

'''National Institute of Standards and Technology Special Publication 800-171A''' 
Natl. Inst. Stand. Technol. Spec. Publ. 800-171A, '''92 pages''' (June 2018)

CODEN: NSPUE2

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-171A

{{Notice|type=note|Certain commercial entities, equipment, or materials may be identified in this document to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.

There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts, practices, and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST.

Organizations are encouraged to review draft publications during the designated public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at https://csrc.nist.gov/publications.}}

'''Comments on this publication may be submitted to:'''

National Institute of Standards and Technology 
Attn: Computer Security Division, Information Technology Laboratory 
100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930 
Email: sec-cert@nist.gov

''All comments are subject to release under the Freedom of Information Act (FOIA).''

=== Authority ===

This publication has been developed by the National Institute of Standards and Technology to further its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 ''et seq.'', Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with requirements of the Office of Management and Budget (OMB) Circular A-130.

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

=== Reports on Computer Systems Technology ===

The NIST Information Technology Laboratory (ITL) promotes the United States economy and public welfare by providing technical leadership for the Nation's measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology.

ITL's responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security of other than national security-related information and protection of individuals' privacy in federal information systems. The Special Publication 800-series reports on ITL's research, guidelines, and outreach efforts in information systems security and its collaborative activities with industry, government, and academic organizations.

=== Abstract ===

The protection of Controlled Unclassified Information (CUI) resident in nonfederal systems and organizations is of paramount importance to federal agencies and can directly impact the ability of the federal government to successfully conduct its assigned missions and business operations. This publication provides federal and nonfederal organizations with assessment procedures and a methodology that can be employed to conduct assessments of the CUI security requirements in [[NIST Special Publication 800-171]], ''Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations''. The assessment procedures are flexible and can be customized to the needs of the organizations and the assessors conducting the assessments. Security assessments can be conducted as self-assessments; independent, third-party assessments; or government-sponsored assessments and can be applied with various degrees of rigor, based on customer-defined depth and coverage attributes. The findings and evidence produced during the security assessments can facilitate risk-based decisions by organizations related to the CUI requirements.

=== Keywords ===

Assessment; Assessment Method; Assessment Object; Assessment Procedure; Assurance; Basic Security Requirement; Controlled Unclassified Information; Coverage; CUI Registry; Depth; Derived Security Requirement; Executive Order 13556; FISMA; NIST Special Publication 800-53; NIST Special Publication 800-53A; Nonfederal Organization; Nonfederal System; Security Assessment; Security Control.

=== Acknowledgements ===

The authors gratefully acknowledge and appreciate the contributions from Jon Boyens, Devin Casey, Chris Enloe, Ned Goren, Gary Guissanie, Jody Jacobs, Jeff Marron, Vicki Michetti, Mark Riddle, Mary Thomas, Matt Scholl, Gary Stoneburner, Patricia Toth, and Patrick Viscuso whose thoughtful and constructive comments improved the quality, thoroughness, and usefulness of this publication. A special note of thanks goes to Jim Foti and Elizabeth Lennon for their superb administrative and technical editing support.

{{Notice|type=note|'''CAUTIONARY NOTE'''

The generalized assessment procedures described in this publication provide a framework and a starting point for developing specific procedures to assess the CUI security requirements in [[NIST Special Publication 800-171]]. The assessment procedures can be used to generate relevant evidence to determine if the security safeguards employed by organizations are implemented correctly, are operating as intended, and satisfy the CUI security requirements. Organizations have the flexibility to specialize the assessment procedures by selecting the specific assessment methods and the set of assessment objects to achieve the assessment objectives. There is no expectation that all assessment methods and all objects will be used for every assessment. There is also significant flexibility on the scope of the assessment and the degree of rigor applied during the assessment process. The assessment procedures and methods can be applied across a continuum of approaches—including self-assessments; independent, third-party assessments; and assessments conducted by sponsoring organizations (e.g., government agencies). Such approaches may be specified in contracts or in agreements by participating parties.}}

{{Notice|type=note|'''DEFINITION AND USAGE OF THE TERM INFORMATION SYSTEM'''

Unless otherwise specified by legislation, regulation, or governmentwide policy, the use of the term ''information system'' in this publication is replaced by the term ''system''. This change reflects a more broad-based and holistic definition of information systems that includes, for example: general purpose information systems; industrial and process control systems; cyber-physical systems; and individual devices that are part of the Internet of Things. As computing platforms and information technologies are increasingly deployed ubiquitously worldwide and systems and components are connected through wired and wireless networks, the susceptibility of Controlled Unclassified Information to loss or compromise grows—as does the potential for adverse consequences resulting from such occurrences.}}

{{Notice|type=note|'''OTHER RESOURCES TO SUPPORT ASSESSMENTS'''

NIST Special Publication 800-171A is a companion publication developed to support assessments of the CUI security requirements in [[NIST Special Publication 800-171]]. As such, it is the primary and authoritative source of guidance for organizations conducting such assessments. However, since it is recognized that the communities of interest affected by the CUI security requirements are broad and diverse, other supporting assessment guidance may be developed for those communities. For example, the NIST Manufacturing Extension Partnership (MEP) developed Handbook 162, ''NIST MEP Cybersecurity Self-Assessment Handbook for Assessing NIST SP 800-171 Security Requirements in Response to DFARS Cybersecurity Requirements''. This resource, along with other assessment resources that may be developed in the future, can complement the assessment procedures in NIST Special Publication 800-171A, thus helping sector-specific organizations generate the evidence needed to determine if the CUI security requirements have been satisfied.}}

== Table of Contents ==
__TOC__

* '''CHAPTER ONE''' Introduction ..... 1
** 1.1 Purpose and Applicability ..... 1
** 1.2 Target Audience ..... 2
** 1.3 Organization of this Special Publication ..... 2
* '''CHAPTER TWO''' The Fundamentals ..... 4
** 2.1 Assessment Procedures ..... 4
** 2.2 Assurance Cases ..... 6
* '''CHAPTER THREE''' The Procedures ..... 8
** 3.1 Access Control ..... 9
** 3.2 Awareness and Training ..... 19
** 3.3 Audit and Accountability ..... 21
** 3.4 Configuration Management ..... 26
** 3.5 Identification and Authentication ..... 31
** 3.6 Incident Response ..... 36
** 3.7 Maintenance ..... 38
** 3.8 Media Protection ..... 41
** 3.9 Personnel Security ..... 45
** 3.10 Physical Protection ..... 46
** 3.11 Risk Assessment ..... 49
** 3.12 Security Assessment ..... 51
** 3.13 System and Communications Protection ..... 53
** 3.14 System and Information Integrity ..... 61
* '''APPENDIX A''' References ..... 65
* '''APPENDIX B''' Glossary ..... 67
* '''APPENDIX C''' Acronyms ..... 75
* '''APPENDIX D''' Assessment Methods ..... 76

== Errata ==

This table contains changes that have been incorporated into Special Publication 800-171A. Errata updates can include corrections, clarifications, or other minor changes in the publication that are either ''editorial'' or ''substantive'' in nature.

{| class="wikitable"
! Date !! Type !! Revision !! Page
|-
| colspan="4" | (No errata entries listed in source document)
|}

== Chapter One: Introduction ==
''The need to assess CUI security requirements''

The protection of unclassified federal information in nonfederal systems and organizations is dependent on the federal government providing a process for identifying the different types of information that are used by federal agencies. Executive Order 13556 established a governmentwide Controlled Unclassified Information (CUI)<ref>''Controlled Unclassified Information'' is information the Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government, that a law, regulation, or governmentwide policy requires or permits an agency to handle using safeguarding or dissemination controls, excluding information that is classified under Executive Order 13526, ''Classified National Security Information'', December 29, 2009, or any predecessor or successor order, or the Atomic Energy Act of 1954, as amended.</ref> Program to standardize the way the executive branch handles unclassified information that requires protection. The implementing regulation for the CUI Program is 32 CFR part 2002, ''Controlled Unclassified Information''. Only federal information that requires safeguarding or dissemination controls pursuant to federal law, regulation, or governmentwide policy may be designated as CUI.<ref>The CUI Registry is the online repository for information, guidance, policy, and requirements on handling CUI.</ref> NIST Special Publication 800-171, ''Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations'', specifies the security requirements to ensure the confidentiality of CUI.

=== 1.1 Purpose and Applicability ===

The purpose of this publication is to provide procedures for assessing the CUI requirements in NIST Special Publication 800-171. Compliance with the security requirements is addressed in CUI guidance and the CUI Federal Acquisition Regulation (FAR)<ref>The CUI Executive Agent is actively engaged in the process of developing a FAR clause that will apply the requirements of the federal CUI regulation and NIST Special Publication 800-171 to contractors.</ref> or as supplemented by federal agencies (e.g., Department of Defense Federal Acquisition Regulation). Organizations can use the assessment procedures to generate evidence to support the assertion that the security requirements have been satisfied.

The assessment process is an information-gathering and evidence-producing activity to determine the effectiveness of the safeguards intended to meet the set of security requirements specified in NIST Special Publication 800-171. In this context, the information gathered and the evidence produced can be used by an organization to:

* Identify potential problems or shortfalls in the organization's security and risk management programs;
* Identify security weaknesses and deficiencies in its systems and in the environments in which those systems operate;
* Prioritize risk mitigation decisions and activities;
* Confirm that identified security weaknesses and deficiencies in the system and in the environment of operation have been addressed; and
* Support continuous monitoring activities and provide information security situational awareness.

The assessment procedures in this publication offer the flexibility to customize assessments based on organizational policies and requirements, known threat and vulnerability information, system and platform dependencies, operational considerations, and tolerance for risk.<ref>The term ''risk'' is used to mean risk to organizational operations (i.e., mission, functions, image, and reputation), organizational assets, individuals, other organizations, and the Nation. See NIST Special Publication 800-39 for additional information on organizational risk management and risk tolerance.</ref>

{{Notice|type=note|'''THE SCOPE OF CUI SECURITY REQUIREMENT ASSESSMENTS'''

For the CUI security requirements in NIST Special Publication 800-171, nonfederal organizations describe in a ''system security plan'', how the specified requirements are met or how organizations plan to meet the requirements. The plan describes the system boundary; the environment in which the system operates; how the requirements are implemented; and the relationships with or connections to other systems. The scope of the assessments conducted using the procedures described in this publication are guided and informed by the individual system security plans for the organizational systems processing, storing, or transmitting CUI. The assessments focus on the implementation and effectiveness of the safeguards intended to meet a fixed set of security requirements as defined in NIST Special Publication 800-171.}}

=== 1.2 Target Audience ===

This publication serves system, information security, and privacy<ref>References to privacy in this publication are made ''only'' in the context of where security and privacy considerations overlap—that is, in the security objective of ''confidentiality'', which generally supports privacy and the protection of personally identifiable information from unauthorized disclosure. NIST Internal Report 8062 provides additional information on the overlapping and complementary nature of security and privacy disciplines.</ref> professionals including individuals with:

* System development responsibilities (e.g., program managers, system developers, system owners, systems integrators, system security engineers);
* Information security assessment and monitoring responsibilities (e.g., system evaluators, assessors, independent verifiers/validators, auditors, analysts, system owners);
* Information security, privacy, risk management, governance, and oversight responsibilities (e.g., authorizing officials, chief information officers, chief privacy officers, chief information security officers, system managers, information security managers); and
* Information security implementation and operational responsibilities (e.g., system owners, information owners/stewards, mission and business owners, systems administrators, system security officers).

=== 1.3 Organization of this Special Publication ===

The remainder of this special publication is organized as follows:

* [[#Chapter Two: The Fundamentals|Chapter Two]] describes the fundamental concepts associated with assessments of CUI security requirements including assessment procedures, methods, objects, and assurance cases that can be created using evidence produced during assessments.
* [[#Chapter Three: The Procedures|Chapter Three]] provides a catalog of assessment procedures for the fourteen families of CUI security requirements in NIST Special Publication 800-171, including assessment objectives and potential assessment methods and objects for each procedure.
* Supporting appendices provide additional assessment-related information including general references; definitions and terms; acronyms; and a description of the assessment methods used in assessment procedures.

== Chapter Two: The Fundamentals ==
''Basic concepts for assessments of CUI security requirements''

The CUI security requirements in NIST Special Publication 800-171 are organized into fourteen families. Each family contains the requirements related to the general security topic of the family. Table 1 lists the CUI security requirement families addressed in this publication. The assessment procedures in [[#Chapter Three: The Procedures|Chapter Three]] are grouped by family designations to help ensure completeness and consistency of assessments.

'''TABLE 1: CUI SECURITY REQUIREMENT FAMILIES'''

{| class="wikitable"
! Family !! Family
|-
| Access Control || Media Protection
|-
| Awareness and Training || Personnel Security
|-
| Audit and Accountability || Physical Protection
|-
| Configuration Management || Risk Assessment
|-
| Identification and Authentication || Security Assessment
|-
| Incident Response || System and Communications Protection
|-
| Maintenance || System and Information Integrity
|}

=== 2.1 Assessment Procedures ===

An assessment procedure consists of an assessment ''objective'' and a set of potential assessment ''methods'' and assessment ''objects'' that can be used to conduct the assessment. Each assessment objective includes a determination statement related to the CUI security requirement that is the subject of the assessment. The determination statements are linked to the content of the CUI security requirements to ensure traceability of the assessment results to the requirements. The application of an assessment procedure to a security requirement produces assessment ''findings''. These findings reflect, or are subsequently used, to help determine if the security requirement has been satisfied.

Assessment objects identify the specific items being assessed and can include specifications, mechanisms, activities, and individuals. Specifications are the document-based artifacts (e.g., policies, procedures, security plans, security requirements, functional specifications, architectural designs) associated with a system. Mechanisms are the specific hardware, software, or firmware safeguards employed within a system. Activities are the protection-related actions supporting a system that involve people (e.g., conducting system backup operations, exercising a contingency plan, and monitoring network traffic). Individuals, or groups of individuals, are people applying the specifications, mechanisms, or activities described above.

The assessment methods define the nature and the extent of the assessor's actions. The methods include ''examine'', ''interview'', and ''test''. The examine method is the process of reviewing, inspecting, observing, studying, or analyzing assessment objects (i.e., specifications, mechanisms, activities). The purpose of the examine method is to facilitate understanding, achieve clarification, or obtain evidence. The interview method is the process of holding discussions with individuals or groups of individuals to facilitate understanding, achieve clarification, or obtain evidence. And finally, the test method is the process of exercising assessment objects (i.e., activities, mechanisms) under specified conditions to compare actual with expected behavior. In all three assessment methods, the results are used in making specific determinations called for in the determination statements and thereby achieving the objectives for the assessment procedure.

The assessment methods described above have associated attributes of ''depth'' and ''coverage'', which define the level of effort for the assessment. These attributes provide a means to define the rigor and scope of the assessment for the increased assurance of security requirements. A description of assessment methods and objects is provided in [[#Appendix D: Assessment Methods|Appendix D]].<ref>Additional information on assessment methods and objects and the attributes of depth and coverage is provided in NIST Special Publication 800-53A.</ref> Figure 1 illustrates an example of an assessment procedure for CUI security requirement 3.1.3 from NIST Special Publication 800-171.

'''FIGURE 1: ASSESSMENT PROCEDURE FOR CUI SECURITY REQUIREMENT'''

{{Requirement
|id=3.1.3
|title=Control the flow of CUI in accordance with approved authorizations.
|objectives=
* 3.1.3[a] information flow control policies are defined.
* 3.1.3[b] methods and enforcement mechanisms for controlling the flow of CUI are defined.
* 3.1.3[c] designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified.
* 3.1.3[d] authorizations for controlling the flow of CUI are defined.
* 3.1.3[e] approved authorizations for controlling the flow of CUI are enforced.
|examine=Access control policy; information flow control policies; procedures addressing information flow enforcement; system security plan; system design documentation; system configuration settings and associated documentation; list of information flow authorizations; system baseline configuration; system audit logs and records; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; system developers.
|test=Mechanisms implementing information flow enforcement policy.
}}

Organizations are not expected to employ ''all'' assessment methods and objects contained within the assessment procedures identified in this publication. Rather, organizations have the flexibility to determine the level of effort needed and the assurance required for an assessment (e.g., which assessment methods and assessment objects are deemed to be the most useful in obtaining the desired results). This determination is made based on how the organization can accomplish the assessment objectives in the most cost-effective manner and with sufficient confidence to support the determination that the CUI requirements have been satisfied.

=== 2.2 Assurance Cases ===

Building an effective assurance case for determining compliance to CUI security requirements is a process that involves compiling evidence from a variety of sources and conducting different types of activities during an assessment. An assurance case is a body of evidence organized into an argument demonstrating that some claim about a system is true. For assessments conducted using the procedures in this publication, that claim is ''compliance'' with the security requirements specified in NIST Special Publication 800-171. Assessors gather evidence during the assessment process to allow designated officials<ref>A ''designated official'' is an official, either internal or external to the nonfederal organization, with the responsibility to determine organizational compliance to CUI security requirements.</ref> to make objective determinations about compliance to the CUI security requirements. The evidence needed to make such determinations can be obtained from various sources including self-assessments, independent third-party assessments, or other types of assessments, depending on the needs of the organization establishing the requirements and the organization conducting the assessments.

For example, many technical security requirements are satisfied by security capabilities that are built in to commercial information technology products and systems. Product assessments are typically conducted by independent, third-party testing organizations.<ref>Examples include Common Criteria Testing Laboratories evaluating commercial IT products in accordance with ISO/IEC 15408 and Cryptographic Module Validation Program Testing Laboratories evaluating cryptographic modules in accordance with Federal Information Processing Standard (FIPS) 140.</ref> These assessments examine the security functions of products and established configuration settings. Assessments can also be conducted to demonstrate compliance to industry, national, or international security standards as well as developer and vendor claims. Since many information technology products are assessed by commercial testing organizations and then subsequently deployed in hundreds of thousands of systems, these types of assessments can be carried out at a greater level of depth and provide deeper insights into the security capabilities of the products.

Ultimately, evidence needed to determine compliance comes from the implementation of the selected safeguards to satisfy the CUI security requirements and from the assessments of that implementation. Assessors can build on previously developed materials that started with the specification of the organization's information security needs and is further developed during the design, development, and implementation of the system and system components. These materials, developed while implementing security throughout the life cycle of the system, provide the initial evidence for an assurance case.

Assessments can be conducted by systems developers, systems integrators, auditors, system owners, or the security staffs of organizations. The assessors or assessment teams bring together available information about the system such as the results from individual component product assessments. The assessors can conduct additional system-level assessments using the procedures and methods contained in this publication and based on the implementation information provided by the nonfederal organization in its system security plan. System assessments can be used to compile and evaluate the evidence needed by organizations to help determine the effectiveness of the safeguards implemented to protect CUI; the actions needed to mitigate security-related risks to the organization; and compliance to the CUI security requirements.

{{Notice|type=note|'''APPLICABLE CUI SECURITY REQUIREMENTS'''

The system security plan is used to describe how the organization meets or plans to meet the CUI security requirements. Any security requirements that are deemed ''non-applicable'' by the organization (e.g., no wireless capability in the system or the system component processing, storing, or transmitting CUI), are documented as such in the system security plan. Once the system security plan is completed, a security assessment plan can be developed using the assessment procedures described in Chapter Three and tailoring those procedures as needed. An assessment procedure is developed for every CUI security requirement that is applicable to the system, system component, or the organization. Conversely, security requirements that are deemed non-applicable in the system security plan are ''not'' assessed.}}

== Chapter Three: The Procedures ==
''Assessment procedures, methods, and objects for CUI security requirements''

This chapter provides assessment procedures for all CUI security requirements defined in NIST Special Publication 800-171. The assessment procedures are organized into fourteen families. Organizations conducting CUI security requirement assessments can build their assessment plans using the information provided in the generic assessment procedures—selecting the specific assessment methods and objects that meet the organization's needs. Organizations also have flexibility in defining the level of rigor and detail associated with the assessment based on the assurance requirements of the organization. [[#Appendix D: Assessment Methods|Appendix D]] provides additional information on the different levels of rigor and detail for assessments.

The assessment objective defined for each assessment procedure is achieved by applying the designated assessment methods to the selected assessment objects and compiling/producing the evidence necessary to make the determination associated with each assessment objective. Each determination statement contained within an assessment procedure produces one of the following findings: ''satisfied'' or ''other than satisfied''. A finding of "satisfied" indicates that for the security requirement addressed by the determination statement, the assessment information obtained (i.e., the evidence collected) indicates that the assessment objective has been met producing a fully acceptable result. A finding of "other than satisfied" indicates that for the security requirement addressed by the determination statement, the assessment findings obtained indicate potential anomalies that may need to be addressed by the organization. A finding of "other than satisfied" may also indicate that for reasons specified in the assessment report, the assessor was unable to obtain sufficient information to make the determination called for in the determination statement.

For assessment findings that are other than satisfied, organizations may define subcategories of findings indicating the severity or criticality of the weaknesses or deficiencies discovered and the potential adverse effects of those weaknesses or deficiencies on organizational missions and/or business functions. Defining such subcategories can help to establish priorities for needed risk mitigation actions.

{{Notice|type=note|'''CAUTIONARY NOTE'''

The content in this publication can be used for many different assessment-related purposes in determining organizational compliance to the CUI security requirements. The broad range of potential assessment methods and objects listed in this publication do not necessarily reflect, and should not be directly associated with, actual compliance or noncompliance. Rather, the selection of specific assessment methods and objects from the list provided, can help generate a picture of overall compliance with the CUI security requirements. There is no expectation about the number of methods or objects needed to determine compliance to the CUI security requirements. Moreover, the entire list of potential assessment objects should not be viewed as required artifacts needed to determine compliance to the requirements. Organizations have the flexibility to determine the specific methods and objects sufficient to obtain the needed evidence to support claims of compliance.}}

=== 3.1 Access Control ===

{{Requirement
|id=3.1.1
|title=Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems).
|objectives=
* 3.1.1[a] authorized users are identified.
* 3.1.1[b] processes acting on behalf of authorized users are identified.
* 3.1.1[c] devices (and other systems) authorized to connect to the system are identified.
* 3.1.1[d] system access is limited to authorized users.
* 3.1.1[e] system access is limited to processes acting on behalf of authorized users.
* 3.1.1[f] system access is limited to authorized devices (including other systems).
|examine=Access control policy; procedures addressing account management; system security plan; system design documentation; system configuration settings and associated documentation; list of active system accounts and the name of the individual associated with each account; notifications or records of recently transferred, separated, or terminated employees; list of conditions for group and role membership; list of recently disabled system accounts along with the name of the individual associated with each account; access authorization records; account management compliance reviews; system monitoring records; system audit logs and records; list of devices and systems authorized to connect to organizational systems; other relevant documents or records.
|interview=Personnel with account management responsibilities; system or network administrators; personnel with information security responsibilities.
|test=Organizational processes for managing system accounts; mechanisms for implementing account management.
}}

{{Requirement
|id=3.1.2
|title=Limit system access to the types of transactions and functions that authorized users are permitted to execute.
|objectives=
* 3.1.2[a] the types of transactions and functions that authorized users are permitted to execute are defined.
* 3.1.2[b] system access is limited to the defined types of transactions and functions for authorized users.
|examine=Access control policy; procedures addressing access enforcement; system security plan; system design documentation; list of approved authorizations including remote access authorizations; system audit logs and records; system configuration settings and associated documentation; other relevant documents or records.
|interview=Personnel with access enforcement responsibilities; system or network administrators; personnel with information security responsibilities; system developers.
|test=Mechanisms implementing access control policy.
}}

{{Requirement
|id=3.1.3
|title=Control the flow of CUI in accordance with approved authorizations.
|objectives=
* 3.1.3[a] information flow control policies are defined.
* 3.1.3[b] methods and enforcement mechanisms for controlling the flow of CUI are defined.
* 3.1.3[c] designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified.
* 3.1.3[d] authorizations for controlling the flow of CUI are defined.
* 3.1.3[e] approved authorizations for controlling the flow of CUI are enforced.
|examine=Access control policy; information flow control policies; procedures addressing information flow enforcement; system security plan; system design documentation; system configuration settings and associated documentation; list of information flow authorizations; system baseline configuration; system audit logs and records; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; system developers.
|test=Mechanisms implementing information flow enforcement policy.
}}

{{Requirement
|id=3.1.4
|title=Separate the duties of individuals to reduce the risk of malevolent activity without collusion.
|objectives=
* 3.1.4[a] the duties of individuals requiring separation are defined.
* 3.1.4[b] responsibilities for duties that require separation are assigned to separate individuals.
* 3.1.4[c] access privileges that enable individuals to exercise the duties that require separation are granted to separate individuals.
|examine=Access control policy; procedures addressing divisions of responsibility and separation of duties; system security plan; system configuration settings and associated documentation; list of divisions of responsibility and separation of duties; system access authorizations; system audit logs and records; other relevant documents or records.
|interview=Personnel with responsibilities for defining divisions of responsibility and separation of duties; personnel with information security responsibilities; system or network administrators.
|test=Mechanisms implementing separation of duties policy.
}}

{{Requirement
|id=3.1.5
|title=Employ the principle of least privilege, including for specific security functions and privileged accounts.
|objectives=
* 3.1.5[a] privileged accounts are identified.
* 3.1.5[b] access to privileged accounts is authorized in accordance with the principle of least privilege.
* 3.1.5[c] security functions are identified.
* 3.1.5[d] access to security functions is authorized in accordance with the principle of least privilege.
|examine=Access control policy; procedures addressing account management; system security plan; system design documentation; system configuration settings and associated documentation; list of active system accounts and the name of the individual associated with each account; list of conditions for group and role membership; notifications or records of recently transferred, separated, or terminated employees; list of recently disabled system accounts along with the name of the individual associated with each account; access authorization records; account management compliance reviews; system monitoring/audit records; procedures addressing least privilege; list of security functions (deployed in hardware, software, and firmware) and security-relevant information for which access is to be explicitly authorized; list of system-generated privileged accounts; list of system administration personnel; other relevant documents or records.
|interview=Personnel with account management responsibilities; system or network administrators; personnel with information security responsibilities; personnel with responsibilities for defining least privileges necessary to accomplish specified tasks.
|test=Organizational processes for managing system accounts; mechanisms for implementing account management; mechanisms implementing least privilege functions; mechanisms prohibiting privileged access to the system.
}}

{{Requirement
|id=3.1.6
|title=Use non-privileged accounts or roles when accessing nonsecurity functions.
|objectives=
* 3.1.6[a] nonsecurity functions are identified.
* 3.1.6[b] users are required to use non-privileged accounts or roles when accessing nonsecurity functions.
|examine=Access control policy; procedures addressing least privilege; system security plan; list of system-generated security functions assigned to system accounts or roles; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records.
|interview=Personnel with responsibilities for defining least privileges necessary to accomplish specified organizational tasks; personnel with information security responsibilities; system or network administrators.
|test=Mechanisms implementing least privilege functions.
}}

{{Requirement
|id=3.1.7
|title=Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.
|objectives=
* 3.1.7[a] privileged functions are defined.
* 3.1.7[b] non-privileged users are defined.
* 3.1.7[c] non-privileged users are prevented from executing privileged functions.
* 3.1.7[d] the execution of privileged functions is captured in audit logs.
|examine=Access control policy; procedures addressing least privilege; system security plan; system design documentation; list of privileged functions and associated user account assignments; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records.
|interview=Personnel with responsibilities for defining least privileges necessary to accomplish specified tasks; personnel with information security responsibilities; system developers.
|test=Mechanisms implementing least privilege functions for non-privileged users; mechanisms auditing the execution of privileged functions.
}}

{{Requirement
|id=3.1.8
|title=Limit unsuccessful logon attempts.
|objectives=
* 3.1.8[a] the means of limiting unsuccessful logon attempts is defined.
* 3.1.8[b] the defined means of limiting unsuccessful logon attempts is implemented.
|examine=Access control policy; procedures addressing unsuccessful logon attempts; system security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records.
|interview=Personnel with information security responsibilities; system developers; system or network administrators.
|test=Mechanisms implementing access control policy for unsuccessful logon attempts.
}}

{{Requirement
|id=3.1.9
|title=Provide privacy and security notices consistent with applicable CUI rules.
|objectives=
* 3.1.9[a] privacy and security notices required by CUI-specified rules are identified, consistent, and associated with the specific CUI category.
* 3.1.9[b] privacy and security notices are displayed.
|examine=Privacy and security policies, procedures addressing system use notification; documented approval of system use notification messages or banners; system audit logs and records; system design documentation; user acknowledgements of notification message or banner; system security plan; system use notification messages; system configuration settings and associated documentation; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; personnel with responsibility for providing legal advice; system developers.
|test=Mechanisms implementing system use notification.
}}

{{Requirement
|id=3.1.10
|title=Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity.
|objectives=
* 3.1.10[a] the period of inactivity after which the system initiates a session lock is defined.
* 3.1.10[b] access to the system and viewing of data is prevented by initiating a session lock after the defined period of inactivity.
* 3.1.10[c] previously visible information is concealed via a pattern-hiding display after the defined period of inactivity.
|examine=Access control policy; procedures addressing session lock; procedures addressing identification and authentication; system design documentation; system configuration settings and associated documentation; system security plan; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; system developers.
|test=Mechanisms implementing access control policy for session lock.
}}

{{Requirement
|id=3.1.11
|title=Terminate (automatically) a user session after a defined condition.
|objectives=
* 3.1.11[a] conditions requiring a user session to terminate are defined.
* 3.1.11[b] a user session is automatically terminated after any of the defined conditions occur.
|examine=Access control policy; procedures addressing session termination; system design documentation; system security plan; system configuration settings and associated documentation; list of conditions or trigger events requiring session disconnect; system audit logs and records; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; system developers.
|test=Mechanisms implementing user session termination.
}}

{{Requirement
|id=3.1.12
|title=Monitor and control remote access sessions.
|objectives=
* 3.1.12[a] remote access sessions are permitted.
* 3.1.12[b] the types of permitted remote access are identified.
* 3.1.12[c] remote access sessions are controlled.
* 3.1.12[d] remote access sessions are monitored.
|examine=Access control policy; procedures addressing remote access implementation and usage (including restrictions); configuration management plan; system security plan; system design documentation; system configuration settings and associated documentation; remote access authorizations; system audit logs and records; other relevant documents or records.
|interview=Personnel with responsibilities for managing remote access connections; system or network administrators; personnel with information security responsibilities.
|test=Remote access management capability for the system.
}}

{{Requirement
|id=3.1.13
|title=Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.
|objectives=
* 3.1.13[a] cryptographic mechanisms to protect the confidentiality of remote access sessions are identified.
* 3.1.13[b] cryptographic mechanisms to protect the confidentiality of remote access sessions are implemented.
|examine=Access control policy; procedures addressing remote access to the system; system security plan; system design documentation; system configuration settings and associated documentation; cryptographic mechanisms and associated configuration documentation; system audit logs and records; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; system developers.
|test=Cryptographic mechanisms protecting remote access sessions.
}}

{{Requirement
|id=3.1.14
|title=Route remote access via managed access control points.
|objectives=
* 3.1.14[a] managed access control points are identified and implemented.
* 3.1.14[b] remote access is routed through managed network access control points.
|examine=Access control policy; procedures addressing remote access to the system; system security plan; system design documentation; list of all managed network access control points; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities.
|test=Mechanisms routing all remote accesses through managed network access control points.
}}

{{Requirement
|id=3.1.15
|title=Authorize remote execution of privileged commands and remote access to security-relevant information.
|objectives=
* 3.1.15[a] privileged commands authorized for remote execution are identified.
* 3.1.15[b] security-relevant information authorized to be accessed remotely is identified.
* 3.1.15[c] the execution of the identified privileged commands via remote access is authorized.
* 3.1.15[d] access to the identified security-relevant information via remote access is authorized.
|examine=Access control policy; procedures addressing remote access to the system; system configuration settings and associated documentation; system security plan; system audit logs and records; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities.
|test=Mechanisms implementing remote access management.
}}

{{Requirement
|id=3.1.16
|title=Authorize wireless access prior to allowing such connections.
|objectives=
* 3.1.16[a] wireless access points are identified.
* 3.1.16[b] wireless access is authorized prior to allowing such connections.
|examine=Access control policy; configuration management plan; procedures addressing wireless access implementation and usage (including restrictions); system security plan; system design documentation; system configuration settings and associated documentation; wireless access authorizations; system audit logs and records; other relevant documents or records.
|interview=Personnel with responsibilities for managing wireless access connections; personnel with information security responsibilities.
|test=Wireless access management capability for the system.
}}

{{Requirement
|id=3.1.17
|title=Protect wireless access using authentication and encryption.
|objectives=
* 3.1.17[a] wireless access to the system is protected using authentication.
* 3.1.17[b] wireless access to the system is protected using encryption.
|examine=Access control policy; system design documentation; procedures addressing wireless implementation and usage (including restrictions); system security plan; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; system developers.
|test=Mechanisms implementing wireless access protections to the system.
}}

{{Requirement
|id=3.1.18
|title=Control connection of mobile devices.
|objectives=
* 3.1.18[a] mobile devices that process, store, or transmit CUI are identified.
* 3.1.18[b] mobile device connections are authorized.
* 3.1.18[c] mobile device connections are monitored and logged.
|examine=Access control policy; authorizations for mobile device connections to organizational systems; procedures addressing access control for mobile device usage (including restrictions); system design documentation; configuration management plan; system security plan; system audit logs and records; system configuration settings and associated documentation; other relevant documents or records.
|interview=Personnel using mobile devices to access organizational systems; system or network administrators; personnel with information security responsibilities.
|test=Access control capability authorizing mobile device connections to organizational systems.
}}

{{Requirement
|id=3.1.19
|title=Encrypt CUI on mobile devices and mobile computing platforms.
|objectives=
* 3.1.19[a] mobile devices and mobile computing platforms that process, store, or transmit CUI are identified.
* 3.1.19[b] encryption is employed to protect CUI on identified mobile devices and mobile computing platforms.
|examine=Access control policy; procedures addressing access control for mobile devices; system design documentation; system configuration settings and associated documentation; encryption mechanisms and associated configuration documentation; system security plan; system audit logs and records; other relevant documents or records.
|interview=Personnel with access control responsibilities for mobile devices; system or network administrators; personnel with information security responsibilities.
|test=Encryption mechanisms protecting confidentiality of information on mobile devices.
}}

{{Requirement
|id=3.1.20
|title=Verify and control/limit connections to and use of external systems.
|objectives=
* 3.1.20[a] connections to external systems are identified.
* 3.1.20[b] the use of external systems is identified.
* 3.1.20[c] connections to external systems are verified.
* 3.1.20[d] the use of external systems is verified.
* 3.1.20[e] connections to external systems are controlled/limited.
* 3.1.20[f] the use of external systems is controlled/limited.
|examine=Access control policy; procedures addressing the use of external systems; terms and conditions for external systems; system security plan; list of applications accessible from external systems; system configuration settings and associated documentation; system connection or processing agreements; account management documents; other relevant documents or records.
|interview=Personnel with responsibilities for defining terms and conditions for use of external systems to access organizational systems; system or network administrators; personnel with information security responsibilities.
|test=Mechanisms implementing terms and conditions on use of external systems.
}}

{{Requirement
|id=3.1.21
|title=Limit use of portable storage devices on external systems.
|objectives=
* 3.1.21[a] the use of portable storage devices containing CUI on external systems is identified and documented.
* 3.1.21[b] limits on the use of portable storage devices containing CUI on external systems are defined.
* 3.1.21[c] the use of portable storage devices containing CUI on external systems is limited as defined.
|examine=Access control policy; procedures addressing the use of external systems; system security plan; system configuration settings and associated documentation; system connection or processing agreements; account management documents; other relevant documents or records.
|interview=Personnel with responsibilities for restricting or prohibiting use of organization-controlled storage devices on external systems; system or network administrators; personnel with information security responsibilities.
|test=Mechanisms implementing restrictions on use of portable storage devices.
}}

{{Requirement
|id=3.1.22
|title=Control CUI posted or processed on publicly accessible systems.
|objectives=
* 3.1.22[a] individuals authorized to post or process information on publicly accessible systems are identified.
* 3.1.22[b] procedures to ensure CUI is not posted or processed on publicly accessible systems are identified.
* 3.1.22[c] a review process is in place prior to posting of any content to publicly accessible systems.
* 3.1.22[d] content on publicly accessible systems is reviewed to ensure that it does not include CUI.
* 3.1.22[e] mechanisms are in place to remove and address improper posting of CUI.
|examine=Access control policy; procedures addressing publicly accessible content; system security plan; list of users authorized to post publicly accessible content on organizational systems; training materials and/or records; records of publicly accessible information reviews; records of response to nonpublic information on public websites; system audit logs and records; security awareness training records; other relevant documents or records.
|interview=Personnel with responsibilities for managing publicly accessible information posted on organizational systems; personnel with information security responsibilities.
|test=Mechanisms implementing management of publicly accessible content.
}}

=== 3.2 Awareness and Training ===

{{Requirement
|id=3.2.1
|title=Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems.
|objectives=
* 3.2.1[a] security risks associated with organizational activities involving CUI are identified.
* 3.2.1[b] policies, standards, and procedures related to the security of the system are identified.
* 3.2.1[c] managers, systems administrators, and users of the system are made aware of the security risks associated with their activities.
* 3.2.1[d] managers, systems administrators, and users of the system are made aware of the applicable policies, standards, and procedures related to the security of the system.
|examine=Security awareness and training policy; procedures addressing security awareness training implementation; relevant codes of federal regulations; security awareness training curriculum; security awareness training materials; system security plan; training records; other relevant documents or records.
|interview=Personnel with responsibilities for security awareness training; personnel with information security responsibilities; personnel composing the general system user community; personnel with responsibilities for role-based awareness training.
|test=Mechanisms managing security awareness training; mechanisms managing role-based security training.
}}

{{Requirement
|id=3.2.2
|title=Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities.
|objectives=
* 3.2.2[a] information security-related duties, roles, and responsibilities are defined.
* 3.2.2[b] information security-related duties, roles, and responsibilities are assigned to designated personnel.
* 3.2.2[c] personnel are adequately trained to carry out their assigned information security-related duties, roles, and responsibilities.
|examine=Security awareness and training policy; procedures addressing security training implementation; codes of federal regulations; security training curriculum; security training materials; system security plan; training records; other relevant documents or records.
|interview=Personnel with responsibilities for role-based security training; personnel with assigned system security roles and responsibilities; personnel with responsibilities for security awareness training; personnel with information security responsibilities; personnel representing the general system user community.
|test=Mechanisms managing role-based security training; mechanisms managing security awareness training.
}}

{{Requirement
|id=3.2.3
|title=Provide security awareness training on recognizing and reporting potential indicators of insider threat.
|objectives=
* 3.2.3[a] potential indicators associated with insider threats are identified.
* 3.2.3[b] security awareness training on recognizing and reporting potential indicators of insider threat is provided to managers and employees.
|examine=Security awareness and training policy; procedures addressing security awareness training implementation; security awareness training curriculum; security awareness training materials; insider threat policy and procedures; system security plan; other relevant documents or records.
|interview=Personnel that participate in security awareness training; personnel with responsibilities for basic security awareness training; personnel with information security responsibilities.
|test=Mechanisms managing insider threat training.
}}

=== 3.3 Audit and Accountability ===

{{Requirement
|id=3.3.1
|title=Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.
|objectives=
* 3.3.1[a] audit logs needed (i.e., event types to be logged) to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity are specified.
* 3.3.1[b] the content of audit records needed to support monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity is defined.
* 3.3.1[c] audit records are created (generated).
* 3.3.1[d] audit records, once created, contain the defined content.
* 3.3.1[e] retention requirements for audit records are defined.
* 3.3.1[f] audit records are retained as defined.
|examine=Audit and accountability policy; procedures addressing auditable events; system security plan; system design documentation; system configuration settings and associated documentation; procedures addressing control of audit records; procedures addressing audit record generation; system audit logs and records; system auditable events; system incident reports; other relevant documents or records.
|interview=Personnel with audit and accountability responsibilities; personnel with information security responsibilities; personnel with audit review, analysis and reporting responsibilities; system or network administrators.
|test=Mechanisms implementing system audit logging.
}}

{{Requirement
|id=3.3.2
|title=Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions.
|objectives=
* 3.3.2[a] the content of the audit records needed to support the ability to uniquely trace users to their actions is defined.
* 3.3.2[b] audit records, once created, contain the defined content.
|examine=Audit and accountability policy; procedures addressing audit records and event types; system security plan; system design documentation; system configuration settings and associated documentation; procedures addressing audit record generation; procedures addressing audit review, analysis, and reporting; reports of audit findings; system audit logs and records; system events; system incident reports; other relevant documents or records.
|interview=Personnel with audit and accountability responsibilities; personnel with information security responsibilities; system or network administrators.
|test=Mechanisms implementing system audit logging.
}}

{{Requirement
|id=3.3.3
|title=Review and update logged events.
|objectives=
* 3.3.3[a] a process for determining when to review logged events is defined.
* 3.3.3[b] event types being logged are reviewed in accordance with the defined review process.
* 3.3.3[c] event types being logged are updated based on the review.
|examine=Audit and accountability policy; procedures addressing audit records and event types; system security plan; list of organization-defined event types to be logged; reviewed and updated records of logged event types; system audit logs and records; system incident reports; other relevant documents or records.
|interview=Personnel with audit and accountability responsibilities; personnel with information security responsibilities.
|test=Mechanisms supporting review and update of logged event types.
}}

{{Requirement
|id=3.3.4
|title=Alert in the event of an audit logging process failure.
|objectives=
* 3.3.4[a] personnel or roles to be alerted in the event of an audit logging process failure are identified.
* 3.3.4[b] types of audit logging process failures for which alert will be generated are defined.
* 3.3.4[c] identified personnel or roles are alerted in the event of an audit logging process failure.
|examine=Audit and accountability policy; procedures addressing response to audit logging processing failures; system design documentation; system security plan; system configuration settings and associated documentation; list of personnel to be notified in case of an audit logging processing failure; system incident reports; system audit logs and records; other relevant documents or records.
|interview=Personnel with audit and accountability responsibilities; personnel with information security responsibilities; system or network administrators; system developers.
|test=Mechanisms implementing system response to audit logging processing failures.
}}

{{Requirement
|id=3.3.5
|title=Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.
|objectives=
* 3.3.5[a] audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity are defined.
* 3.3.5[b] defined audit record review, analysis, and reporting processes are correlated.
|examine=Audit and accountability policy; procedures addressing audit record review, analysis, and reporting; system security plan; system design documentation; system configuration settings and associated documentation; procedures addressing investigation of and response to suspicious activities; system audit logs and records across different repositories; other relevant documents or records.
|interview=Personnel with audit record review, analysis, and reporting responsibilities; personnel with information security responsibilities.
|test=Mechanisms supporting analysis and correlation of audit records; mechanisms integrating audit review, analysis and reporting.
}}

{{Requirement
|id=3.3.6
|title=Provide audit record reduction and report generation to support on-demand analysis and reporting.
|objectives=
* 3.3.6[a] an audit record reduction capability that supports on-demand analysis is provided.
* 3.3.6[b] a report generation capability that supports on-demand reporting is provided.
|examine=Audit and accountability policy; procedures addressing audit record reduction and report generation; system design documentation; system security plan; system configuration settings and associated documentation; audit record reduction, review, analysis, and reporting tools; system audit logs and records; other relevant documents or records.
|interview=Personnel with audit record reduction and report generation responsibilities; personnel with information security responsibilities.
|test=Audit record reduction and report generation capability.
}}

{{Requirement
|id=3.3.7
|title=Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.
|objectives=
* 3.3.7[a] internal system clocks are used to generate time stamps for audit records.
* 3.3.7[b] an authoritative source with which to compare and synchronize internal system clocks is specified.
* 3.3.7[c] internal system clocks used to generate time stamps for audit records are compared to and synchronized with the specified authoritative time source.
|examine=Audit and accountability policy; procedures addressing time stamp generation; system design documentation; system security plan; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records.
|interview=Personnel with information security responsibilities; system or network administrators; system developers.
|test=Mechanisms implementing time stamp generation; mechanisms implementing internal information system clock synchronization.
}}

{{Requirement
|id=3.3.8
|title=Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
|objectives=
* 3.3.8[a] audit information is protected from unauthorized access.
* 3.3.8[b] audit information is protected from unauthorized modification.
* 3.3.8[c] audit information is protected from unauthorized deletion.
* 3.3.8[d] audit logging tools are protected from unauthorized access.
* 3.3.8[e] audit logging tools are protected from unauthorized modification.
* 3.3.8[f] audit logging tools are protected from unauthorized deletion.
|examine=Audit and accountability policy; access control policy and procedures; procedures addressing protection of audit information; system security plan; system design documentation; system configuration settings and associated documentation, system audit logs and records; audit logging tools; other relevant documents or records.
|interview=Personnel with audit and accountability responsibilities; personnel with information security responsibilities; system or network administrators; system developers.
|test=Mechanisms implementing audit information protection.
}}

{{Requirement
|id=3.3.9
|title=Limit management of audit logging functionality to a subset of privileged users.
|objectives=
* 3.3.9[a] a subset of privileged users granted access to manage audit logging functionality is defined.
* 3.3.9[b] management of audit logging functionality is limited to the defined subset of privileged users.
|examine=Audit and accountability policy; access control policy and procedures; procedures addressing protection of audit information; system security plan; system design documentation; system configuration settings and associated documentation; access authorizations; system-generated list of privileged users with access to management of audit logging functionality; access control list; system audit logs and records; other relevant documents or records.
|interview=Personnel with audit and accountability responsibilities; personnel with information security responsibilities; system or network administrators; system developers.
|test=Mechanisms managing access to audit logging functionality.
}}

=== 3.4 Configuration Management ===

{{Requirement
|id=3.4.1
|title=Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.
|objectives=
* 3.4.1[a] a baseline configuration is established.
* 3.4.1[b] the baseline configuration includes hardware, software, firmware, and documentation.
* 3.4.1[c] the baseline configuration is maintained (reviewed and updated) throughout the system development life cycle.
* 3.4.1[d] a system inventory is established.
* 3.4.1[e] the system inventory includes hardware, software, firmware, and documentation.
* 3.4.1[f] the inventory is maintained (reviewed and updated) throughout the system development life cycle.
|examine=Configuration management policy; procedures addressing the baseline configuration of the system; procedures addressing system inventory; system security plan; configuration management plan; system inventory records; inventory review and update records; enterprise architecture documentation; system design documentation; system architecture and configuration documentation; system configuration settings and associated documentation; change control records; system component installation records; system component removal records; other relevant documents or records.
|interview=Personnel with configuration management responsibilities; personnel with responsibilities for establishing the system inventory; personnel with responsibilities for updating the system inventory; personnel with information security responsibilities; system or network administrators.
|test=Organizational processes for managing baseline configurations; mechanisms supporting configuration control of the baseline configuration; organizational processes for developing and documenting an inventory of system components; organizational processes for updating inventory of system components; mechanisms supporting or implementing the system inventory; mechanisms implementing updating of the system inventory.
}}

{{Requirement
|id=3.4.2
|title=Establish and enforce security configuration settings for information technology products employed in organizational systems.
|objectives=
* 3.4.2[a] security configuration settings for information technology products employed in the system are established and included in the baseline configuration.
* 3.4.2[b] security configuration settings for information technology products employed in the system are enforced.
|examine=Configuration management policy; baseline configuration; procedures addressing configuration settings for the system; configuration management plan; system security plan; system design documentation; system configuration settings and associated documentation; security configuration checklists; evidence supporting approved deviations from established configuration settings; change control records; system audit logs and records; other relevant documents or records.
|interview=Personnel with security configuration management responsibilities; personnel with information security responsibilities; system or network administrators.
|test=Organizational processes for managing configuration settings; mechanisms that implement, monitor, and/or control system configuration settings; mechanisms that identify and/or document deviations from established configuration settings; processes for managing baseline configurations; mechanisms supporting configuration control of baseline configurations.
}}

{{Requirement
|id=3.4.3
|title=Track, review, approve or disapprove, and log changes to organizational systems.
|objectives=
* 3.4.3[a] changes to the system are tracked.
* 3.4.3[b] changes to the system are reviewed.
* 3.4.3[c] changes to the system are approved or disapproved.
* 3.4.3[d] changes to the system are logged.
|examine=Configuration management policy; procedures addressing system configuration change control; configuration management plan; system architecture and configuration documentation; system security plan; change control records; system audit logs and records; change control audit and review reports; agenda/minutes from configuration change control oversight meetings; other relevant documents or records.
|interview=Personnel with configuration change control responsibilities; personnel with information security responsibilities; system or network administrators; members of change control board or similar.
|test=Organizational processes for configuration change control; mechanisms that implement configuration change control.
}}

{{Requirement
|id=3.4.4
|title=Analyze the security impact of changes prior to implementation.
|objectives=Determine if the security impact of changes to the system is analyzed prior to implementation.
|examine=Configuration management policy; procedures addressing security impact analysis for system changes; configuration management plan; security impact analysis documentation; system security plan; analysis tools and associated outputs; change control records; system audit logs and records; other relevant documents or records.
|interview=Personnel with responsibility for conducting security impact analysis; personnel with information security responsibilities; system or network administrators.
|test=Organizational processes for security impact analysis.
}}

{{Requirement
|id=3.4.5
|title=Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.
|objectives=
* 3.4.5[a] physical access restrictions associated with changes to the system are defined.
* 3.4.5[b] physical access restrictions associated with changes to the system are documented.
* 3.4.5[c] physical access restrictions associated with changes to the system are approved.
* 3.4.5[d] physical access restrictions associated with changes to the system are enforced.
* 3.4.5[e] logical access restrictions associated with changes to the system are defined.
* 3.4.5[f] logical access restrictions associated with changes to the system are documented.
* 3.4.5[g] logical access restrictions associated with changes to the system are approved.
* 3.4.5[h] logical access restrictions associated with changes to the system are enforced.
|examine=Configuration management policy; procedures addressing access restrictions for changes to the system; system security plan; configuration management plan; system design documentation; system architecture and configuration documentation; system configuration settings and associated documentation; logical access approvals; physical access approvals; access credentials; change control records; system audit logs and records; other relevant documents or records.
|interview=Personnel with logical access control responsibilities; personnel with physical access control responsibilities; personnel with information security responsibilities; system or network administrators.
|test=Organizational processes for managing access restrictions associated with changes to the system; mechanisms supporting, implementing, and enforcing access restrictions associated with changes to the system.
}}

{{Requirement
|id=3.4.6
|title=Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.
|objectives=
* 3.4.6[a] essential system capabilities are defined based on the principle of least functionality.
* 3.4.6[b] the system is configured to provide only the defined essential capabilities.
|examine=Configuration management policy; configuration management plan; procedures addressing least functionality in the system; system security plan; system design documentation; system configuration settings and associated documentation; security configuration checklists; other relevant documents or records.
|interview=Personnel with security configuration management responsibilities; personnel with information security responsibilities; system or network administrators.
|test=Organizational processes prohibiting or restricting functions, ports, protocols, or services; mechanisms implementing restrictions or prohibition of functions, ports, protocols, or services.
}}

{{Requirement
|id=3.4.7
|title=Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.
|objectives=
* 3.4.7[a] essential programs are defined.
* 3.4.7[b] the use of nonessential programs is defined.
* 3.4.7[c] the use of nonessential programs is restricted, disabled, or prevented as defined.
* 3.4.7[d] essential functions are defined.
* 3.4.7[e] the use of nonessential functions is defined.
* 3.4.7[f] the use of nonessential functions is restricted, disabled, or prevented as defined.
* 3.4.7[g] essential ports are defined.
* 3.4.7[h] the use of nonessential ports is defined.
* 3.4.7[i] the use of nonessential ports is restricted, disabled, or prevented as defined.
* 3.4.7[j] essential protocols are defined.
* 3.4.7[k] the use of nonessential protocols is defined.
* 3.4.7[l] the use of nonessential protocols is restricted, disabled, or prevented as defined.
* 3.4.7[m] essential services are defined.
* 3.4.7[n] the use of nonessential services is defined.
* 3.4.7[o] the use of nonessential services is restricted, disabled, or prevented as defined.
|examine=Configuration management policy; procedures addressing least functionality in the system; configuration management plan; system security plan; system design documentation; security configuration checklists; system configuration settings and associated documentation; specifications for preventing software program execution; documented reviews of programs, functions, ports, protocols, and/or services; change control records; system audit logs and records; other relevant documents or records.
|interview=Personnel with responsibilities for reviewing programs, functions, ports, protocols, and services on the system; personnel with information security responsibilities; system or network administrators; system developers.
|test=Organizational processes for reviewing and disabling nonessential programs, functions, ports, protocols, or services; mechanisms implementing review and handling of nonessential programs, functions, ports, protocols, or services; organizational processes preventing program execution on the system; organizational processes for software program usage and restrictions; mechanisms supporting or implementing software program usage and restrictions; mechanisms preventing program execution on the system.
}}

{{Requirement
|id=3.4.8
|title=Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.
|objectives=
* 3.4.8[a] a policy specifying whether whitelisting or blacklisting is to be implemented is specified.
* 3.4.8[b] the software allowed to execute under whitelisting or denied use under blacklisting is specified.
* 3.4.8[c] whitelisting to allow the execution of authorized software or blacklisting to prevent the use of unauthorized software is implemented as specified.
|examine=Configuration management policy; procedures addressing least functionality in the system; system security plan; configuration management plan; system design documentation; system configuration settings and associated documentation; list of software programs not authorized to execute on the system; list of software programs authorized to execute on the system; security configuration checklists; review and update records associated with list of authorized or unauthorized software programs; change control records; system audit logs and records; other relevant documents or records.
|interview=Personnel with responsibilities for identifying software authorized or not authorized to execute on the system; personnel with information security responsibilities; system or network administrators.
|test=Organizational process for identifying, reviewing, and updating programs authorized or not authorized to execute on the system; process for implementing blacklisting or whitelisting; mechanisms supporting or implementing blacklisting or whitelisting.
}}

{{Requirement
|id=3.4.9
|title=Control and monitor user-installed software.
|objectives=
* 3.4.9[a] a policy for controlling the installation of software by users is established.
* 3.4.9[b] installation of software by users is controlled based on the established policy.
* 3.4.9[c] installation of software by users is monitored.
|examine=Configuration management policy; procedures addressing user installed software; configuration management plan; system security plan; system design documentation; system configuration settings and associated documentation; list of rules governing user-installed software; system monitoring records; system audit logs and records; continuous monitoring strategy; other relevant documents or records.
|interview=Personnel with responsibilities for governing user-installed software; personnel operating, using, or maintaining the system; personnel monitoring compliance with user-installed software policy; personnel with information security responsibilities; system or network administrators.
|test=Organizational processes governing user-installed software on the system; mechanisms enforcing rules or methods for governing the installation of software by users; mechanisms monitoring policy compliance.
}}

=== 3.5 Identification and Authentication ===

{{Requirement
|id=3.5.1
|title=Identify system users, processes acting on behalf of users, and devices.
|objectives=
* 3.5.1[a] system users are identified.
* 3.5.1[b] processes acting on behalf of users are identified.
* 3.5.1[c] devices accessing the system are identified.
|examine=Identification and authentication policy; procedures addressing user identification and authentication; system security plan, system design documentation; system configuration settings and associated documentation; system audit logs and records; list of system accounts; other relevant documents or records.
|interview=Personnel with system operations responsibilities; personnel with information security responsibilities; system or network administrators; personnel with account management responsibilities; system developers.
|test=Organizational processes for uniquely identifying and authenticating users; mechanisms supporting or implementing identification and authentication capability.
}}

{{Requirement
|id=3.5.2
|title=Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems.
|objectives=
* 3.5.2[a] the identity of each user is authenticated or verified as a prerequisite to system access.
* 3.5.2[b] the identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access.
* 3.5.2[c] the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access.
|examine=Identification and authentication policy; system security plan; procedures addressing authenticator management; procedures addressing user identification and authentication; system design documentation; list of system authenticator types; system configuration settings and associated documentation; change control records associated with managing system authenticators; system audit logs and records; other relevant documents or records.
|interview=Personnel with authenticator management responsibilities; personnel with information security responsibilities; system or network administrators.
|test=Mechanisms supporting or implementing authenticator management capability.
}}

{{Requirement
|id=3.5.3
|title=Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
|objectives=
* 3.5.3[a] privileged accounts are identified.
* 3.5.3[b] multifactor authentication is implemented for local access to privileged accounts.
* 3.5.3[c] multifactor authentication is implemented for network access to privileged accounts.
* 3.5.3[d] multifactor authentication is implemented for network access to non-privileged accounts.
|examine=Identification and authentication policy; procedures addressing user identification and authentication; system security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; list of system accounts; other relevant documents or records.
|interview=Personnel with system operations responsibilities; personnel with account management responsibilities; personnel with information security responsibilities; system or network administrators; system developers.
|test=Mechanisms supporting or implementing multifactor authentication capability.
}}

{{Requirement
|id=3.5.4
|title=Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.
|objectives=Determine if replay-resistant authentication mechanisms are implemented for network account access to privileged and non-privileged accounts.
|examine=Identification and authentication policy; procedures addressing user identification and authentication; system security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; list of privileged system accounts; other relevant documents or records.
|interview=Personnel with system operations responsibilities; personnel with account management responsibilities; personnel with information security responsibilities; system or network administrators; system developers.
|test=Mechanisms supporting or implementing identification and authentication capability or replay resistant authentication mechanisms.
}}

{{Requirement
|id=3.5.5
|title=Prevent reuse of identifiers for a defined period.
|objectives=
* 3.5.5[a] a period within which identifiers cannot be reused is defined.
* 3.5.5[b] reuse of identifiers is prevented within the defined period.
|examine=Identification and authentication policy; procedures addressing identifier management; procedures addressing account management; system security plan; system design documentation; system configuration settings and associated documentation; list of system accounts; list of identifiers generated from physical access control devices; other relevant documents or records.
|interview=Personnel with identifier management responsibilities; personnel with information security responsibilities; system or network administrators; system developers.
|test=Mechanisms supporting or implementing identifier management.
}}

{{Requirement
|id=3.5.6
|title=Disable identifiers after a defined period of inactivity.
|objectives=
* 3.5.6[a] a period of inactivity after which an identifier is disabled is defined.
* 3.5.6[b] identifiers are disabled after the defined period of inactivity.
|examine=Identification and authentication policy; procedures addressing identifier management; procedures addressing account management; system security plan; system design documentation; system configuration settings and associated documentation; list of system accounts; list of identifiers generated from physical access control devices; other relevant documents or records.
|interview=Personnel with identifier management responsibilities; personnel with information security responsibilities; system or network administrators; system developers.
|test=Mechanisms supporting or implementing identifier management.
}}

{{Requirement
|id=3.5.7
|title=Enforce a minimum password complexity and change of characters when new passwords are created.
|objectives=
* 3.5.7[a] password complexity requirements are defined.
* 3.5.7[b] password change of character requirements are defined.
* 3.5.7[c] minimum password complexity requirements as defined are enforced when new passwords are created.
* 3.5.7[d] minimum password change of character requirements as defined are enforced when new passwords are created.
|examine=Identification and authentication policy; password policy; procedures addressing authenticator management; system security plan; system configuration settings and associated documentation; system design documentation; password configurations and associated documentation; other relevant documents or records.
|interview=Personnel with authenticator management responsibilities; personnel with information security responsibilities; system or network administrators; system developers.
|test=Mechanisms supporting or implementing password-based authenticator management capability.
}}

{{Requirement
|id=3.5.8
|title=Prohibit password reuse for a specified number of generations.
|objectives=
* 3.5.8[a] the number of generations during which a password cannot be reused is specified.
* 3.5.8[b] reuse of passwords is prohibited during the specified number of generations.
|examine=Identification and authentication policy; password policy; procedures addressing authenticator management; system security plan; system design documentation; system configuration settings and associated documentation; password configurations and associated documentation; other relevant documents or records.
|interview=Personnel with authenticator management responsibilities; personnel with information security responsibilities; system or network administrators; system developers.
|test=Mechanisms supporting or implementing password-based authenticator management capability.
}}

{{Requirement
|id=3.5.9
|title=Allow temporary password use for system logons with an immediate change to a permanent password.
|objectives=Determine if an immediate change to a permanent password is required when a temporary password is used for system logon.
|examine=Identification and authentication policy; password policy; procedures addressing authenticator management; system security plan; system configuration settings and associated documentation; system design documentation; password configurations and associated documentation; other relevant documents or records.
|interview=Personnel with authenticator management responsibilities; personnel with information security responsibilities; system or network administrators; system developers.
|test=Mechanisms supporting or implementing password-based authenticator management capability.
}}

{{Requirement
|id=3.5.10
|title=Store and transmit only cryptographically-protected passwords.
|objectives=
* 3.5.10[a] passwords are cryptographically protected in storage.
* 3.5.10[b] passwords are cryptographically protected in transit.
|examine=Identification and authentication policy; password policy; procedures addressing authenticator management; system security plan; system configuration settings and associated documentation; system design documentation; password configurations and associated documentation; other relevant documents or records.
|interview=Personnel with authenticator management responsibilities; personnel with information security responsibilities; system or network administrators; system developers.
|test=Mechanisms supporting or implementing password-based authenticator management capability.
}}

{{Requirement
|id=3.5.11
|title=Obscure feedback of authentication information.
|objectives=Determine if authentication information is obscured during the authentication process.
|examine=Identification and authentication policy; procedures addressing authenticator feedback; system security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records.
|interview=Personnel with information security responsibilities; system or network administrators; system developers.
|test=Mechanisms supporting or implementing the obscuring of feedback of authentication information during authentication.
}}

=== 3.6 Incident Response ===

{{Requirement
|id=3.6.1
|title=Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.
|objectives=
* 3.6.1[a] an operational incident-handling capability is established.
* 3.6.1[b] the operational incident-handling capability includes preparation.
* 3.6.1[c] the operational incident-handling capability includes detection.
* 3.6.1[d] the operational incident-handling capability includes analysis.
* 3.6.1[e] the operational incident-handling capability includes containment.
* 3.6.1[f] the operational incident-handling capability includes recovery.
* 3.6.1[g] the operational incident-handling capability includes user response activities.
|examine=Incident response policy; contingency planning policy; procedures addressing incident handling; procedures addressing incident response assistance; incident response plan; contingency plan; system security plan; procedures addressing incident response training; incident response training curriculum; incident response training materials; incident response training records; other relevant documents or records.
|interview=Personnel with incident handling responsibilities; personnel with contingency planning responsibilities; personnel with incident response training and operational responsibilities; personnel with incident response assistance and support responsibilities; personnel with access to incident response support and assistance capability; personnel with information security responsibilities.
|test=Incident-handling capability for the organization; organizational processes for incident response assistance; mechanisms supporting or implementing incident response assistance.
}}

{{Requirement
|id=3.6.2
|title=Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.
|objectives=
* 3.6.2[a] incidents are tracked.
* 3.6.2[b] incidents are documented.
* 3.6.2[c] authorities to whom incidents are to be reported are identified.
* 3.6.2[d] organizational officials to whom incidents are to be reported are identified.
* 3.6.2[e] identified authorities are notified of incidents.
* 3.6.2[f] identified organizational officials are notified of incidents.
|examine=Incident response policy; procedures addressing incident monitoring; incident response records and documentation; procedures addressing incident reporting; incident reporting records and documentation; incident response plan; system security plan; other relevant documents or records.
|interview=Personnel with incident monitoring responsibilities; personnel with incident reporting responsibilities; personnel who have or should have reported incidents; personnel (authorities) to whom incident information is to be reported; personnel with information security responsibilities.
|test=Incident monitoring capability for the organization; mechanisms supporting or implementing tracking and documenting of system security incidents; organizational processes for incident reporting; mechanisms supporting or implementing incident reporting.
}}

{{Requirement
|id=3.6.3
|title=Test the organizational incident response capability.
|objectives=Determine if the incident response capability is tested.
|examine=Incident response policy; contingency planning policy; procedures addressing incident response testing; procedures addressing contingency plan testing; incident response testing material; incident response test results; incident response test plan; incident response plan; contingency plan; system security plan; other relevant documents or records.
|interview=Personnel with incident response testing responsibilities; personnel with information security responsibilities; personnel with responsibilities for testing plans related to incident response.
|test=Mechanisms and processes for incident response.
}}

=== 3.7 Maintenance ===

{{Requirement
|id=3.7.1
|title=Perform maintenance on organizational systems.
|objectives=Determine if system maintenance is performed.
|examine=System maintenance policy; procedures addressing controlled system maintenance; maintenance records; manufacturer or vendor maintenance specifications; equipment sanitization records; media sanitization records; system security plan; other relevant documents or records.
|interview=Personnel with system maintenance responsibilities; personnel with information security responsibilities; personnel responsible for media sanitization; system or network administrators.
|test=Organizational processes for scheduling, performing, documenting, reviewing, approving, and monitoring maintenance and repairs for systems; organizational processes for sanitizing system components; mechanisms supporting or implementing controlled maintenance; mechanisms implementing sanitization of system components.
}}

{{Requirement
|id=3.7.2
|title=Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance.
|objectives=
* 3.7.2[a] tools used to conduct system maintenance are controlled.
* 3.7.2[b] techniques used to conduct system maintenance are controlled.
* 3.7.2[c] mechanisms used to conduct system maintenance are controlled.
* 3.7.2[d] personnel used to conduct system maintenance are controlled.
|examine=System maintenance policy; procedures addressing system maintenance tools and media; maintenance records; system maintenance tools and associated documentation; maintenance tool inspection records; system security plan; other relevant documents or records.
|interview=Personnel with system maintenance responsibilities; personnel with information security responsibilities.
|test=Organizational processes for approving, controlling, and monitoring maintenance tools; mechanisms supporting or implementing approval, control, and monitoring of maintenance tools; organizational processes for inspecting maintenance tools; mechanisms supporting or implementing inspection of maintenance tools; organizational process for inspecting media for malicious code; mechanisms supporting or implementing inspection of media used for maintenance.
}}

{{Requirement
|id=3.7.3
|title=Ensure equipment removed for off-site maintenance is sanitized of any CUI.
|objectives=Determine if equipment to be removed from organizational spaces for off-site maintenance is sanitized of any CUI.
|examine=System maintenance policy; procedures addressing controlled system maintenance; maintenance records; manufacturer or vendor maintenance specifications; equipment sanitization records; media sanitization records; system security plan; other relevant documents or records.
|interview=Personnel with system maintenance responsibilities; personnel with information security responsibilities; personnel responsible for media sanitization; system or network administrators.
|test=Organizational processes for scheduling, performing, documenting, reviewing, approving, and monitoring maintenance and repairs for systems; organizational processes for sanitizing system components; mechanisms supporting or implementing controlled maintenance; mechanisms implementing sanitization of system components.
}}

{{Requirement
|id=3.7.4
|title=Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems.
|objectives=Determine if media containing diagnostic and test programs are checked for malicious code before being used in organizational systems that process, store, or transmit CUI.
|examine=System maintenance policy; procedures addressing system maintenance tools; system maintenance tools and associated documentation; maintenance records; system security plan; other relevant documents or records.
|interview=Personnel with system maintenance responsibilities; personnel with information security responsibilities.
|test=Organizational process for inspecting media for malicious code; mechanisms supporting or implementing inspection of media used for maintenance.
}}

{{Requirement
|id=3.7.5
|title=Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete.
|objectives=
* 3.7.5[a] multifactor authentication is used to establish nonlocal maintenance sessions via external network connections.
* 3.7.5[b] nonlocal maintenance sessions established via external network connections are terminated when nonlocal maintenance is complete.
|examine=System maintenance policy; procedures addressing nonlocal system maintenance; system security plan; system design documentation; system configuration settings and associated documentation; maintenance records; diagnostic records; other relevant documents or records.
|interview=Personnel with system maintenance responsibilities; personnel with information security responsibilities; system or network administrators.
|test=Organizational processes for managing nonlocal maintenance; mechanisms implementing, supporting, and managing nonlocal maintenance; mechanisms for strong authentication of nonlocal maintenance diagnostic sessions; mechanisms for terminating nonlocal maintenance sessions and network connections.
}}

{{Requirement
|id=3.7.6
|title=Supervise the maintenance activities of maintenance personnel without required access authorization.
|objectives=Determine if maintenance personnel without required access authorization are supervised during maintenance activities.
|examine=System maintenance policy; procedures addressing maintenance personnel; service provider contracts; service-level agreements; list of authorized personnel; maintenance records; access control records; system security plan; other relevant documents or records.
|interview=Personnel with system maintenance responsibilities; personnel with information security responsibilities.
|test=Organizational processes for authorizing and managing maintenance personnel; mechanisms supporting or implementing authorization of maintenance personnel.
}}

=== 3.8 Media Protection ===

{{Requirement
|id=3.8.1
|title=Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital.
|objectives=
* 3.8.1[a] paper media containing CUI is physically controlled.
* 3.8.1[b] digital media containing CUI is physically controlled.
* 3.8.1[c] paper media containing CUI is securely stored.
* 3.8.1[d] digital media containing CUI is securely stored.
|examine=System media protection policy; procedures addressing media storage; procedures addressing media access restrictions; access control policy and procedures; physical and environmental protection policy and procedures; system security plan; media storage facilities; access control records; other relevant documents or records.
|interview=Personnel with system media protection responsibilities; personnel with information security responsibilities; system or network administrators.
|test=Organizational processes for restricting information media; mechanisms supporting or implementing media access restrictions.
}}

{{Requirement
|id=3.8.2
|title=Limit access to CUI on system media to authorized users.
|objectives=Determine if access to CUI on system media is limited to authorized users.
|examine=System media protection policy; procedures addressing media storage; physical and environmental protection policy and procedures; access control policy and procedures; system security plan; system media; designated controlled areas; other relevant documents or records.
|interview=Personnel with system media protection and storage responsibilities; personnel with information security responsibilities.
|test=Organizational processes for storing media; mechanisms supporting or implementing secure media storage and media protection.
}}

{{Requirement
|id=3.8.3
|title=Sanitize or destroy system media containing CUI before disposal or release for reuse.
|objectives=
* 3.8.3[a] system media containing CUI is sanitized or destroyed before disposal.
* 3.8.3[b] system media containing CUI is sanitized before it is released for reuse.
|examine=System media protection policy; procedures addressing media sanitization and disposal; applicable standards and policies addressing media sanitization; system security plan; media sanitization records; system audit logs and records; system design documentation; system configuration settings and associated documentation; other relevant documents or records.
|interview=Personnel with media sanitization responsibilities; personnel with information security responsibilities; system or network administrators.
|test=Organizational processes for media sanitization; mechanisms supporting or implementing media sanitization.
}}

{{Requirement
|id=3.8.4
|title=Mark media with necessary CUI markings and distribution limitations.
|objectives=
* 3.8.4[a] media containing CUI is marked with applicable CUI markings.
* 3.8.4[b] media containing CUI is marked with distribution limitations.
|examine=System media protection policy; procedures addressing media marking; physical and environmental protection policy and procedures; system security plan; list of system media marking security attributes; designated controlled areas; other relevant documents or records.
|interview=Personnel with system media protection and marking responsibilities; personnel with information security responsibilities.
|test=Organizational processes for marking information media; mechanisms supporting or implementing media marking.
}}

{{Requirement
|id=3.8.5
|title=Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas.
|objectives=
* 3.8.5[a] access to media containing CUI is controlled.
* 3.8.5[b] accountability for media containing CUI is maintained during transport outside of controlled areas.
|examine=System media protection policy; procedures addressing media storage; physical and environmental protection policy and procedures; access control policy and procedures; system security plan; system media; designated controlled areas; other relevant documents or records.
|interview=Personnel with system media protection and storage responsibilities; personnel with information security responsibilities; system or network administrators.
|test=Organizational processes for storing media; mechanisms supporting or implementing media storage and media protection.
}}

{{Requirement
|id=3.8.6
|title=Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards.
|objectives=Determine if the confidentiality of CUI stored on digital media is protected during transport using cryptographic mechanisms or alternative physical safeguards.
|examine=System media protection policy; procedures addressing media transport; system design documentation; system security plan; system configuration settings and associated documentation; system media transport records; system audit logs and records; other relevant documents or records.
|interview=Personnel with system media transport responsibilities; personnel with information security responsibilities.
|test=Cryptographic mechanisms protecting information on digital media during transportation outside controlled areas.
}}

{{Requirement
|id=3.8.7
|title=Control the use of removable media on system components.
|objectives=Determine if the use of removable media on system components is controlled.
|examine=System media protection policy; system use policy; procedures addressing media usage restrictions; system security plan; rules of behavior; system design documentation; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records.
|interview=Personnel with system media use responsibilities; personnel with information security responsibilities; system or network administrators.
|test=Organizational processes for media use; mechanisms restricting or prohibiting use of system media on systems or system components.
}}

{{Requirement
|id=3.8.8
|title=Prohibit the use of portable storage devices when such devices have no identifiable owner.
|objectives=Determine if the use of portable storage devices is prohibited when such devices have no identifiable owner.
|examine=System media protection policy; system use policy; procedures addressing media usage restrictions; system security plan; rules of behavior; system configuration settings and associated documentation; system design documentation; system audit logs and records; other relevant documents or records.
|interview=Personnel with system media use responsibilities; personnel with information security responsibilities; system or network administrators.
|test=Organizational processes for media use; mechanisms prohibiting use of media on systems or system components.
}}

{{Requirement
|id=3.8.9
|title=Protect the confidentiality of backup CUI at storage locations.
|objectives=Determine if the confidentiality of backup CUI is protected at storage locations.
|examine=Procedures addressing system backup; system configuration settings and associated documentation; security plan; backup storage locations; system backup logs or records; other relevant documents or records.
|interview=Personnel with system backup responsibilities; personnel with information security responsibilities.
|test=Organizational processes for conducting system backups; mechanisms supporting or implementing system backups.
}}

=== 3.9 Personnel Security ===

{{Requirement
|id=3.9.1
|title=Screen individuals prior to authorizing access to organizational systems containing CUI.
|objectives=Determine if individuals are screened prior to authorizing access to organizational systems containing CUI.
|examine=Personnel security policy; procedures addressing personnel screening; records of screened personnel; system security plan; other relevant documents or records.
|interview=Personnel with personnel security responsibilities; personnel with information security responsibilities.
|test=Organizational processes for personnel screening.
}}

{{Requirement
|id=3.9.2
|title=Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers.
|objectives=
* 3.9.2[a] a policy and/or process for terminating system access and any credentials coincident with personnel actions is established.
* 3.9.2[b] system access and credentials are terminated consistent with personnel actions such as termination or transfer.
* 3.9.2[c] the system is protected during and after personnel transfer actions.
|examine=Personnel security policy; procedures addressing personnel transfer and termination; records of personnel transfer and termination actions; list of system accounts; records of terminated or revoked authenticators and credentials; records of exit interviews; other relevant documents or records.
|interview=Personnel with personnel security responsibilities; personnel with account management responsibilities; system or network administrators; personnel with information security responsibilities.
|test=Organizational processes for personnel transfer and termination; mechanisms supporting or implementing personnel transfer and termination notifications; mechanisms for disabling system access and revoking authenticators.
}}

=== 3.10 Physical Protection ===

{{Requirement
|id=3.10.1
|title=Limit physical access to organizational systems, equipment, and the respective operating environments to authorized individuals.
|objectives=
* 3.10.1[a] authorized individuals allowed physical access are identified.
* 3.10.1[b] physical access to organizational systems is limited to authorized individuals.
* 3.10.1[c] physical access to equipment is limited to authorized individuals.
* 3.10.1[d] physical access to operating environments is limited to authorized individuals.
|examine=Physical and environmental protection policy; procedures addressing physical access authorizations; system security plan; authorized personnel access list; authorization credentials; physical access list reviews; physical access termination records and associated documentation; other relevant documents or records.
|interview=Personnel with physical access authorization responsibilities; personnel with physical access to system facility; personnel with information security responsibilities.
|test=Organizational processes for physical access authorizations; mechanisms supporting or implementing physical access authorizations.
}}

{{Requirement
|id=3.10.2
|title=Protect and monitor the physical facility and support infrastructure for organizational systems.
|objectives=
* 3.10.2[a] the physical facility where organizational systems reside is protected.
* 3.10.2[b] the support infrastructure for organizational systems is protected.
* 3.10.2[c] the physical facility where organizational systems reside is monitored.
* 3.10.2[d] the support infrastructure for organizational systems is monitored.
|examine=Physical and environmental protection policy; procedures addressing physical access monitoring; system security plan; physical access logs or records; physical access monitoring records; physical access log reviews; other relevant documents or records.
|interview=Personnel with physical access monitoring responsibilities; personnel with incident response responsibilities; personnel with information security responsibilities.
|test=Organizational processes for monitoring physical access; mechanisms supporting or implementing physical access monitoring; mechanisms supporting or implementing the review of physical access logs.
}}

{{Requirement
|id=3.10.3
|title=Escort visitors and monitor visitor activity.
|objectives=
* 3.10.3[a] visitors are escorted.
* 3.10.3[b] visitor activity is monitored.
|examine=Physical and environmental protection policy; procedures addressing physical access control; system security plan; physical access control logs or records; inventory records of physical access control devices; system entry and exit points; records of key and lock combination changes; storage locations for physical access control devices; physical access control devices; list of security safeguards controlling access to designated publicly accessible areas within facility; other relevant documents or records.
|interview=Personnel with physical access control responsibilities; personnel with information security responsibilities.
|test=Organizational processes for physical access control; mechanisms supporting or implementing physical access control; physical access control devices.
}}

{{Requirement
|id=3.10.4
|title=Maintain audit logs of physical access.
|objectives=Determine if audit logs of physical access are maintained.
|examine=Physical and environmental protection policy; procedures addressing physical access control; system security plan; physical access control logs or records; inventory records of physical access control devices; system entry and exit points; records of key and lock combination changes; storage locations for physical access control devices; physical access control devices; list of security safeguards controlling access to designated publicly accessible areas within facility; other relevant documents or records.
|interview=Personnel with physical access control responsibilities; personnel with information security responsibilities.
|test=Organizational processes for physical access control; mechanisms supporting or implementing physical access control; physical access control devices.
}}

{{Requirement
|id=3.10.5
|title=Control and manage physical access devices.
|objectives=
* 3.10.5[a] physical access devices are identified.
* 3.10.5[b] physical access devices are controlled.
* 3.10.5[c] physical access devices are managed.
|examine=Physical and environmental protection policy; procedures addressing physical access control; system security plan; physical access control logs or records; inventory records of physical access control devices; system entry and exit points; records of key and lock combination changes; storage locations for physical access control devices; physical access control devices; list of security safeguards controlling access to designated publicly accessible areas within facility; other relevant documents or records.
|interview=Personnel with physical access control responsibilities; personnel with information security responsibilities.
|test=Organizational processes for physical access control; mechanisms supporting or implementing physical access control; physical access control devices.
}}

{{Requirement
|id=3.10.6
|title=Enforce safeguarding measures for CUI at alternate work sites.
|objectives=
* 3.10.6[a] safeguarding measures for CUI are defined for alternate work sites.
* 3.10.6[b] safeguarding measures for CUI are enforced for alternate work sites.
|examine=Physical and environmental protection policy; procedures addressing alternate work sites for personnel; system security plan; list of safeguards required for alternate work sites; assessments of safeguards at alternate work sites; other relevant documents or records.
|interview=Personnel approving use of alternate work sites; personnel using alternate work sites; personnel assessing controls at alternate work sites; personnel with information security responsibilities.
|test=Organizational processes for security at alternate work sites; mechanisms supporting alternate work sites; safeguards employed at alternate work sites; means of communications between personnel at alternate work sites and security personnel.
}}

=== 3.11 Risk Assessment ===

{{Requirement
|id=3.11.1
|title=Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI.
|objectives=
* 3.11.1[a] the frequency to assess risk to organizational operations, organizational assets, and individuals is defined.
* 3.11.1[b] risk to organizational operations, organizational assets, and individuals resulting from the operation of an organizational system that processes, stores, or transmits CUI is assessed with the defined frequency.
|examine=Risk assessment policy; security planning policy and procedures; procedures addressing organizational risk assessments; system security plan; risk assessment; risk assessment results; risk assessment reviews; risk assessment updates; other relevant documents or records.
|interview=Personnel with risk assessment responsibilities; personnel with information security responsibilities.
|test=Organizational processes for risk assessment; mechanisms supporting or for conducting, documenting, reviewing, disseminating, and updating the risk assessment.
}}

{{Requirement
|id=3.11.2
|title=Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
|objectives=
* 3.11.2[a] the frequency to scan for vulnerabilities in organizational systems and applications is defined.
* 3.11.2[b] vulnerability scans are performed on organizational systems with the defined frequency.
* 3.11.2[c] vulnerability scans are performed on applications with the defined frequency.
* 3.11.2[d] vulnerability scans are performed on organizational systems when new vulnerabilities are identified.
* 3.11.2[e] vulnerability scans are performed on applications when new vulnerabilities are identified.
|examine=Risk assessment policy; procedures addressing vulnerability scanning; risk assessment; system security plan; security assessment report; vulnerability scanning tools and associated configuration documentation; vulnerability scanning results; patch and vulnerability management records; other relevant documents or records.
|interview=Personnel with risk assessment, security assessment and vulnerability scanning responsibilities; personnel with vulnerability scan analysis and remediation responsibilities; personnel with information security responsibilities; system or network administrators.
|test=Organizational processes for vulnerability scanning, analysis, remediation, and information sharing; mechanisms supporting or implementing vulnerability scanning, analysis, remediation, and information sharing.
}}

{{Requirement
|id=3.11.3
|title=Remediate vulnerabilities in accordance with risk assessments.
|objectives=
* 3.11.3[a] vulnerabilities are identified.
* 3.11.3[b] vulnerabilities are remediated in accordance with risk assessments.
|examine=Risk assessment policy; procedures addressing vulnerability scanning; risk assessment; system security plan; security assessment report; vulnerability scanning tools and associated configuration documentation; vulnerability scanning results; patch and vulnerability management records; other relevant documents or records.
|interview=Personnel with risk assessment, security assessment and vulnerability scanning responsibilities; personnel with vulnerability scan analysis responsibilities; personnel with vulnerability remediation responsibilities; personnel with information security responsibilities; system or network administrators.
|test=Organizational processes for vulnerability scanning, analysis, remediation, and information sharing; mechanisms supporting or implementing vulnerability scanning, analysis, remediation, and information sharing.
}}

=== 3.12 Security Assessment ===

{{Requirement
|id=3.12.1
|title=Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.
|objectives=
* 3.12.1[a] the frequency of security control assessments is defined.
* 3.12.1[b] security controls are assessed with the defined frequency to determine if the controls are effective in their application.
|examine=Security assessment and authorization policy; procedures addressing security assessment planning; procedures addressing security assessments; security assessment plan; system security plan; other relevant documents or records.
|interview=Personnel with security assessment responsibilities; personnel with information security responsibilities.
|test=Mechanisms supporting security assessment, security assessment plan development, and security assessment reporting.
}}

{{Requirement
|id=3.12.2
|title=Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.
|objectives=
* 3.12.2[a] deficiencies and vulnerabilities to be addressed by the plan of action are identified.
* 3.12.2[b] a plan of action is developed to correct identified deficiencies and reduce or eliminate identified vulnerabilities.
* 3.12.2[c] the plan of action is implemented to correct identified deficiencies and reduce or eliminate identified vulnerabilities.
|examine=Security assessment and authorization policy; procedures addressing plan of action; system security plan; security assessment plan; security assessment report; security assessment evidence; plan of action; other relevant documents or records.
|interview=Personnel with plan of action development and implementation responsibilities; personnel with information security responsibilities.
|test=Mechanisms for developing, implementing, and maintaining plan of action.
}}

{{Requirement
|id=3.12.3
|title=Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.
|objectives=Determine if security controls are monitored on an ongoing basis to ensure the continued effectiveness of those controls.
|examine=Security planning policy; organizational procedures addressing system security plan development and implementation; procedures addressing system security plan reviews and updates; enterprise architecture documentation; system security plan; records of system security plan reviews and updates; other relevant documents or records.
|interview=Personnel with security planning and system security plan implementation responsibilities; personnel with information security responsibilities.
|test=Organizational processes for system security plan development, review, update, and approval; mechanisms supporting the system security plan.
}}

{{Requirement
|id=3.12.4
|title=Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.
|objectives=
* 3.12.4[a] a system security plan is developed.
* 3.12.4[b] the system boundary is described and documented in the system security plan.
* 3.12.4[c] the system environment of operation is described and documented in the system security plan.
* 3.12.4[d] the security requirements identified and approved by the designated authority as non-applicable are identified.
* 3.12.4[e] the method of security requirement implementation is described and documented in the system security plan.
* 3.12.4[f] the relationship with or connection to other systems is described and documented in the system security plan.
* 3.12.4[g] the frequency to update the system security plan is defined.
* 3.12.4[h] system security plan is updated with the defined frequency.
|examine=Security planning policy; procedures addressing system security plan development and implementation; procedures addressing system security plan reviews and updates; enterprise architecture documentation; system security plan; records of system security plan reviews and updates; other relevant documents or records.
|interview=Personnel with security planning and system security plan implementation responsibilities; personnel with information security responsibilities.
|test=Organizational processes for system security plan development, review, update, and approval; mechanisms supporting the system security plan.
}}

=== 3.13 System and Communications Protection ===

{{Requirement
|id=3.13.1
|title=Monitor, control, and protect communications (i.e., information transmitted or received by organizational systems) at the external boundaries and key internal boundaries of organizational systems.
|objectives=
* 3.13.1[a] the external system boundary is defined.
* 3.13.1[b] key internal system boundaries are defined.
* 3.13.1[c] communications are monitored at the external system boundary.
* 3.13.1[d] communications are monitored at key internal boundaries.
* 3.13.1[e] communications are controlled at the external system boundary.
* 3.13.1[f] communications are controlled at key internal boundaries.
* 3.13.1[g] communications are protected at the external system boundary.
* 3.13.1[h] communications are protected at key internal boundaries.
|examine=System and communications protection policy; procedures addressing boundary protection; system security plan; list of key internal boundaries of the system; system design documentation; boundary protection hardware and software; enterprise security architecture documentation; system audit logs and records; system configuration settings and associated documentation; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; system developer; personnel with boundary protection responsibilities.
|test=Mechanisms implementing boundary protection capability.
}}

{{Requirement
|id=3.13.2
|title=Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.
|objectives=
* 3.13.2[a] architectural designs that promote effective information security are identified.
* 3.13.2[b] software development techniques that promote effective information security are identified.
* 3.13.2[c] systems engineering principles that promote effective information security are identified.
* 3.13.2[d] identified architectural designs that promote effective information security are employed.
* 3.13.2[e] identified software development techniques that promote effective information security are employed.
* 3.13.2[f] identified systems engineering principles that promote effective information security are employed.
|examine=Security planning policy; procedures addressing system security plan development and implementation; procedures addressing system security plan reviews and updates; enterprise architecture documentation; system security plan; records of system security plan reviews and updates; system and communications protection policy; procedures addressing security engineering principles used in the specification, design, development, implementation, and modification of the system; security architecture documentation; security requirements and specifications for the system; system design documentation; system configuration settings and associated documentation; other relevant documents or records.
|interview=Personnel with responsibility for determining information system security requirements; personnel with information system design, development, implementation, and modification responsibilities; personnel with security planning and system security plan implementation responsibilities; personnel with information security responsibilities.
|test=Organizational processes for system security plan development, review, update, and approval; mechanisms supporting the system security plan; processes for applying security engineering principles in system specification, design, development, implementation, and modification; automated mechanisms supporting the application of security engineering principles in information system specification, design, development, implementation, and modification.
}}

{{Requirement
|id=3.13.3
|title=Separate user functionality from system management functionality.
|objectives=
* 3.13.3[a] user functionality is identified.
* 3.13.3[b] system management functionality is identified.
* 3.13.3[c] user functionality is separated from system management functionality.
|examine=System and communications protection policy; procedures addressing application partitioning; system design documentation; system configuration settings and associated documentation; system security plan; system audit logs and records; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; system developer.
|test=Separation of user functionality from system management functionality.
}}

{{Requirement
|id=3.13.4
|title=Prevent unauthorized and unintended information transfer via shared system resources.
|objectives=Determine if unauthorized and unintended information transfer via shared system resources is prevented.
|examine=System and communications protection policy; procedures addressing application partitioning; system security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; system developer.
|test=Separation of user functionality from system management functionality.
}}

{{Requirement
|id=3.13.5
|title=Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
|objectives=
* 3.13.5[a] publicly accessible system components are identified.
* 3.13.5[b] subnetworks for publicly accessible system components are physically or logically separated from internal networks.
|examine=System and communications protection policy; procedures addressing boundary protection; system security plan; list of key internal boundaries of the system; system design documentation; boundary protection hardware and software; system configuration settings and associated documentation; enterprise security architecture documentation; system audit logs and records; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; system developer; personnel with boundary protection responsibilities.
|test=Mechanisms implementing boundary protection capability.
}}

{{Requirement
|id=3.13.6
|title=Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).
|objectives=
* 3.13.6[a] network communications traffic is denied by default.
* 3.13.6[b] network communications traffic is allowed by exception.
|examine=System and communications protection policy; procedures addressing boundary protection; system security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; system developer; personnel with boundary protection responsibilities.
|test=Mechanisms implementing traffic management at managed interfaces.
}}

{{Requirement
|id=3.13.7
|title=Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling).
|objectives=Determine if remote devices are prevented from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks (i.e., split tunneling).
|examine=System and communications protection policy; procedures addressing boundary protection; system security plan; system design documentation; system hardware and software; system architecture; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; system developer; personnel with boundary protection responsibilities.
|test=Mechanisms implementing boundary protection capability; mechanisms supporting or restricting non-remote connections.
}}

{{Requirement
|id=3.13.8
|title=Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.
|objectives=
* 3.13.8[a] cryptographic mechanisms intended to prevent unauthorized disclosure of CUI are identified.
* 3.13.8[b] alternative physical safeguards intended to prevent unauthorized disclosure of CUI are identified.
* 3.13.8[c] either cryptographic mechanisms or alternative physical safeguards are implemented to prevent unauthorized disclosure of CUI during transmission.
|examine=System and communications protection policy; procedures addressing transmission confidentiality and integrity; system security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; system developer.
|test=Cryptographic mechanisms or mechanisms supporting or implementing transmission confidentiality; organizational processes for defining and implementing alternative physical safeguards.
}}

{{Requirement
|id=3.13.9
|title=Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity.
|objectives=
* 3.13.9[a] a period of inactivity to terminate network connections associated with communications sessions is defined.
* 3.13.9[b] network connections associated with communications sessions are terminated at the end of the sessions.
* 3.13.9[c] network connections associated with communications sessions are terminated after the defined period of inactivity.
|examine=System and communications protection policy; procedures addressing network disconnect; system design documentation; system security plan; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; system developer.
|test=Mechanisms supporting or implementing network disconnect capability.
}}

{{Requirement
|id=3.13.10
|title=Establish and manage cryptographic keys for cryptography employed in organizational systems.
|objectives=
* 3.13.10[a] cryptographic keys are established whenever cryptography is employed.
* 3.13.10[b] cryptographic keys are managed whenever cryptography is employed.
|examine=System and communications protection policy; procedures addressing cryptographic key establishment and management; system security plan; system design documentation; cryptographic mechanisms; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; personnel with responsibilities for cryptographic key establishment and management.
|test=Mechanisms supporting or implementing cryptographic key establishment and management.
}}

{{Requirement
|id=3.13.11
|title=Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.
|objectives=Determine if FIPS-validated cryptography is employed to protect the confidentiality of CUI.
|examine=System and communications protection policy; procedures addressing cryptographic protection; system security plan; system design documentation; system configuration settings and associated documentation; cryptographic module validation certificates; list of FIPS-validated cryptographic modules; system audit logs and records; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; system developer; personnel with responsibilities for cryptographic protection.
|test=Mechanisms supporting or implementing cryptographic protection.
}}

{{Requirement
|id=3.13.12
|title=Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device.
|objectives=
* 3.13.12[a] collaborative computing devices are identified.
* 3.13.12[b] collaborative computing devices provide indication to users of devices in use.
* 3.13.12[c] remote activation of collaborative computing devices is prohibited.
|examine=System and communications protection policy; procedures addressing collaborative computing; access control policy and procedures; system security plan; system design documentation; system audit logs and records; system configuration settings and associated documentation; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; system developer; personnel with responsibilities for managing collaborative computing devices.
|test=Mechanisms supporting or implementing management of remote activation of collaborative computing devices; mechanisms providing an indication of use of collaborative computing devices.
}}

{{Requirement
|id=3.13.13
|title=Control and monitor the use of mobile code.
|objectives=
* 3.13.13[a] use of mobile code is controlled.
* 3.13.13[b] use of mobile code is monitored.
|examine=System and communications protection policy; procedures addressing mobile code; mobile code usage restrictions, mobile code implementation policy and procedures; system audit logs and records; system security plan; list of acceptable mobile code and mobile code technologies; list of unacceptable mobile code and mobile technologies; authorization records; system monitoring records; system audit logs and records; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; personnel with responsibilities for managing mobile code.
|test=Organizational process for controlling, authorizing, monitoring, and restricting mobile code; mechanisms supporting or implementing the management of mobile code; mechanisms supporting or implementing the monitoring of mobile code.
}}

{{Requirement
|id=3.13.14
|title=Control and monitor the use of Voice over Internet Protocol (VoIP) technologies.
|objectives=
* 3.13.14[a] use of Voice over Internet Protocol (VoIP) technologies is controlled.
* 3.13.14[b] use of Voice over Internet Protocol (VoIP) technologies is monitored.
|examine=System and communications protection policy; procedures addressing VoIP; VoIP usage restrictions; VoIP implementation guidance; system security plan; system design documentation; system audit logs and records; system configuration settings and associated documentation; system monitoring records; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; personnel with responsibilities for managing VoIP.
|test=Organizational process for authorizing, monitoring, and controlling VoIP; mechanisms supporting or implementing authorizing, monitoring, and controlling VoIP.
}}

{{Requirement
|id=3.13.15
|title=Protect the authenticity of communications sessions.
|objectives=Determine if the authenticity of communications sessions is protected.
|examine=System and communications protection policy; procedures addressing session authenticity; system security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities.
|test=Mechanisms supporting or implementing session authenticity.
}}

{{Requirement
|id=3.13.16
|title=Protect the confidentiality of CUI at rest.
|objectives=Determine if the confidentiality of CUI at rest is protected.
|examine=System and communications protection policy; procedures addressing protection of information at rest; system security plan; system design documentation; list of information at rest requiring confidentiality protections; system configuration settings and associated documentation; cryptographic mechanisms and associated configuration documentation; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; system developer.
|test=Mechanisms supporting or implementing confidentiality protections for information at rest.
}}

=== 3.14 System and Information Integrity ===

{{Requirement
|id=3.14.1
|title=Identify, report, and correct system flaws in a timely manner.
|objectives=
* 3.14.1[a] the time within which to identify system flaws is specified.
* 3.14.1[b] system flaws are identified within the specified time frame.
* 3.14.1[c] the time within which to report system flaws is specified.
* 3.14.1[d] system flaws are reported within the specified time frame.
* 3.14.1[e] the time within which to correct system flaws is specified.
* 3.14.1[f] system flaws are corrected within the specified time frame.
|examine=System and information integrity policy; procedures addressing flaw remediation; procedures addressing configuration management; system security plan; list of flaws and vulnerabilities potentially affecting the system; list of recent security flaw remediation actions performed on the system (e.g., list of installed patches, service packs, hot fixes, and other software updates to correct system flaws); test results from the installation of software and firmware updates to correct system flaws; installation/change control records for security-relevant software and firmware updates; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; personnel installing, configuring, and maintaining the system; personnel with responsibility for flaw remediation; personnel with configuration management responsibility.
|test=Organizational processes for identifying, reporting, and correcting system flaws; organizational process for installing software and firmware updates; mechanisms supporting or implementing reporting, and correcting system flaws; mechanisms supporting or implementing testing software and firmware updates.
}}

{{Requirement
|id=3.14.2
|title=Provide protection from malicious code at designated locations within organizational systems.
|objectives=
* 3.14.2[a] designated locations for malicious code protection are identified.
* 3.14.2[b] protection from malicious code at designated locations is provided.
|examine=System and information integrity policy; configuration management policy and procedures; procedures addressing malicious code protection; records of malicious code protection updates; malicious code protection mechanisms; system security plan; system configuration settings and associated documentation; record of actions initiated by malicious code protection mechanisms in response to malicious code detection; scan results from malicious code protection mechanisms; system design documentation; system audit logs and records; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; personnel installing, configuring, and maintaining the system; personnel with responsibility for malicious code protection; personnel with configuration management responsibility.
|test=Organizational processes for employing, updating, and configuring malicious code protection mechanisms; organizational process for addressing false positives and resulting potential impact; mechanisms supporting or implementing employing, updating, and configuring malicious code protection mechanisms; mechanisms supporting or implementing malicious code scanning and subsequent actions.
}}

{{Requirement
|id=3.14.3
|title=Monitor system security alerts and advisories and take action in response.
|objectives=
* 3.14.3[a] response actions to system security alerts and advisories are identified.
* 3.14.3[b] system security alerts and advisories are monitored.
* 3.14.3[c] actions in response to system security alerts and advisories are taken.
|examine=System and information integrity policy; procedures addressing security alerts, advisories, and directives; system security plan; records of security alerts and advisories; other relevant documents or records.
|interview=Personnel with security alert and advisory responsibilities; personnel implementing, operating, maintaining, and using the system; personnel, organizational elements, and external organizations to whom alerts, advisories, and directives are to be disseminated; system or network administrators; personnel with information security responsibilities.
|test=Organizational processes for defining, receiving, generating, disseminating, and complying with security alerts, advisories, and directives; mechanisms supporting or implementing definition, receipt, generation, and dissemination of security alerts, advisories, and directives; mechanisms supporting or implementing security directives.
}}

{{Requirement
|id=3.14.4
|title=Update malicious code protection mechanisms when new releases are available.
|objectives=Determine if malicious code protection mechanisms are updated when new releases are available.
|examine=System and information integrity policy; configuration management policy and procedures; procedures addressing malicious code protection; malicious code protection mechanisms; records of malicious code protection updates; system security plan; system design documentation; system configuration settings and associated documentation; scan results from malicious code protection mechanisms; record of actions initiated by malicious code protection mechanisms in response to malicious code detection; system audit logs and records; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; personnel installing, configuring, and maintaining the system; personnel with responsibility for malicious code protection; personnel with configuration management responsibility.
|test=Organizational processes for employing, updating, and configuring malicious code protection mechanisms; organizational process for addressing false positives and resulting potential impact; mechanisms supporting or implementing malicious code protection mechanisms (including updates and configurations); mechanisms supporting or implementing malicious code scanning and subsequent actions.
}}

{{Requirement
|id=3.14.5
|title=Perform periodic scans of organizational systems and real-time scans of files from external sources as files are downloaded, opened, or executed.
|objectives=
* 3.14.5[a] the frequency for malicious code scans is defined.
* 3.14.5[b] malicious code scans are performed with the defined frequency.
* 3.14.5[c] real-time malicious code scans of files from external sources as files are downloaded, opened, or executed are performed.
|examine=System and information integrity policy; configuration management policy and procedures; procedures addressing malicious code protection; malicious code protection mechanisms; records of malicious code protection updates; system security plan; system design documentation; system configuration settings and associated documentation; scan results from malicious code protection mechanisms; record of actions initiated by malicious code protection mechanisms in response to malicious code detection; system audit logs and records; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; personnel installing, configuring, and maintaining the system; personnel with responsibility for malicious code protection; personnel with configuration management responsibility.
|test=Organizational processes for employing, updating, and configuring malicious code protection mechanisms; organizational process for addressing false positives and resulting potential impact; mechanisms supporting or implementing malicious code protection mechanisms (including updates and configurations); mechanisms supporting or implementing malicious code scanning and subsequent actions.
}}

{{Requirement
|id=3.14.6
|title=Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.
|objectives=
* 3.14.6[a] the system is monitored to detect attacks and indicators of potential attacks.
* 3.14.6[b] inbound communications traffic is monitored to detect attacks and indicators of potential attacks.
* 3.14.6[c] outbound communications traffic is monitored to detect attacks and indicators of potential attacks.
|examine=System and information integrity policy; procedures addressing system monitoring tools and techniques; continuous monitoring strategy; facility diagram or layout; system security plan; system monitoring tools and techniques documentation; system design documentation; locations within system where monitoring devices are deployed; system protocols; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; personnel installing, configuring, and maintaining the system; personnel with responsibility monitoring the system; personnel with responsibility for the intrusion detection system.
|test=Organizational processes for system monitoring; mechanisms supporting or implementing intrusion detection capability and system monitoring; mechanisms supporting or implementing system monitoring capability; organizational processes for intrusion detection and system monitoring; mechanisms supporting or implementing the monitoring of inbound and outbound communications traffic.
}}

{{Requirement
|id=3.14.7
|title=Identify unauthorized use of organizational systems.
|objectives=
* 3.14.7[a] authorized use of the system is defined.
* 3.14.7[b] unauthorized use of the system is identified.
|examine=Continuous monitoring strategy; system and information integrity policy; procedures addressing system monitoring tools and techniques; facility diagram/layout; system security plan; system design documentation; system monitoring tools and techniques documentation; locations within system where monitoring devices are deployed; system configuration settings and associated documentation; other relevant documents or records.
|interview=System or network administrators; personnel with information security responsibilities; personnel installing, configuring, and maintaining the system; personnel with responsibility for monitoring the system.
|test=Organizational processes for system monitoring; mechanisms supporting or implementing system monitoring capability.
}}

== Appendix A: References ==
''Laws, Executive Orders, Regulations, Instructions, Standards, and Guidelines''<ref>References in this section without specific publication dates or revision numbers are assumed to refer to the most recent updates to those publications.</ref>

=== Legislation, Executive Orders, and Regulations ===

# Federal Information Security Modernization Act of 2014 (P.L. 113-283), December 2014. https://www.gpo.gov/fdsys/pkg/PLAW-113publ283/pdf/PLAW-113publ283.pdf
# Executive Order 13526, ''Classified National Security Information'', December 2009. https://www.archives.gov/isoo/policy-documents/cnsi-eo.html
# Executive Order 13556, ''Controlled Unclassified Information'', November 2010. https://www.gpo.gov/fdsys/pkg/FR-2010-11-09/pdf/2010-28360.pdf
# Executive Order 13636, ''Improving Critical Infrastructure Cybersecurity'', February 2013. https://www.gpo.gov/fdsys/pkg/FR-2013-02-19/pdf/2013-03915.pdf
# 32 CFR Part 2002, ''Controlled Unclassified Information'', September 2016. https://www.gpo.gov/fdsys/pkg/CFR-2017-title32-vol6/pdf/CFR-2017-title32-vol6-part2002.pdf

=== Standards, Guidelines, Interagency Reports, and Instructions ===

# National Institute of Standards and Technology Federal Information Processing Standards Publication 199, ''Standards for Security Categorization of Federal Information and Information Systems'', February 2004. https://doi.org/10.6028/NIST.FIPS.199
# National Institute of Standards and Technology Federal Information Processing Standards Publication 200, ''Minimum Security Requirements for Federal Information and Information Systems'', March 2006. https://doi.org/10.6028/NIST.FIPS.200
# National Institute of Standards and Technology Special Publication 800-39, ''Managing Information Security Risk: Organization, Mission, and Information System View'', March 2011. https://doi.org/10.6028/NIST.SP.800-39
# National Institute of Standards and Technology Special Publication 800-53, Revision 4, ''Security and Privacy Controls for Federal Information Systems and Organizations'', April 2013. https://doi.org/10.6028/NIST.SP.800-53r4
# National Institute of Standards and Technology Special Publication 800-53A, Revision 4, ''Assessing Security and Privacy Controls in Federal Information Systems and Organizations: Building Effective Security Assessment Plans'', December 2014. https://doi.org/10.6028/NIST.SP.800-53Ar4
# National Institute of Standards and Technology Special Publication 171, Revision 1, ''Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations'', December 2016. https://doi.org/10.6028/NIST.SP.800-171r1
# National Institute of Standards and Technology Special Publication 128, ''Guide for Security-Focused Configuration Management of Information Systems'', August 2011. https://doi.org/10.6028/NIST.SP.800-128
# International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) 27001:2013, ''Information technology -- Security techniques -- Information security management systems -- Requirements'', September 2013.
# International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) 27002:2013, ''Information technology -- Security techniques -- Code of practice for information security controls'', September 2013.
# Committee on National Security Systems Instruction 4009, ''National Information Assurance Glossary'', April 2015. https://www.cnss.gov
# National Institute of Standards and Technology Internal Report 8062, ''An Introduction to Privacy Engineering and Risk Management in Federal Systems'', January 2017. https://doi.org/10.6028/NIST.IR.8062

=== Other Resources ===

# National Archives and Records Administration, ''Controlled Unclassified Information Registry''. https://www.archives.gov/cui/registry/category-list
# National Institute of Standards and Technology Handbook 162, ''NIST MEP Cybersecurity Self-Assessment Handbook for Assessing NIST SP 800-171 Security Requirements in Response to DFARS Cybersecurity Requirements'', November 2017. https://doi.org/10.6028/NIST.HB.162

== Appendix B: Glossary ==
''Common terms and definitions''

Appendix B provides definitions for security terminology used within Special Publication 800-171. Unless specifically defined in this glossary, all terms used in this publication are consistent with the definitions contained in CNSS Instruction 4009, ''National Information Assurance Glossary''.

{| class="wikitable"
|-
! Term !! Definition
|-
| '''agency''' || See ''executive agency''.
|-
| '''assessment''' || See ''Security Control Assessment''.
|-
| '''assessor''' || See ''Security Control Assessor''.
|-
| '''audit log''' || A chronological record of system activities, including records of system accesses and operations performed in a given period.
|-
| '''audit record''' || An individual entry in an audit log related to an audited event.
|-
| '''authentication''' [FIPS 200, Adapted] || Verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in a system.
|-
| '''availability''' [44 U.S.C., Sec. 3542] || Ensuring timely and reliable access to and use of information.
|-
| '''baseline configuration''' || A documented set of specifications for a system, or a configuration item within a system, that has been formally reviewed and agreed on at a given point in time, and which can be changed only through change control procedures.
|-
| '''blacklisting''' || A process used to identify software programs that are not authorized to execute on a system or prohibited Universal Resource Locators (URL)/websites.
|-
| '''confidentiality''' [44 U.S.C., Sec. 3542] || Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.
|-
| '''configuration management''' || A collection of activities focused on establishing and maintaining the integrity of information technology products and systems, through control of processes for initializing, changing, and monitoring the configurations of those products and systems throughout the system development life cycle.
|-
| '''configuration settings''' || The set of parameters that can be changed in hardware, software, or firmware that affect the security posture and/or functionality of the system.
|-
| '''controlled area''' || Any area or space for which the organization has confidence that the physical and procedural protections provided are sufficient to meet the requirements established for protecting the information or system.
|-
| '''controlled unclassified information''' [E.O. 13556] || Information that law, regulation, or governmentwide policy requires to have safeguarding or disseminating controls, excluding information that is classified under Executive Order 13526, ''Classified National Security Information'', December 29, 2009, or any predecessor or successor order, or the Atomic Energy Act of 1954, as amended.
|-
| '''CUI categories or subcategories''' [Title 32 CFR, Part 2002] || Those types of information for which laws, regulations, or governmentwide policies require or permit agencies to exercise safeguarding or dissemination controls, and which the CUI Executive Agent has approved and listed in the CUI Registry.
|-
| '''CUI Executive Agent''' [Title 32 CFR, Part 2002] || The National Archives and Records Administration (NARA), which implements the executive branch-wide CUI Program and oversees federal agency actions to comply with Executive Order 13556. NARA has delegated this authority to the Director of the Information Security Oversight Office (ISOO).
|-
| '''CUI program''' [Title 32 CFR, Part 2002] || The executive branch-wide program to standardize CUI handling by all federal agencies. The program includes the rules, organization, and procedures for CUI, established by Executive Order 13556, 32 CFR Part 2002, and the CUI Registry.
|-
| '''CUI registry''' [Title 32 CFR, Part 2002] || The online repository for all information, guidance, policy, and requirements on handling CUI, including everything issued by the CUI Executive Agent other than 32 CFR Part 2002. Among other information, the CUI Registry identifies all approved CUI categories and subcategories, provides general descriptions for each, identifies the basis for controls, establishes markings, and includes guidance on handling procedures.
|-
| '''environment of operation''' [NIST SP 800-37, Adapted] || The physical surroundings in which a system processes, stores, and transmits information.
|-
| '''executive agency''' [41 U.S.C., Sec. 403] || An executive department specified in 5 U.S.C., Sec. 105; a military department specified in 5 U.S.C., Sec. 102; an independent establishment as defined in 5 U.S.C., Sec. 104(1); and a wholly owned Government corporation fully subject to the provisions of 31 U.S.C., Chapter 91.
|-
| '''external system (or component)''' || A system or component of a system that is outside of the authorization boundary established by the organization and for which the organization typically has no direct control over the application of required security controls or the assessment of security control effectiveness.
|-
| '''external system service''' || A system service that is implemented outside of the authorization boundary of the organizational system (i.e., a service that is used by, but not a part of, the organizational system) and for which the organization typically has no direct control over the application of required security controls or the assessment of security control effectiveness.
|-
| '''external system service provider''' || A provider of external system services to an organization through a variety of consumer-producer relationships including but not limited to: joint ventures; business partnerships; outsourcing arrangements (i.e., through contracts, interagency agreements, lines of business arrangements); licensing agreements; and/or supply chain exchanges.
|-
| '''external network''' || A network not controlled by the organization.
|-
| '''federal agency''' || See ''executive agency''.
|-
| '''federal information system''' [40 U.S.C., Sec. 11331] || An information system used or operated by an executive agency, by a contractor of an executive agency, or by another organization on behalf of an executive agency. See ''on behalf of (an agency)'' for additional information.
|-
| '''FIPS-validated cryptography''' || A cryptographic module validated by the Cryptographic Module Validation Program (CMVP) to meet requirements specified in FIPS Publication 140-2 (as amended). As a prerequisite to CMVP validation, the cryptographic module is required to employ a cryptographic algorithm implementation that has successfully passed validation testing by the Cryptographic Algorithm Validation Program (CAVP). See ''NSA-Approved Cryptography''.
|-
| '''firmware''' || Computer programs and data stored in hardware - typically in read-only memory (ROM) or programmable read-only memory (PROM) - such that the programs and data cannot be dynamically written or modified during execution of the programs.
|-
| '''hardware''' || The physical components of a system. See ''Software'' and ''Firmware''.
|-
| '''identifier''' || Unique data used to represent a person's identity and associated attributes. A name or a card number are examples of identifiers. A unique label used by a system to indicate a specific entity, object, or group.
|-
| '''impact''' || The effect on organizational operations, organizational assets, individuals, other organizations, or the Nation (including the national security interests of the United States) of a loss of confidentiality, integrity, or availability of information or a system.
|-
| '''impact value''' || The assessed potential impact resulting from a compromise of the confidentiality of information (e.g., CUI) expressed as a value of low, moderate, or high.
|-
| '''incident''' [FIPS 200, Adapted] || An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of a system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.
|-
| '''information''' || Any communication or representation of knowledge such as facts, data, or opinions in any medium or form, including textual, numerical, graphic, cartographic, narrative, or audiovisual.
|-
| '''information flow control''' || Procedure to ensure that information transfers within a system are not made in violation of the security policy.
|-
| '''information resources''' [44 U.S.C., Sec. 3502] || Information and related resources, such as personnel, equipment, funds, and information technology.
|-
| '''information security''' [44 U.S.C., Sec. 3542] || The protection of information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide confidentiality, integrity, and availability.
|-
| '''information system''' [44 U.S.C., Sec. 3502] || A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.
|-
| '''information technology''' [40 U.S.C., Sec. 1401] || Any equipment or interconnected system or subsystem of equipment that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the executive agency. For purposes of the preceding sentence, equipment is used by an executive agency if the equipment is used by the executive agency directly or is used by a contractor under a contract with the executive agency which: (i) requires the use of such equipment; or (ii) requires the use, to a significant extent, of such equipment in the performance of a service or the furnishing of a product. The term ''information technology'' includes computers, ancillary equipment, software, firmware, and similar procedures, services (including support services), and related resources.
|-
| '''insider threat''' || The threat that an insider will use her/his authorized access, wittingly or unwittingly, to do harm to the security of the United States. This threat can include damage to the United States through espionage, terrorism, unauthorized disclosure, or through the loss or degradation of departmental resources or capabilities.
|-
| '''integrity''' [44 U.S.C., Sec. 3542] || Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity.
|-
| '''internal network''' || A network where establishment, maintenance, and provisioning of security controls are under the direct control of organizational employees or contractors; or the cryptographic encapsulation or similar security technology implemented between organization-controlled endpoints, provides the same effect (with regard to confidentiality and integrity). An internal network is typically organization-owned, yet may be organization-controlled while not being organization-owned.
|-
| '''least privilege''' || The principle that a system security architecture is designed so that each entity is granted the minimum system resources and authorizations that the entity needs to perform its function.
|-
| '''local access''' || Access to an organizational system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network.
|-
| '''malicious code''' || Software or firmware intended to perform an unauthorized process that will have adverse impact on the confidentiality, integrity, or availability of a system. A virus, worm, Trojan horse, or other code-based entity that infects a host. Spyware and some forms of adware are also examples of malicious code.
|-
| '''media''' [FIPS 200] || Physical devices or writing surfaces including, but not limited to, magnetic tapes, optical disks, magnetic disks, Large-Scale Integration (LSI) memory chips, and printouts (but not including display media) onto which information is recorded, stored, or printed within a system.
|-
| '''mobile code''' || Software programs or parts of programs obtained from remote systems, transmitted across a network, and executed on a local system without explicit installation or execution by the recipient.
|-
| '''mobile device''' || A portable computing device that has a small form factor such that it can easily be carried by a single individual; is designed to operate without a physical connection (e.g., wirelessly transmit or receive information); possesses local, non-removable/removable data storage; and includes a self-contained power source. Mobile devices may also include voice communication capabilities, on-board sensors that allow the devices to capture information, or built-in features that synchronize local data with remote locations. Examples include smartphones, tablets, and E-readers.
|-
| '''multifactor authentication''' || Authentication using two or more different factors to achieve authentication. Factors include something you know (e.g., PIN, password); something you have (e.g., cryptographic identification device, token); or something you are (e.g., biometric). See also ''Authenticator''.
|-
| '''nonfederal organization''' || An entity that owns, operates, or maintains a nonfederal system.
|-
| '''nonfederal system''' || A system that does not meet the criteria for a federal system.
|-
| '''network''' || A system implemented with a collection of interconnected components. Such components may include routers, hubs, cabling, telecommunications controllers, key distribution centers, and technical control devices.
|-
| '''network access''' || Access to a system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, Internet).
|-
| '''nonlocal maintenance''' || Maintenance activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network.
|-
| '''on behalf of (an agency)''' [32 CFR Part 2002] || A situation that occurs when: (i) a non-executive branch entity uses or operates an information system or maintains or collects information for the purpose of processing, storing, or transmitting Federal information; and (ii) those activities are not incidental to providing a service or product to the government.
|-
| '''organization''' [FIPS 200, Adapted] || An entity of any size, complexity, or positioning within an organizational structure.
|-
| '''portable storage device''' || A system component that can be inserted into and removed from a system, and that is used to store data or information (e.g., text, video, audio, and/or image data). Such components are typically implemented on magnetic, optical, or solid-state devices (e.g., floppy disks, compact/digital video disks, flash/thumb drives, external hard disk drives, and flash memory cards/drives that contain nonvolatile memory).
|-
| '''potential impact''' [FIPS 199] || The loss of confidentiality, integrity, or availability could be expected to have: (i) a ''limited'' adverse effect (FIPS Publication 199 low); (ii) a ''serious'' adverse effect (FIPS Publication 199 moderate); or (iii) a ''severe'' or ''catastrophic'' adverse effect (FIPS Publication 199 high) on organizational operations, organizational assets, or individuals.
|-
| '''privileged account''' || A system account with authorizations of a privileged user.
|-
| '''privileged user''' || A user that is authorized (and therefore, trusted) to perform security-relevant functions that ordinary users are not authorized to perform.
|-
| '''records''' || The recordings (automated and/or manual) of evidence of activities performed or results achieved (e.g., forms, reports, test results), which serve as a basis for verifying that the organization and the system are performing as intended. Also used to refer to units of related data fields (i.e., groups of data fields that can be accessed by a program and that contain the complete set of information on particular items).
|-
| '''remote access''' || Access to an organizational system by a user (or a process acting on behalf of a user) communicating through an external network (e.g., the Internet).
|-
| '''remote maintenance''' || Maintenance activities conducted by individuals communicating through an external network (e.g., the Internet).
|-
| '''replay resistance''' || Protection against the capture of transmitted authentication or access control information and its subsequent retransmission with the intent of producing an unauthorized effect or gaining unauthorized access.
|-
| '''risk''' [FIPS 200, Adapted] || A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. System-related security risks are those risks that arise from the loss of confidentiality, integrity, or availability of information or systems. Such risks reflect the potential adverse impacts to organizational operations, organizational assets, individuals, other organizations, and the Nation.
|-
| '''risk assessment''' || The process of identifying risks to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation of a system. Part of risk management, incorporates threat and vulnerability analyses, and considers mitigations provided by security controls planned or in place. Synonymous with risk analysis.
|-
| '''sanitization''' || Actions taken to render data written on media unrecoverable by both ordinary and, for some forms of sanitization, extraordinary means. Process to remove information from media such that data recovery is not possible. It includes removing all classified labels, markings, and activity logs.
|-
| '''security''' || A condition that results from the establishment and maintenance of protective measures that enable an enterprise to perform its mission or critical functions despite risks posed by threats to its use of systems. Protective measures may involve a combination of deterrence, avoidance, prevention, detection, recovery, and correction that form part of the enterprise's risk management approach.
|-
| '''security assessment''' || See ''Security Control Assessment''.
|-
| '''security control''' [FIPS 199, Adapted] || A safeguard or countermeasure prescribed for a system or an organization designed to protect the confidentiality, integrity, and availability of its information and to meet a set of defined security requirements.
|-
| '''security control assessment''' [CNSSI 4009, Adapted] || The testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for a system or organization.
|-
| '''security functionality''' || The security-related features, functions, mechanisms, services, procedures, and architectures implemented within organizational systems or the environments in which those systems operate.
|-
| '''security functions''' || The hardware, software, or firmware of the system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based.
|-
| '''security relevance''' || Functions or mechanisms that are relied upon, directly or indirectly, to enforce a security policy that governs confidentiality, integrity, and availability protections.
|-
| '''situational awareness''' [CNSSI 4009] || Within a volume of time and space, the perception of an enterprise's security posture and its threat environment; the comprehension/meaning of both taken together (risk); and the projection of their status into the near future.
|-
| '''split tunneling''' || The process of allowing a remote user or device to establish a non-remote connection with a system and simultaneously communicate via some other connection to a resource in an external network. This method of network access enables a user to access remote devices (e.g., a networked printer) at the same time as accessing uncontrolled networks.
|-
| '''supplemental guidance''' || Statements used to provide additional explanatory information for security controls or security control enhancements.
|-
| '''system''' || See ''Information System''.
|-
| '''system component''' [NIST SP 800-128, Adapted] || A discrete, identifiable information technology asset (hardware, software, firmware) that represents a building block of a system. System components include commercial information technology products.
|-
| '''system security plan''' || A document that describes how an organization meets the security requirements for a system or how an organization plans to meet the requirements. The system security plan describes the system boundary; the environment in which the system operates; the relationships with or connections to other systems; and how the security requirements are implemented.
|-
| '''system service''' || A capability provided by a system that facilitates information processing, storage, or transmission.
|-
| '''threat''' [CNSSI 4009, Adapted] || Any circumstance or event with the potential to adversely impact organizational operations, organizational assets, individuals, other organizations, or the Nation through a system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service.
|-
| '''user''' [CNSSI 4009, Adapted] || Individual, or (system) process acting on behalf of an individual, authorized to access a system.
|-
| '''whitelisting''' || A process used to identify software programs that are authorized to execute on a system or authorized Universal Resource Locators (URL)/websites.
|-
| '''wireless technology''' || Technology that permits the transfer of information between separated points without physical connection.
|}

== Appendix C: Acronyms ==
''Common abbreviations''

{| class="wikitable"
|-
! Acronym !! Meaning
|-
| CFR || Code of Federal Regulations
|-
| CIO || Chief Information Officer
|-
| CNSS || Committee on National Security Systems
|-
| CUI || Controlled Unclassified Information
|-
| FIPS || Federal Information Processing Standards
|-
| FISMA || Federal Information Security Modernization Act
|-
| ISO/IEC || International Organization for Standardization/International Electrotechnical Commission
|-
| ISOO || Information Security Oversight Office
|-
| ITL || Information Technology Laboratory
|-
| NARA || National Archives and Records Administration
|-
| NFO || Nonfederal Organization
|-
| NIST || National Institute of Standards and Technology
|-
| OMB || Office of Management and Budget
|-
| SP || Special Publication
|-
| SSP || System Security Plan
|}

== Appendix D: Assessment Methods ==
''Assessment method definitions, applicable objects, and attributes''

This appendix defines three assessment methods that can be used to assess the CUI security requirements in NIST Special Publication 800-171: ''examine'', ''interview'', and ''test''. Included in the definition of each assessment method are types of objects to which the method can be applied. The application of each method is described in terms of the attributes of ''depth'' and ''coverage'', progressing from ''basic'' to ''focused'' to ''comprehensive''. The attribute values correlate to the assurance requirements specified by the organization.

The depth attribute addresses the rigor and level of detail of the assessment. For the depth attribute, the ''focused'' attribute value includes and builds upon the assessment rigor and level of detail defined for the ''basic'' attribute value; the ''comprehensive'' attribute value includes and builds upon the assessment rigor and level of detail defined for the ''focused'' attribute value.

The coverage attribute addresses the scope or breadth of the assessment. For the coverage attribute, the ''focused'' attribute value includes and builds upon the number and type of assessment objects defined for the ''basic'' attribute value; the ''comprehensive'' attribute value includes and builds upon the number and type of assessment objects defined for the ''focused'' attribute value.

Tables D-1 through D-3 provide complete descriptions of the examine, interview, and test assessment methods. The use of '''bolded text''' in the assessment method description indicates the content that was added to and appears for the first time, in the description indicating greater rigor and level of detail for the attribute value.

=== Table D-1: Examine Assessment Method ===

{| class="wikitable"
|-
! colspan="2" | Method: EXAMINE
|-
| colspan="2" | The process of checking, inspecting, reviewing, observing, studying, or analyzing one or more assessment objects to facilitate understanding, achieve clarification, or obtain evidence. The results are used to support the determination of security safeguard existence, functionality, correctness, completeness, and potential for improvement over time.
|-
! Objects !! Description
|-
| ''Specifications'' || Examples: policies, plans, procedures, system requirements, designs.
|-
| ''Mechanisms'' || Examples: functionality implemented in hardware, software, firmware.
|-
| ''Activities'' || Examples: system operations, administration, management, exercises.
|-
! Attribute: Depth !! Description
|-
| '''Basic''' || Examination that consists of high-level reviews, checks, observations, or inspections of the assessment object. This type of examination is conducted using a limited body of evidence or documentation. Examples include: functional-level descriptions for mechanisms; high-level process descriptions for activities; and documents for specifications. Basic examinations provide a level of understanding of the security safeguards necessary for determining whether the safeguards are implemented and free of obvious errors.
|-
| '''Focused''' || Examination that consists of high-level reviews, checks, observations, or inspections '''and more in-depth studies and analyses''' of the assessment object. This type of examination is conducted using a '''substantial''' body of evidence or documentation. Examples include: functional-level descriptions '''and where appropriate and available, high-level design information''' for mechanisms; high-level process descriptions '''and implementation procedures''' for activities; and documents '''and related documents''' for specifications. Focused examinations provide a level of understanding of the security safeguards necessary for determining whether the safeguards are implemented and free of obvious errors '''and whether there are increased grounds for confidence that the safeguards are implemented correctly and operating as intended'''.
|-
| '''Comprehensive''' || Examination that consists of high-level reviews, checks, observations, or inspections and more in-depth, '''detailed, and thorough''' studies and analyses of the assessment object. This type of examination is conducted using an '''extensive''' body of evidence or documentation. Examples include: functional-level descriptions and where appropriate and available, high-level design information, '''low-level design information, and implementation information''' for mechanisms; high-level process descriptions and '''detailed''' implementation procedures for activities; and documents and related documents for specifications.<ref>While additional documentation is likely for mechanisms when moving from basic to focused to comprehensive examinations, the documentation associated with specifications and activities may be the same or similar for focused and comprehensive examinations, with the rigor of the examinations of these documents being increased at the comprehensive level.</ref> '''Comprehensive''' examinations provide a level of understanding of the security safeguards necessary for determining whether the safeguards are implemented and free of obvious errors and whether there are '''further''' increased grounds for confidence that the safeguards are implemented correctly and operating as intended '''on an ongoing and consistent basis, and that there is support for continuous improvement in the effectiveness of the safeguards'''.
|-
! Attribute: Coverage !! Description
|-
| colspan="2" | Addresses the scope or breadth of the examination process and includes the types of assessment objects to be examined; the number of objects to be examined by type; and specific objects to be examined.<ref>The organization, considering a variety of factors (e.g., available resources, importance of the assessment, the organization's overall assessment goals and objectives), confers with assessors and provides direction on the type, number, and specific objects to be examined for the attribute value described.</ref>
|-
| '''Basic''' || Examination that uses a representative sample of assessment objects (by type and number within type) to provide a level of coverage necessary for determining whether the security safeguards are implemented and free of obvious errors.
|-
| '''Focused''' || Examination that uses a representative sample of assessment objects (by type and number within type) '''and other specific assessment objects deemed particularly important to achieving the assessment objective''' to provide a level of coverage necessary for determining whether the security safeguards are implemented and free of obvious errors '''and whether there are increased grounds for confidence that the safeguards are implemented correctly and operating as intended'''.
|-
| '''Comprehensive''' || Examination that uses a '''sufficiently large''' sample of assessment objects (by type and number within type) and other specific assessment objects deemed particularly important to achieving the assessment objective to provide a level of coverage necessary for determining whether the security safeguards are implemented and free of obvious errors and whether there are '''further''' increased grounds for confidence that the safeguards are implemented correctly and operating as intended '''on an ongoing and consistent basis, and that there is support for continuous improvement in the effectiveness of the safeguards'''.
|-
! colspan="2" | Discussion
|-
| colspan="2" | Typical assessor actions may include, for example: reviewing information security policies, plans, and procedures; analyzing system design documentation and interface specifications; observing system backup operations; reviewing training records; reviewing audit records; observing incident response activities; studying technical manuals and user/administrator guides; checking, studying, or observing the operation of an information technology mechanism in the system hardware or software; or checking, studying, or observing physical security measures related to the operation of a system.
|}

=== Table D-2: Interview Assessment Method ===

{| class="wikitable"
|-
! colspan="2" | Method: INTERVIEW
|-
| colspan="2" | The process of conducting discussions with individuals or groups of individuals in an organization to facilitate understanding, achieve clarification, or lead to the location of evidence. The results are used to support the determination of security safeguard existence, functionality, correctness, completeness, and potential for improvement over time.
|-
! Objects !! Description
|-
| ''Individuals or Groups'' || Examples: Personnel with risk assessment responsibilities; personnel with information security responsibilities; system or network administrators; personnel with account management responsibilities.
|-
! Attribute: Depth !! Description
|-
| '''Basic''' || Interview that consists of broad-based, high-level discussions with individuals or groups of individuals. This type of interview is conducted using a set of generalized, high-level questions. Basic interviews provide a level of understanding of the security safeguards necessary for determining whether the safeguards are implemented and free of obvious errors.
|-
| '''Focused''' || Interview that consists of broad-based, high-level discussions '''and more in-depth discussions in specific areas''' with individuals or groups of individuals. This type of interview is conducted using a set of generalized, high-level questions '''and more in-depth questions in specific areas where responses indicate a need for more in-depth investigation'''. Focused interviews provide a level of understanding of the security safeguards necessary for determining whether the safeguards are implemented and free of obvious errors '''and whether there are increased grounds for confidence that the safeguards are implemented correctly and operating as intended'''.
|-
| '''Comprehensive''' || Interview that consists of broad-based, high-level discussions and more in-depth, '''probing''' discussions in specific areas with individuals or groups of individuals. This type of interview is conducted using a set of generalized, high-level questions and more in-depth, '''probing''' questions in specific areas where responses indicate a need for more in-depth investigation. '''Comprehensive''' interviews provide a level of understanding of the security safeguards necessary for determining whether the safeguards are implemented and free of obvious errors and whether there are '''further''' increased grounds for confidence that the safeguards are implemented correctly and operating as intended '''on an ongoing and consistent basis, and that there is support for continuous improvement in the effectiveness of the safeguards'''.
|-
! Attribute: Coverage !! Description
|-
| colspan="2" | Addresses the scope or breadth of the interview process and includes the types of individuals to be interviewed by role and responsibility; the number of individuals to be interviewed by type; and specific individuals to be interviewed.<ref>The organization, considering a variety of factors (e.g., available resources, importance of the assessment, the organization's overall assessment goals and objectives), confers with assessors and provides direction on the type, number, and specific individuals to be interviewed for the attribute value described.</ref>
|-
| '''Basic''' || Interview that uses a representative sample of individuals in organizational roles to provide a level of coverage necessary for determining whether the security safeguards are implemented and free of obvious errors.
|-
| '''Focused''' || Interview that uses a representative sample of individuals in organizational roles '''and other specific individuals deemed particularly important to achieving the assessment objective''' to provide a level of coverage necessary for determining whether the security safeguards are implemented and free of obvious errors '''and whether there are increased grounds for confidence that the safeguards are implemented correctly and operating as intended'''.
|-
| '''Comprehensive''' || Interview that uses a '''sufficiently large''' sample of individuals in organizational roles and other specific individuals deemed particularly important to achieving the assessment objective to provide a level of coverage necessary for determining whether the security safeguards are implemented and free of obvious errors and whether there are '''further''' increased grounds for confidence that the safeguards are implemented correctly and operating as intended '''on an ongoing and consistent basis, and that there is support for continuous improvement in the effectiveness of the safeguards'''.
|-
! colspan="2" | Discussion
|-
| colspan="2" | Typical assessor actions may include, for example, interviewing chief executive officers, chief information officers, senior information security officers, information owners, system and mission owners, system security officers, system security managers, personnel officers, human resource managers, network and system administrators, facilities managers, training officers, physical security officers, system operators, site managers, and users.
|}

=== Table D-3: Test Assessment Method ===

{| class="wikitable"
|-
! colspan="2" | Method: TEST
|-
| colspan="2" | The process of exercising one or more assessment objects under specified conditions to compare actual with expected behavior. The results are used to support the determination of security safeguard existence, functionality, correctness, completeness, and potential for improvement over time.<ref>Testing is typically used to determine if mechanisms or activities meet a set of predefined specifications. Testing can also be performed to determine characteristics of a security or privacy control that are not commonly associated with predefined specifications, with an example of such testing being penetration testing.</ref>
|-
! Objects !! Description
|-
| ''Mechanisms'' || Examples: hardware, software, firmware.
|-
| ''Activities'' || Examples: system operations, administration, management; exercises.
|-
! Attribute: Depth !! Description
|-
| '''Basic''' || Test methodology (also known as ''black box'' testing) that assumes no knowledge of the internal structure and implementation detail of the assessment object. This type of testing is conducted using a functional specification for mechanisms and a high-level process description for activities. Basic testing provides a level of understanding of the security safeguards necessary for determining whether the safeguards are implemented and free of obvious errors.
|-
| '''Focused''' || Test methodology (also known as ''gray box'' testing) that assumes '''some''' knowledge of the internal structure and implementation detail of the assessment object. This type of testing is conducted using a functional specification '''and limited system architectural information (e.g., high-level design)''' for mechanisms and a high-level process description '''and high-level description of integration into the operational environment''' for activities. Focused testing provides a level of understanding of the security safeguards necessary for determining whether the safeguards are implemented and free of obvious errors '''and whether there are increased grounds for confidence that the safeguards are implemented correctly and operating as intended'''.
|-
| '''Comprehensive''' || Test methodology (also known as ''white box'' testing) that assumes '''explicit and substantial''' knowledge of the internal structure and implementation detail of the assessment object. This type of testing is conducted using a functional specification, '''extensive''' system architectural information (e.g., high-level design, '''low-level design''') and '''implementation representation (e.g., source code, schematics)''' for mechanisms and a high-level process description and '''detailed''' description of integration into the operational environment for activities. Comprehensive testing provides a level of understanding of the security safeguards necessary for determining whether the safeguards are implemented and free of obvious errors and whether there are '''further''' increased grounds for confidence that the safeguards are implemented correctly and operating as intended '''on an ongoing and consistent basis, and that there is support for continuous improvement in the effectiveness of the safeguards'''.
|-
! Attribute: Coverage !! Description
|-
| colspan="2" | Addresses the scope or breadth of the testing process and includes the types of assessment objects to be tested; the number of objects to be tested by type; and specific objects to be tested.
|-
| '''Basic''' || Testing that uses a representative sample of assessment objects by type and number within type, to provide a level of coverage necessary for determining whether the security safeguards are implemented and free of obvious errors.
|-
| '''Focused''' || Testing that uses a representative sample of assessment objects by type and number within type, '''and other specific assessment objects deemed particularly important to achieving the assessment objective''' to provide a level of coverage necessary for determining whether the security safeguards are implemented and free of obvious errors '''and whether there are increased grounds for confidence that the safeguards are implemented correctly and operating as intended'''.
|-
| '''Comprehensive''' || Testing that uses a '''sufficiently large''' sample of assessment objects by type and number within type, and other specific assessment objects deemed particularly important to achieving the assessment objective to provide a level of coverage necessary for determining whether the security safeguards are implemented and free of obvious errors and whether there are '''further''' increased grounds for confidence that the safeguards are implemented correctly and operating as intended '''on an ongoing and consistent basis, and that there is support for continuous improvement in the effectiveness of the safeguards'''.
|-
! colspan="2" | Discussion
|-
| colspan="2" | Typical assessor actions may include, for example: testing access control, identification and authentication, and audit mechanisms; testing security configuration settings; testing physical access control devices; conducting penetration testing of key system components; testing system backup operations; testing incident response capability; and exercising vulnerability scanning capability.
|}

== Notes ==
<references/>

[[Category:NIST Special Publications]]
[[Category:Cybersecurity standards]]
[[Category:Controlled Unclassified Information]]

NIST SP 800-17 R2

2026-07-27T02:57:21Z

David: Created page with "{{DISPLAYTITLE:NIST Special Publication 800-171, Revision 2}} '''NIST Special Publication 800-171, Revision 2''' — ''Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations'' — is a National Institute of Standards and Technology (NIST) publication that provides federal agencies with recommended security requirements for protecting the confidentiality of Controlled Unclassified Information (CUI) when that information resides in n..."

{{DISPLAYTITLE:NIST Special Publication 800-171, Revision 2}}
'''NIST Special Publication 800-171, Revision 2''' — ''Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations'' — is a [[National Institute of Standards and Technology]] (NIST) publication that provides federal agencies with recommended security requirements for protecting the confidentiality of [[Controlled Unclassified Information]] (CUI) when that information resides in nonfederal systems and organizations.

{{Infobox publication
| title = Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
| series = NIST Special Publication 800-171
| revision = Revision 2
| authors = Ron Ross, Victoria Pillitteri, Kelley Dempsey, Mark Riddle, Gary Guissanie
| publisher = National Institute of Standards and Technology, U.S. Department of Commerce
| publication_date = February 2020 (includes updates as of January 28, 2021)
| doi = 10.6028/NIST.SP.800-171r2
| pages = 113
| status = Withdrawn May 14, 2024; superseded by NIST SP 800-171 Revision 3
}}

== Withdrawal notice ==
{{Ambox
| type = notice
| text = This publication has been '''withdrawn (archived)''' and is provided solely for historical purposes.
}}

{| class="wikitable"
|-
! Withdrawn publication !! Detail
|-
| Series/Number || NIST SP 800-171r2
|-
| Title || Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
|-
| Publication date(s) || February 2020 (includes updates as of January 28, 2021)
|-
| Withdrawal date || May 14, 2024
|-
| Withdrawal note || NIST SP 800-171r2 is withdrawn and superseded in its entirety by NIST SP 800-171r3
|}

{| class="wikitable"
|-
! Superseding publication !! Detail
|-
| Series/Number || NIST SP 800-171r3
|-
| Title || Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
|-
| Author(s) || Ron Ross; Victoria Pillitteri
|-
| Publication date(s) || May 2024
|-
| URL/DOI || {{URL|https://doi.org/10.6028/NIST.SP.800-171r3}}
|}

Contact: Computer Security Division (Information Technology Laboratory). Related information: {{URL|https://csrc.nist.gov/pubs/sp/800/171/r2/upd1/final}}. Date updated: May 14, 2024.

== Front matter ==

=== Authority ===
This publication was developed by NIST to further its statutory responsibilities under the [[Federal Information Security Modernization Act]] (FISMA), 44 U.S.C. § 3551 ''et seq.'', Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems. Such information security standards and guidelines do not apply to national security systems without the express approval of the appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of [[Office of Management and Budget]] (OMB) Circular A-130.

Nothing in the publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority, nor should the guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, the OMB Director, or any other federal official. The publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States, although attribution is appreciated by NIST.

'''National Institute of Standards and Technology Special Publication 800-171, Revision 2''' 
Natl. Inst. Stand. Technol. Spec. Publ. 800-171, Revision 2, 113 pages (February 2020) 
CODEN: NSPUE2 
{{URL|https://doi.org/10.6028/NIST.SP.800-171r2}}

=== Reports on Computer Systems Technology ===
The National Institute of Standards and Technology (NIST) Information Technology Laboratory (ITL) promotes the U.S. economy and public welfare by providing technical leadership for the nation's measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof-of-concept implementations, and technical analyses to advance the development and productive use of information technology. ITL's responsibilities include developing management, administrative, technical, and physical standards and guidelines for the cost-effective security of other than national-security-related information in federal information systems. The Special Publication 800-series reports on ITL's research, guidelines, and outreach efforts in information systems security and privacy and its collaborative activities with industry, government, and academic organizations.

=== Abstract ===
The protection of Controlled Unclassified Information (CUI) resident in nonfederal systems and organizations is of paramount importance to federal agencies and can directly impact the ability of the federal government to successfully conduct its essential missions and functions. This publication provides agencies with recommended security requirements for protecting the confidentiality of CUI when the information is resident in nonfederal systems and organizations; when the nonfederal organization is not collecting or maintaining information on behalf of a federal agency or using or operating a system on behalf of an agency; and where there are no specific safeguarding requirements for protecting the confidentiality of CUI prescribed by the authorizing law, regulation, or governmentwide policy for the CUI category listed in the CUI Registry. The requirements apply to all components of nonfederal systems and organizations that process, store, and/or transmit CUI, or that provide protection for such components. The security requirements are intended for use by federal agencies in contractual vehicles or other agreements established between those agencies and nonfederal organizations.

'''Keywords:''' Basic Security Requirement; Contractor Systems; Controlled Unclassified Information; CUI Registry; Derived Security Requirement; Executive Order 13556; FIPS Publication 199; FIPS Publication 200; FISMA; NIST Special Publication 800-53; Nonfederal Organizations; Nonfederal Systems; Security Assessment; Security Control; Security Requirement.

=== Acknowledgements ===
The authors wish to recognize the scientists, engineers, and research staff from the Computer Security Division and Applied Cybersecurity Division for their exceptional contributions in helping to improve the content of the publication, and thank Pat O'Reilly, Jim Foti, and Jeff Brewer of the NIST web team for their administrative support. The authors also acknowledge the contributions from individuals and organizations in the public and private sectors, nationally and internationally, whose comments improved the overall quality, thoroughness, and usefulness of the publication.

'''Historical contributions''' to previous versions of Special Publication 800-171, since its inception in June 2015, were made by Carol Bales, Matthew Barrett, Jon Boyens, Devin Casey, Christian Enloe, Peggy Himes, Robert Glenn, Elizabeth Lennon, Vicki Michetti, Dorian Pappas, Karen Quigg, Mary Thomas, Matthew Scholl, Murugiah Souppaya, Patricia Toth, and Patrick Viscuso.

=== Patent disclosure notice ===
The Information Technology Laboratory (ITL) requested that holders of patent claims whose use may be required for compliance with the guidance or requirements of this publication disclose such patent claims to ITL. Holders of patents are not obligated to respond to ITL's calls for patents, and ITL has not undertaken a patent search to identify which, if any, patents may apply to the publication. As of the date of publication and following the call(s) for identification of patent claims, no such patent claims had been identified to ITL. No representation is made or implied by ITL that licenses are not required to avoid patent infringement in the use of the publication.

=== Cautionary note ===
FISMA of 2014 requires federal agencies to identify and provide information security protections commensurate with the risk resulting from the unauthorized access, use, disclosure, disruption, modification, or destruction of information collected or maintained by or on behalf of an agency, or of information systems used or operated by an agency, a contractor of an agency, or another organization on behalf of an agency. This publication focuses on protecting the confidentiality of CUI in nonfederal systems and organizations and recommends specific security requirements to achieve that objective. It does not change the requirements set forth in FISMA, nor does it alter the responsibility of federal agencies to comply with the full provisions of the statute, OMB policy, and supporting NIST standards and guidelines.

The requirements recommended in the publication are derived from [[FIPS 200]] and the moderate security control baseline in [[NIST Special Publication 800-53|SP 800-53]], and are based on the CUI regulation (32 CFR 2002). These requirements and controls have, over time, been determined to provide the necessary protection for federal information and systems covered under FISMA. The tailoring criteria applied to the FIPS 200 requirements and SP 800-53 controls are not an endorsement of eliminating those requirements and controls; rather, the tailoring focuses on protecting CUI from unauthorized disclosure in nonfederal systems and organizations. Because the security requirements are derived from the NIST publications listed above, organizations should not assume that satisfying these particular requirements will automatically satisfy the requirements and controls in FIPS 200 and SP 800-53.

In addition to confidentiality, the objectives of integrity and availability remain a high priority for organizations concerned with establishing and maintaining a comprehensive information security program. While the primary purpose of this publication is to define requirements to protect the confidentiality of CUI, confidentiality and integrity are closely related since many underlying security mechanisms at the system level support both objectives; the basic and derived security requirements therefore provide protection from both unauthorized disclosure and unauthorized modification of CUI. Organizations that must comply with the recommendations in this publication are strongly advised to review the complete listing of controls in the moderate baseline in Appendix E to ensure their security plans and control deployments provide the necessary and sufficient protection against cyber and kinetic threats to organizational missions and business operations.

=== CUI security requirements ===
The recommended security requirements contained in this publication are only applicable to a nonfederal system or organization when mandated by a federal agency in a contract, grant, or other agreement. The security requirements apply to the components of nonfederal systems that process, store, or transmit CUI, or that provide security protection for such components.

=== Framework for Improving Critical Infrastructure Cybersecurity ===
Organizations that have implemented, or plan to implement, the NIST [[Framework for Improving Critical Infrastructure Cybersecurity]] (Cybersecurity Framework) can find in Appendix D a direct mapping of the CUI security requirements to the security controls in SP 800-53 and [[ISO/IEC 27001]]. These controls are also mapped to the categories and subcategories associated with the Cybersecurity Framework's core functions: Identify, Protect, Detect, Respond, and Recover. The mappings can be useful to organizations that wish to demonstrate compliance with the security requirements in the context of an established information security program built around the NIST or ISO/IEC security controls.

'''Additional resources:'''
* Mapping security controls to the Cybersecurity Framework: {{URL|https://csrc.nist.gov/publications/detail/nistir/8170/draft}}
* Mapping CUI security requirements to the Cybersecurity Framework: {{URL|https://csrc.nist.gov/projects/cybersecurity-framework/informative-reference-catalog/details/1}}

=== Errata ===
This table contains changes that have been incorporated into the publication since its original February 2020 release. Errata updates can include corrections, clarifications, or other minor changes that are either editorial or substantive in nature. All entries below are dated January 28, 2021.

{| class="wikitable"
|-
! Location !! Type !! Change
|-
| Front matter (Cautionary note) || Editorial || Changed "The requirements apply only" to "The security requirements apply"
|-
| Chapter One, §1.1, paragraph 1 || Editorial || Deleted the sentence "The requirements apply only to components of nonfederal systems that process, store, or transmit CUI, or that provide security protection for such components."
|-
| Chapter One, §1.1, paragraph 2 || Editorial || Added a passage on the scope of applicability and on isolating designated system components into a separate CUI security domain
|-
| Chapter One, §1.1, paragraph 3 || Editorial || Changed "The requirements are" to "The recommended security requirements in this publication are"
|-
| Chapter One, §1.1, paragraph 6 || Editorial || Deleted a passage on isolating CUI into its own security domain (superseded by the paragraph 2 addition above)
|}

== Table of contents ==
* [[#Chapter One: Introduction|Chapter One: Introduction]]
** 1.1 Purpose and Applicability
** 1.2 Target Audience
** 1.3 Organization of this Special Publication
* [[#Chapter Two: The Fundamentals|Chapter Two: The Fundamentals]]
** 2.1 Basic Assumptions
** 2.2 Development of Security Requirements
* [[#Chapter Three: The Requirements|Chapter Three: The Requirements]]
** 3.1 Access Control
** 3.2 Awareness and Training
** 3.3 Audit and Accountability
** 3.4 Configuration Management
** 3.5 Identification and Authentication
** 3.6 Incident Response
** 3.7 Maintenance
** 3.8 Media Protection
** 3.9 Personnel Security
** 3.10 Physical Protection
** 3.11 Risk Assessment
** 3.12 Security Assessment
** 3.13 System and Communications Protection
** 3.14 System and Information Integrity
* [[#Appendix A: References|Appendix A: References]]
* [[#Appendix B: Glossary|Appendix B: Glossary]]
* [[#Appendix C: Acronyms|Appendix C: Acronyms]]
* [[#Appendix D: Mapping Tables|Appendix D: Mapping Tables]]
* [[#Appendix E: Tailoring Criteria|Appendix E: Tailoring Criteria]]

== Chapter One: Introduction ==
''The need to protect Controlled Unclassified Information''

Today, more than at any time in history, the federal government relies on external service providers to help carry out a wide range of federal missions and business functions using information systems.<ref>An information system is a discrete set of information resources organized expressly for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information. Information systems also include specialized systems, for example: industrial/process control systems, cyber-physical systems, embedded systems, and devices. The term ''system'' is used throughout this publication to represent all types of computing platforms that can process, store, or transmit CUI.</ref> Many federal contractors process, store, and transmit sensitive federal information to support the delivery of essential products and services to federal agencies (e.g., providing financial services; providing web and electronic mail services; processing security clearances or healthcare data; providing cloud services; and developing communications, satellite, and weapons systems). Federal information is frequently provided to or shared with entities such as state and local governments, colleges and universities, and independent research organizations. The protection of sensitive federal information while residing in nonfederal systems<ref>A federal information system is a system that is used or operated by an executive agency, by a contractor of an executive agency, or by another organization on behalf of an executive agency. A system that does not meet such criteria is a nonfederal system.</ref> and organizations is of paramount importance to federal agencies, and can directly impact the ability of the federal government to carry out its designated missions and business operations.

The protection of unclassified federal information in nonfederal systems and organizations is dependent on the federal government providing a process for identifying the different types of information that are used by federal agencies. Executive Order 13556 established a governmentwide Controlled Unclassified Information (CUI)<ref>Controlled Unclassified Information is any information that law, regulation, or governmentwide policy requires to have safeguarding or disseminating controls, excluding information that is classified under Executive Order 13526 or any predecessor or successor order, or the Atomic Energy Act of 1954, as amended.</ref> Program to standardize the way the executive branch handles unclassified information that requires protection.<ref>Executive Order 13556 designated the National Archives and Records Administration (NARA) as the Executive Agent to implement the CUI Program.</ref> Only information that requires safeguarding or dissemination controls pursuant to federal law, regulation, or governmentwide policy may be designated as CUI. The CUI Program is designed to address several deficiencies in managing and protecting unclassified information, including inconsistent markings, inadequate safeguarding, and needless restrictions, both by standardizing procedures and by providing common definitions through a CUI Registry maintained by NARA. The CUI Registry is the online repository for information, guidance, policy, and requirements on handling CUI, including issuances by the CUI Executive Agent. It identifies approved CUI categories, provides general descriptions for each, identifies the basis for controls, and sets out procedures for the use of CUI, including marking, safeguarding, transporting, disseminating, reusing, and disposing of the information.

Executive Order 13556 also required that the CUI Program emphasize openness, transparency, and uniformity of governmentwide practices, and that implementation take place consistent with applicable OMB policies and federal standards and guidelines issued by NIST. The federal CUI regulation,<ref>32 CFR 2002 was issued on September 14, 2016, and became effective on November 14, 2016.</ref> developed by the CUI Executive Agent, provides guidance to federal agencies on the designation, safeguarding, dissemination, marking, decontrolling, and disposition of CUI, establishes self-inspection and oversight requirements, and delineates other facets of the program.

=== 1.1 Purpose and Applicability ===
The purpose of this publication is to provide federal agencies with recommended security requirements<ref>The term ''requirements'' can be used in different contexts. In federal information security and privacy policy, it generally refers to information security and privacy obligations imposed on organizations — for example, OMB Circular A-130 imposes a series of such requirements with which federal agencies must comply. The term is also used in this guideline in a broader sense to refer to an expression of the set of stakeholder protection needs for a particular system or organization, which may be derived from many sources (e.g., laws, executive orders, directives, regulations, policies, standards, mission and business needs, or risk assessments). As used in this guideline, the term includes both legal and policy requirements as well as the broader set of stakeholder protection needs.</ref> for protecting the confidentiality of CUI: (1) when the CUI is resident in a nonfederal system and organization; (2) when the nonfederal organization is not collecting or maintaining information on behalf of a federal agency or using or operating a system on behalf of an agency;<ref>Nonfederal organizations that collect or maintain information on behalf of a federal agency, or that use or operate a system on behalf of an agency, must comply with the requirements in FISMA, including the requirements in FIPS 200 and the security controls in SP 800-53 (see 44 U.S.C. § 3554(a)(1)(A)).</ref> and (3) where there are no specific safeguarding requirements for protecting the confidentiality of CUI prescribed by the authorizing law, regulation, or governmentwide policy for the CUI category listed in the CUI Registry.<ref>The requirements in this publication can be used to comply with the FISMA requirement for senior agency officials to provide information security for the information that supports the operations and assets under their control, including CUI resident in nonfederal systems and organizations (see 44 U.S.C. § 3554(a)(1)(A) and (a)(2)).</ref>

The requirements apply to components of nonfederal systems that process, store, or transmit CUI, or that provide security protection for such components.<ref>System components include, for example: mainframes, workstations, servers; input and output devices; network components; operating systems; virtual machines; and applications.</ref> If nonfederal organizations designate specific system components for the processing, storage, or transmission of CUI, those organizations may limit the scope of the security requirements by isolating the designated system components in a separate CUI security domain. Isolation can be achieved by applying architectural and design concepts (e.g., implementing subnetworks with firewalls or other boundary protection devices and using information flow control mechanisms). Security domains may employ physical separation, logical separation, or a combination of both. This approach can provide adequate security for the CUI and avoid increasing the organization's security posture to a level beyond that which it requires for protecting its missions, operations, and assets.

The recommended security requirements in this publication are intended for use by federal agencies in appropriate contractual vehicles or other agreements established between those agencies and nonfederal organizations. In CUI guidance and the CUI Federal Acquisition Regulation (FAR),<ref>NARA, as the CUI Executive Agent, plans to sponsor a single FAR clause that will apply the requirements of the federal CUI regulation and NIST Special Publication 800-171 to contractors. Until the FAR clause is in place, the requirements in NIST Special Publication 800-171 may be referenced in federal contracts consistent with federal law and regulatory requirements.</ref> the CUI Executive Agent will address determining compliance with security requirements.<ref>NIST Special Publication 800-171A provides assessment procedures to determine compliance with the CUI security requirements.</ref>

In accordance with the federal CUI regulation, federal agencies using federal systems to process, store, or transmit CUI must, at a minimum, comply with:
* Federal Information Processing Standards (FIPS) Publication 199, ''Standards for Security Categorization of Federal Information and Information Systems'' (moderate confidentiality);<ref>FIPS 199 defines three values of potential impact (i.e., low, moderate, high) on organizations, assets, or individuals in the event of a breach of security (e.g., a loss of confidentiality).</ref>
* Federal Information Processing Standards (FIPS) Publication 200, ''Minimum Security Requirements for Federal Information and Information Systems'';
* NIST Special Publication 800-53, ''Security and Privacy Controls for Federal Information Systems and Organizations''; and
* NIST Special Publication 800-60, ''Guide for Mapping Types of Information and Information Systems to Security Categories''.

The responsibility of federal agencies to protect CUI does not change when such information is shared with nonfederal partners. Therefore, a similar level of protection is needed when CUI is processed, stored, or transmitted by nonfederal organizations using nonfederal systems.<ref>A nonfederal organization is any entity that owns, operates, or maintains a nonfederal system. Examples include: state, local, and tribal governments; colleges and universities; and contractors.</ref> The recommended requirements for safeguarding CUI in nonfederal systems and organizations are derived from the above authoritative federal standards and guidelines to maintain a consistent level of protection. However, recognizing that the scope of the safeguarding requirements in the federal CUI regulation is limited to the security objective of confidentiality (i.e., not directly addressing integrity and availability), and that some of the security requirements expressed in the NIST standards and guidelines are uniquely federal, the requirements in this publication have been tailored for nonfederal entities.

The tailoring criteria described in Chapter Two are not intended to reduce or minimize the federal requirements for safeguarding CUI as expressed in the federal CUI regulation. Rather, the intent is to express the requirements in a manner that allows for and facilitates equivalent safeguarding measures within nonfederal systems and organizations and does not diminish the level of protection of CUI required for moderate confidentiality. Additional or differing requirements, other than those described in this publication, may be applied only when based on law, regulation, or governmentwide policy and when indicated in the CUI Registry as CUI-specified, or when an agreement establishes requirements to protect CUI Basic<ref>CUI Basic is defined in the CUI Registry.</ref> at higher than moderate confidentiality. The provision of safeguarding requirements for CUI in a specified category will be addressed by NARA in its CUI guidance and in the CUI FAR, and reflected as specific requirements in contracts or other agreements. Nonfederal organizations may use the same CUI infrastructure for multiple government contracts or agreements, if that infrastructure meets the safeguarding requirements for the organization's CUI-related contracts and/or agreements, including any specific safeguarding required or permitted by the authorizing law, regulation, or governmentwide policy.

=== 1.2 Target Audience ===
This publication serves a diverse group of individuals and organizations in both the public and private sectors, including, but not limited to, individuals with:
* System development life cycle responsibilities (e.g., program managers, mission/business owners, information owners/stewards, system designers and developers, system/security engineers, systems integrators);
* Acquisition or procurement responsibilities (e.g., contracting officers);
* System, security, or risk management and oversight responsibilities (e.g., authorizing officials, chief information officers, chief information security officers, system owners, information security managers); and
* Security assessment and monitoring responsibilities (e.g., auditors, system evaluators, assessors, independent verifiers/validators, analysts).

These roles and responsibilities can be viewed from two distinct perspectives: the federal perspective, as the entity establishing and conveying the security requirements in contractual vehicles or other inter-organizational agreements; and the nonfederal perspective, as the entity responding to and complying with the security requirements set forth in contracts or agreements.

=== 1.3 Organization of this Special Publication ===
The remainder of this special publication is organized as follows:
* Chapter Two describes the fundamental assumptions and methodology used to develop the security requirements for protecting the confidentiality of CUI; the format and structure of the requirements; and the tailoring criteria applied to the NIST standards and guidelines to obtain the requirements.
* Chapter Three describes the fourteen families of security requirements for protecting the confidentiality of CUI in nonfederal systems and organizations.
* Supporting appendices provide additional information related to the protection of CUI in nonfederal systems and organizations, including general references; definitions and terms; acronyms; mapping tables relating security requirements to the security controls in SP 800-53 and ISO/IEC 27001; and tailoring actions applied to the moderate security control baseline.

<references/>

== Chapter Two: The Fundamentals ==
''Assumptions and methodology for developing security requirements''

This chapter describes the assumptions and the methodology used to develop the recommended security requirements to protect CUI in nonfederal systems and organizations; the structure of the basic and derived security requirements; and the tailoring criteria applied to the federal information security requirements and controls.

=== 2.1 Basic Assumptions ===
The recommended security requirements described in this publication have been developed based on three fundamental assumptions:
* Statutory and regulatory requirements for the protection of CUI are consistent, whether such information resides in federal systems or nonfederal systems, including the environments in which those systems operate;
* Safeguards implemented to protect CUI are consistent in both federal and nonfederal systems and organizations; and
* The confidentiality impact value for CUI is no less than FIPS 199 moderate.<ref>The moderate impact value defined in FIPS 199 may become part of a moderate-impact system in FIPS 200, which requires the use of the moderate baseline in SP 800-53 as the starting point for tailoring actions.</ref><ref>In accordance with 32 CFR 2002, CUI is categorized at no less than the moderate confidentiality impact value. However, when federal law, regulation, or governmentwide policy establishing control of the CUI specifies controls that differ from those of the moderate confidentiality baseline, those will be followed.</ref>

These assumptions reinforce the concept that federal information designated as CUI has the same intrinsic value and potential adverse impact if compromised — whether the information resides in a federal or a nonfederal organization. Thus, protecting the confidentiality of CUI is critical to the mission and business success of federal agencies and to the economic and national security interests of the nation. Additional assumptions affecting the development of the security requirements, and the expectation of federal agencies working with nonfederal entities, include:
* Nonfederal organizations have information technology infrastructures in place, and are not necessarily developing or acquiring systems specifically for processing, storing, or transmitting CUI;
* Nonfederal organizations have specific safeguarding measures in place to protect their information, which may also be sufficient to satisfy the security requirements;
* Nonfederal organizations may not have the necessary organizational structure or resources to satisfy every security requirement and may implement alternative, but equally effective, security measures to compensate for the inability to satisfy a requirement; and
* Nonfederal organizations can implement a variety of potential security solutions directly, or using external service providers (e.g., managed services), to satisfy security requirements.

'''Implementing a single, state security solution for CUI:''' Controlled Unclassified Information has the same value whether it is resident in a federal system that is part of a federal agency or a nonfederal system that is part of a nonfederal organization. Accordingly, the recommended security requirements in this publication are consistent with, and complementary to, the standards and guidelines used by federal agencies to protect CUI.

=== 2.2 Development of Security Requirements ===
The security requirements for protecting the confidentiality of CUI in nonfederal systems and organizations have a well-defined structure consisting of a basic security requirements section and a derived security requirements section. The basic security requirements are obtained from FIPS 200, which provides the high-level and fundamental security requirements for federal information and systems. The derived security requirements, which supplement the basic security requirements, are taken from the security controls in SP 800-53. Starting with the security requirements and controls in the moderate baseline (i.e., the minimum level of protection required for CUI in federal systems and organizations), the requirements and controls are tailored to eliminate requirements, controls, or parts of controls that are:
* Uniquely federal (i.e., primarily the responsibility of the federal government);
* Not directly related to protecting the confidentiality of CUI; or
* Expected to be routinely satisfied by nonfederal organizations without specification.<ref>The security requirements developed from the tailored FIPS 200 security requirements and the SP 800-53 moderate security control baseline represent a subset of the safeguarding measures necessary for a comprehensive information security program. The strength and quality of such programs in nonfederal organizations depend on the degree to which the organizations implement the security requirements and controls expected to be routinely satisfied without specification by the federal government, including security policies, procedures, and practices that support an effective risk-based information security program. Nonfederal organizations are encouraged to refer to Appendix E and SP 800-53 for a complete listing of security controls in the moderate baseline deemed out of scope for the security requirements in Chapter Three.</ref>

Appendix E provides a complete listing of security controls that support the CUI derived security requirements, and those controls that have been eliminated from the moderate baseline based on the CUI tailoring criteria described above.

The combination of the basic and derived security requirements captures the intent of FIPS 200 and SP 800-53 with respect to protecting the confidentiality of CUI in nonfederal systems and organizations. Appendix D provides informal mappings of the security requirements to the relevant security controls in SP 800-53 and ISO/IEC 27001. The mappings promote a better understanding of the CUI security requirements and are not intended to impose additional requirements on nonfederal organizations.

'''Example — structure of a CUI requirement (Media Protection family):'''

''Basic Security Requirements''
{| class="wikitable"
|-
! # !! Requirement
|-
| 3.8.1 || Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital.
|-
| 3.8.2 || Limit access to CUI on system media to authorized users.
|-
| 3.8.3 || Sanitize or destroy system media containing CUI before disposal or release for reuse.
|}

''Derived Security Requirements''
{| class="wikitable"
|-
! # !! Requirement
|-
| 3.8.4 || Mark media with necessary CUI markings and distribution limitations.
|-
| 3.8.5 || Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas.
|-
| 3.8.6 || Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards.
|-
| 3.8.7 || Control the use of removable media on system components.
|-
| 3.8.8 || Prohibit the use of portable storage devices when such devices have no identifiable owner.
|-
| 3.8.9 || Protect the confidentiality of backup CUI at storage locations.
|}

For ease of use, the security requirements are organized into fourteen families. Each family contains the requirements related to the general security topic of the family. The families are closely aligned with the minimum security requirements for federal information and systems described in FIPS 200. The contingency planning, system and services acquisition, and planning requirements are not included within the scope of this publication due to the tailoring criteria.<ref>Three exceptions include: a requirement to protect the confidentiality of system backups (derived from CP-9) from the contingency planning family; a requirement to develop and implement a system security plan (derived from PL-2) from the planning family; and a requirement to implement system security engineering principles (derived from SA-8) from the system and services acquisition family. These requirements are included in the CUI media protection, security assessment, and system and communications protection requirements families, respectively.</ref>

'''Table 1: Security requirement families'''
{| class="wikitable"
|-
! Family !! Family
|-
| Access Control || Media Protection
|-
| Awareness and Training || Personnel Security
|-
| Audit and Accountability || Physical Protection
|-
| Configuration Management || Risk Assessment
|-
| Identification and Authentication || Security Assessment
|-
| Incident Response || System and Communications Protection
|-
| Maintenance || System and Information Integrity
|}

A discussion section follows each CUI security requirement, providing additional information to facilitate implementation and assessment of the requirement. This information is derived primarily from the security control discussion sections in SP 800-53 and is provided to give organizations a better understanding of the mechanisms and procedures used to implement the controls that protect CUI. The discussion section is informative, not normative: it is not intended to extend the scope of a requirement or to influence the solutions organizations may use to satisfy it. The use of examples is notional, not exhaustive, and not reflective of the potential options available to organizations. The example below illustrates basic security requirement 3.8.3 with its supporting discussion section.

{| class="wikitable"
|-
! 3.8.3
| Sanitize or destroy system media containing CUI before disposal or release for reuse.
|-
! DISCUSSION
| This requirement applies to all system media, digital and non-digital, subject to disposal or reuse. Examples include: digital media found in workstations, network components, scanners, copiers, printers, notebook computers, and mobile devices; and non-digital media such as paper and microfilm. The sanitization process removes information from the media such that the information cannot be retrieved or reconstructed. Sanitization techniques, including clearing, purging, cryptographic erase, and destruction, prevent the disclosure of information to unauthorized individuals when such media is released for reuse or disposal.

Organizations determine the appropriate sanitization methods, recognizing that destruction may be necessary when other methods cannot be applied to the media requiring sanitization. Organizations use discretion in employing sanitization techniques and procedures for media containing information that is in the public domain, is publicly releasable, or is deemed to have no adverse impact on organizations or individuals if released for reuse or disposal. Sanitization of non-digital media includes destruction, removing CUI from documents, or redacting selected sections or words from a document by obscuring the redacted sections or words in a manner equivalent in effectiveness to removing the words or sections from the document. NARA policy and guidance control sanitization processes for controlled unclassified information.

''(SP 800-88 provides guidance on media sanitization.)''
|}

<references/>

== Chapter Three: The Requirements ==
''Security requirements for protecting the confidentiality of CUI''

This chapter describes fourteen families of recommended security requirements for protecting the confidentiality of CUI in nonfederal systems and organizations.<ref>The security objectives of confidentiality and integrity are closely related since many of the underlying security mechanisms at the system level support both objectives. Therefore, the basic and derived security requirements in this publication provide protection from unauthorized disclosure and unauthorized modification of CUI.</ref> The security controls from SP 800-53 associated with the basic and derived requirements are listed in Appendix D.<ref>The security control references in Appendix D are included to promote a better understanding of the recommended security requirements and do not expand the scope of the requirements.</ref> Organizations can use the NIST publication to obtain additional, non-prescriptive information related to the recommended security requirements (e.g., explanatory information in the discussion section for each of the referenced security controls, mapping tables to ISO/IEC 27001 security controls, and a catalog of optional controls that can be used to specify additional security requirements, if needed). This information can help clarify or interpret the requirements in the context of mission and business requirements, operational environments, or assessments of risk. Nonfederal organizations can implement a variety of potential security solutions, either directly or using managed services, to satisfy the security requirements, and may implement alternative, but equally effective, security measures to compensate for the inability to satisfy a requirement.<ref>To promote consistency, transparency, and comparability, the compensatory security measures selected by organizations are based on or derived from existing and recognized security standards and control sets, including, for example, ISO/IEC 27001 or SP 800-53.</ref>

'''Discussion section:''' The discussion section associated with each CUI requirement is informative, not normative. It is not intended to extend the scope of a requirement or to influence the solutions organizations may use to satisfy a requirement. In addition, the use of examples is notional, not exhaustive, and not reflective of potential options available to organizations.

Nonfederal organizations describe, in a system security plan, how the security requirements are met or how organizations plan to meet the requirements and address known and anticipated threats. The system security plan describes: the system boundary; operational environment; how security requirements are implemented; and the relationships with or connections to other systems. Nonfederal organizations develop plans of action that describe how unimplemented security requirements will be met and how any planned mitigations will be implemented. Organizations can document the system security plan and the plan of action as separate or combined documents and in any chosen format.<ref>NIST's CUI project provides supplemental material for Special Publication 800-171, including templates for system security plans and plans of action.</ref>

When requested, the system security plan (or extracts thereof) and the associated plans of action for any planned implementations or mitigations are submitted to the responsible federal agency/contracting office to demonstrate the nonfederal organization's implementation or planned implementation of the security requirements. Federal agencies may consider the submitted system security plans and plans of action as critical inputs to a risk management decision to process, store, or transmit CUI on a system hosted by a nonfederal organization, and whether it is advisable to pursue an agreement or contract with the nonfederal organization.

The recommended security requirements in this publication apply only to the components of nonfederal systems that process, store, or transmit CUI or that provide protection for such components. Some systems, including specialized systems (e.g., industrial/process control systems, medical devices, computer numerical control machines), may have limitations on the application of certain security requirements. To accommodate such issues, the system security plan, as reflected in requirement 3.12.4, is used to describe any enduring exceptions to the security requirements. Individual, isolated, or temporary deficiencies are managed through plans of action, as reflected in requirement 3.12.2.

'''The meaning of ''organizational systems'':''' The term ''organizational system'' is used in many of the recommended CUI security requirements in this publication. This term has a specific meaning regarding the scope of applicability for the security requirements: the requirements apply only to the components of nonfederal systems that process, store, or transmit CUI, or that provide protection for the system components. The appropriate scoping for the CUI security requirements is an important factor in determining protection-related investment decisions and managing security risk for nonfederal organizations that have the responsibility of safeguarding CUI.

=== 3.1 Access Control ===
==== Basic Security Requirements ====
;3.1.1: Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems).
:'''Discussion:''' Access control policies (e.g., identity- or role-based policies, control matrices, and cryptography) control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, and domains) in systems. Access enforcement mechanisms can be employed at the application and service level to provide increased information security. Other systems include systems internal and external to the organization. This requirement focuses on account management for systems and applications. The definition of and enforcement of access authorizations, other than those determined by account type (e.g., privileged versus non-privileged), are addressed in requirement 3.1.2.

;3.1.2: Limit system access to the types of transactions and functions that authorized users are permitted to execute.
:'''Discussion:''' Organizations may choose to define access privileges or other attributes by account, by type of account, or a combination of both. System account types include individual, shared, group, system, anonymous, guest, emergency, developer, manufacturer, vendor, and temporary. Other attributes required for authorizing access include restrictions on time-of-day, day-of-week, and point-of-origin. In defining other account attributes, organizations consider system-related requirements (e.g., scheduled system upgrades and maintenance) and mission or business requirements (e.g., time zone differences, customer requirements, remote access to support travel requirements).

==== Derived Security Requirements ====
;3.1.3: Control the flow of CUI in accordance with approved authorizations.
:'''Discussion:''' Information flow control regulates where information can travel within a system and between systems (versus who can access the information), without explicit regard to subsequent accesses to that information. Flow control restrictions include: keeping export-controlled information from being transmitted in the clear to the Internet; blocking outside traffic that claims to be from within the organization; restricting requests to the Internet that are not from the internal web proxy server; and limiting information transfers between organizations based on data structures and content.

Organizations commonly use information flow control policies and enforcement mechanisms to control the flow of information between designated sources and destinations (e.g., networks, individuals, and devices) within systems and between interconnected systems. Flow control is based on characteristics of the information or the information path. Enforcement occurs in boundary protection devices (e.g., gateways, routers, guards, encrypted tunnels, firewalls) that employ rule sets or configuration settings that restrict system services, provide packet-filtering based on header information, or message-filtering based on message content. Organizations also consider the trustworthiness of filtering and inspection mechanisms critical to information flow enforcement.

Transferring information between systems representing different security domains with different security policies introduces the risk that such transfers violate one or more domain security policies. In such situations, information owners or stewards provide guidance at designated policy enforcement points between interconnected systems. Enforcement includes prohibiting information transfers between interconnected systems (i.e., allowing access only), employing hardware mechanisms to enforce one-way information flows, and implementing trustworthy regrading mechanisms to reassign security attributes and labels.

;3.1.4: Separate the duties of individuals to reduce the risk of malevolent activity without collusion.
:'''Discussion:''' Separation of duties addresses the potential for abuse of authorized privileges and helps reduce the risk of malevolent activity without collusion. It includes dividing mission functions and system support functions among different individuals or roles; conducting system support functions with different individuals (e.g., configuration management, quality assurance and testing, system management, programming, and network security); and ensuring that security personnel administering access control functions do not also administer audit functions. Because separation-of-duty violations can span systems and application domains, organizations consider the entirety of organizational systems and components when developing policy on separation of duties.

;3.1.5: Employ the principle of least privilege, including for specific security functions and privileged accounts.
:'''Discussion:''' Organizations employ the principle of least privilege for specific duties and authorized accesses for users and processes, with the goal of authorized privileges no higher than necessary to accomplish required missions or business functions. Organizations consider creating additional processes, roles, and system accounts as necessary to achieve least privilege, and also apply least privilege to the development, implementation, and operation of organizational systems. Security functions include establishing system accounts, setting logged events, setting intrusion detection parameters, and configuring access authorizations.

Privileged accounts, including super user accounts, are typically described as system administrator accounts for various commercial off-the-shelf operating systems. Restricting privileged accounts to specific personnel or roles prevents day-to-day users from having access to privileged information or functions. Organizations may differentiate application of this requirement between local and domain accounts, provided they retain the ability to control system configurations for key security parameters and otherwise sufficiently mitigate risk.

;3.1.6: Use non-privileged accounts or roles when accessing nonsecurity functions.
:'''Discussion:''' This requirement limits exposure when operating from within privileged accounts or roles. The inclusion of roles addresses situations where organizations implement access control policies such as role-based access control, and where a change of role provides the same degree of assurance in the change of access authorizations for the user and all processes acting on the user's behalf as would be provided by a change between a privileged and non-privileged account.

;3.1.7: Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.
:'''Discussion:''' Privileged functions include establishing system accounts, performing system integrity checks, conducting patching operations, or administering cryptographic key management activities. Non-privileged users are individuals who do not possess appropriate authorizations. Circumventing intrusion detection and prevention mechanisms or malicious code protection mechanisms are examples of privileged functions requiring protection from non-privileged users. This requirement represents a condition to be achieved by the definition of authorized privileges in 3.1.2.

Misuse of privileged functions, whether intentional or unintentional by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern with potentially significant adverse impacts. Logging the use of privileged functions is one way to detect such misuse and help mitigate the risk from insider threats and the advanced persistent threat.

;3.1.8: Limit unsuccessful logon attempts.
:'''Discussion:''' This requirement applies regardless of whether the logon occurs via a local or network connection. Due to the potential for denial of service, automatic lockouts initiated by systems are, in most cases, temporary and automatically release after a predetermined period established by the organization (i.e., a delay algorithm). Organizations may employ different delay algorithms for different system components based on their capabilities. Responses to unsuccessful logon attempts may be implemented at the operating system and application levels.

;3.1.9: Provide privacy and security notices consistent with applicable CUI rules.
:'''Discussion:''' System use notifications can be implemented using messages or warning banners displayed before individuals log in to organizational systems. System use notifications are used only for access via logon interfaces with human users and are not required when such human interfaces do not exist. Based on a risk assessment, organizations consider whether a secondary system use notification is needed to access applications or other system resources after the initial network logon. Where necessary, posters or other printed materials may be used in lieu of an automated system banner. Organizations consult with the Office of General Counsel for legal review and approval of warning banner content.

;3.1.10: Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity.
:'''Discussion:''' Session locks are temporary actions taken when users stop work and move away from the immediate vicinity of the system but do not want to log out because of the temporary nature of their absence. Session locks are implemented where session activities can be determined, typically at the operating system level, but can also be at the application level. Session locks are not an acceptable substitute for logging out of the system, for example, if organizations require users to log out at the end of the workday.

Pattern-hiding displays can include static or dynamic images, such as screen-saver patterns, photographic images, solid colors, a clock, a battery-life indicator, or a blank screen, with the additional caveat that none of the images convey controlled unclassified information.

;3.1.11: Terminate (automatically) a user session after a defined condition.
:'''Discussion:''' This requirement addresses the termination of user-initiated logical sessions, in contrast to the termination of network connections associated with communications sessions (i.e., disconnecting from the network). A logical session (for local, network, and remote access) is initiated whenever a user (or process acting on a user's behalf) accesses an organizational system. Such user sessions can be terminated (and thus terminate user access) without terminating network sessions. Session termination terminates all processes associated with a user's logical session except those specifically created by the user (i.e., session owner) to continue after the session is terminated. Conditions or trigger events requiring automatic session termination can include organization-defined periods of user inactivity, targeted responses to certain types of incidents, and time-of-day restrictions on system use.

;3.1.12: Monitor and control remote access sessions.
:'''Discussion:''' Remote access is access to organizational systems by users (or processes acting on their behalf) communicating through external networks (e.g., the Internet). Remote access methods include dial-up, broadband, and wireless. Organizations often employ encrypted virtual private networks (VPNs) to enhance confidentiality over remote connections; the use of encrypted VPNs does not make the access non-remote, but when adequately provisioned with appropriate controls, may provide sufficient assurance that the organization can effectively treat such connections as internal networks. VPNs with encrypted tunnels can affect the capability to adequately monitor network communications traffic for malicious code.

Automated monitoring and control of remote access sessions allows organizations to detect cyberattacks and help ensure ongoing compliance with remote access policies by auditing connection activities of remote users on a variety of system components (e.g., servers, workstations, notebook computers, smart phones, and tablets). NIST Special Publications 800-46, 800-77, and 800-113 provide guidance on secure remote access and virtual private networks.

;3.1.13: Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.
:'''Discussion:''' Cryptographic standards include FIPS-validated cryptography and NSA-approved cryptography.

;3.1.14: Route remote access via managed access control points.
:'''Discussion:''' Routing remote access through managed access control points enhances explicit, organizational control over such connections, reducing susceptibility to unauthorized access to organizational systems resulting in the unauthorized disclosure of CUI.

;3.1.15: Authorize remote execution of privileged commands and remote access to security-relevant information.
:'''Discussion:''' A privileged command is a human-initiated (interactively or via a process operating on the human's behalf) command executed on a system involving the control, monitoring, or administration of the system, including security functions and associated security-relevant information. Security-relevant information is any information within the system that can potentially impact the operation of security functions or the provision of security services in a manner that could result in failure to enforce the system security policy or maintain isolation of code and data. Privileged commands give individuals the ability to execute sensitive, security-critical, or security-relevant system functions. Controlling such access from remote locations helps ensure that unauthorized individuals cannot freely execute such commands with the potential to do serious or catastrophic damage to organizational systems. The ability to affect the integrity of the system is considered security-relevant, as it could enable a means to bypass security functions, even without directly impacting the function itself.

;3.1.16: Authorize wireless access prior to allowing such connections.
:'''Discussion:''' Establishing usage restrictions and configuration/connection requirements for wireless access to the system provides criteria for organizations to support wireless access authorization decisions, reducing the susceptibility to unauthorized access to the system through wireless technologies. Wireless networks use authentication protocols that provide credential protection and mutual authentication. NIST Special Publication 800-97 provides guidance on secure wireless networks.

;3.1.17: Protect wireless access using authentication and encryption.
:'''Discussion:''' Organizations authenticate individuals and devices to help protect wireless access to the system. Special attention is given to the wide variety of devices that are part of the Internet of Things, which may have wireless access to organizational systems.

;3.1.18: Control connection of mobile devices.
:'''Discussion:''' A mobile device is a computing device with a small form factor that can easily be carried by a single individual; is designed to operate without a physical connection (e.g., wirelessly transmitting or receiving information); possesses local, non-removable or removable data storage; and includes a self-contained power source. Mobile devices may also include voice communication capabilities, on-board sensors allowing the device to capture information, or built-in features for synchronizing local data with remote locations. Examples include smart phones, e-readers, and tablets.

Due to the large variety of mobile devices with different technical characteristics and capabilities, organizational restrictions may vary for different device types. Usage restrictions and implementation guidance for mobile devices include: device identification and authentication; configuration management; implementation of mandatory protective software (e.g., malicious code detection, firewall); scanning devices for malicious code; updating virus protection software; scanning for critical software updates and patches; conducting operating system integrity checks; and disabling unnecessary hardware (e.g., wireless, infrared). Many controls for mobile devices are reflected in other CUI security requirements. NIST Special Publication 800-124 provides guidance on mobile device security.

;3.1.19: Encrypt CUI on mobile devices and mobile computing platforms.<ref>Mobile devices and computing platforms include, for example, smartphones and tablets.</ref>
:'''Discussion:''' Organizations can employ full-device encryption or container-based encryption to protect the confidentiality of CUI on mobile devices and computing platforms. Container-based encryption provides a more fine-grained approach, including encrypting selected data structures such as files, records, or fields.

;3.1.20: Verify and control/limit connections to and use of external systems.
:'''Discussion:''' External systems are systems or components for which organizations typically have no direct supervision and authority over the application of security requirements and controls, or the determination of the effectiveness of implemented controls. External systems include personally owned systems, components, or devices, and privately owned computing and communications devices resident in commercial or public facilities. This requirement also addresses the use of external systems for the processing, storage, or transmission of CUI, including accessing cloud services (e.g., infrastructure as a service, platform as a service, or software as a service) from organizational systems.

Organizations establish terms and conditions for the use of external systems in accordance with organizational security policies and procedures, addressing at a minimum the types of applications that can be accessed on organizational systems from external systems. If terms and conditions with the owners of external systems cannot be established, organizations may impose restrictions on organizational personnel using those external systems.

This requirement recognizes that there are circumstances where individuals using external systems (e.g., contractors, coalition partners) need to access organizational systems. In those situations, organizations need confidence that the external systems contain the necessary controls so as not to compromise, damage, or otherwise harm organizational systems. Verification that the required controls have been effectively implemented can be achieved through third-party independent assessments, attestations, or other means, depending on the assurance or confidence level required.

Note that while "external" typically refers to outside of the organization's direct supervision and authority, that is not always the case: an organization may have systems that process CUI and others that do not, and among the systems that process CUI there are likely access restrictions that apply between systems. Therefore, from the perspective of a given system, other systems within the organization may be considered "external" to that system.

;3.1.21: Limit use of portable storage devices on external systems.
:'''Discussion:''' Limits on the use of organization-controlled portable storage devices in external systems include complete prohibition of use, or restrictions on how and under what conditions the devices may be used. As with 3.1.20, "external" does not always mean outside the organization; from the perspective of a given system, other systems within the organization may be considered "external" to that system.

;3.1.22: Control CUI posted or processed on publicly accessible systems.
:'''Discussion:''' In accordance with laws, executive orders, directives, policies, regulations, or standards, the public is not authorized access to nonpublic information (e.g., information protected under the Privacy Act, CUI, and proprietary information). This requirement addresses systems that are controlled by the organization and accessible to the public, typically without identification or authentication. Individuals authorized to post CUI onto publicly accessible systems are designated, and the content of information is reviewed prior to posting to ensure that nonpublic information is not included.

=== 3.2 Awareness and Training ===
==== Basic Security Requirements ====
;3.2.1: Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems.
:'''Discussion:''' Organizations determine the content and frequency of security awareness training and techniques based on specific organizational requirements and the systems to which personnel have authorized access. Content includes a basic understanding of the need for information security and user actions to maintain security and respond to suspected security incidents, as well as awareness of the need for operations security. Techniques include formal training, supplies inscribed with security reminders, email advisories, logon screen messages, security awareness posters, and information security awareness events. NIST Special Publication 800-50 provides guidance on security awareness and training programs.

;3.2.2: Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities.
:'''Discussion:''' Organizations determine the content and frequency of security training based on assigned duties, roles, and responsibilities, and the security requirements of organizations and the systems to which personnel have authorized access. Organizations provide system developers, architects, acquisition/procurement officials, system/network administrators, configuration management and auditing personnel, independent verification and validation personnel, security assessors, and others with system-level access, security-related technical training tailored to their assigned duties. Comprehensive role-based training addresses management, operational, and technical roles and responsibilities covering physical, personnel, and technical controls, and can include policies, procedures, tools, and artifacts for the defined security roles. Organizations also provide training for responsibilities related to operations and supply chain security. NIST Special Publication 800-181 provides guidance on role-based information security training; NIST Special Publication 800-161 provides guidance on supply chain risk management.

==== Derived Security Requirements ====
;3.2.3: Provide security awareness training on recognizing and reporting potential indicators of insider threat.
:'''Discussion:''' Potential indicators and possible precursors of insider threat include behaviors such as: inordinate, long-term job dissatisfaction; attempts to gain access to information not required for job performance; unexplained access to financial resources; bullying or sexual harassment of fellow employees; workplace violence; and other serious violations of organizational policies, procedures, directives, rules, or practices. Security awareness training includes how to communicate employee and management concerns about potential indicators of insider threat through appropriate organizational channels. Organizations may consider tailoring insider threat awareness topics to the role (e.g., training for managers focused on changes in team members' behavior, training for employees focused on more general observations).

=== 3.3 Audit and Accountability ===
==== Basic Security Requirements ====
;3.3.1: Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.
:'''Discussion:''' An event is any observable occurrence in a system, including unlawful or unauthorized system activity. Organizations identify event types for which a logging functionality is needed as those significant and relevant to the security of systems and their operating environments. Event types can include password changes, failed logons or accesses, administrative privilege usage, or third-party credential usage. Organizations consider the monitoring and auditing appropriate for each CUI security requirement, balanced with other system needs; for example, systems may have the capability to log every file access but not activate that capability except in specific circumstances due to the potential burden on performance.

Audit records can be generated at various levels of abstraction, including at the packet level. Selecting the appropriate level of abstraction is a critical aspect of audit logging and can facilitate identifying root causes of problems. Organizations consider the logging necessary to cover related events, such as steps in distributed, transaction-based processes and actions occurring in service-oriented or cloud-based architectures.

Audit record content that may be necessary includes time stamps, source and destination addresses, user or process identifiers, event descriptions, success or failure indications, filenames involved, and access control or flow control rules invoked. Organizations consider limiting additional audit log information to only what is explicitly needed, to avoid misleading information or making it harder to locate information of interest. Audit logs are reviewed and analyzed as often as needed to facilitate risk-based decision making. NIST Special Publication 800-92 provides guidance on security log management.

;3.3.2: Ensure that the actions of individual system users can be uniquely traced to those users, so they can be held accountable for their actions.
:'''Discussion:''' This requirement ensures that audit record content includes the information needed to link an audit event to the actions of an individual, to the extent feasible. Organizations consider logging for traceability including account usage, remote access, wireless connectivity, mobile device connection, boundary communications, configuration settings, physical access, nonlocal maintenance, use of maintenance tools, temperature and humidity, equipment delivery and removal, system component inventory, use of mobile code, and use of Voice over Internet Protocol (VoIP).

==== Derived Security Requirements ====
;3.3.3: Review and update logged events.
:'''Discussion:''' The intent of this requirement is to periodically re-evaluate which logged events will continue to be included in the list of events to be logged. Event types logged by organizations may change over time; periodic review and updating ensures that the current set remains necessary and sufficient.

;3.3.4: Alert in the event of an audit logging process failure.
:'''Discussion:''' Audit logging process failures include software and hardware errors, failures in audit record capturing mechanisms, and audit record storage capacity being reached or exceeded. This requirement applies to each audit record data storage repository, the total audit record storage capacity of organizations, or both.

;3.3.5: Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.
:'''Discussion:''' Correlating audit record review, analysis, and reporting processes helps ensure they operate collectively rather than independently. The requirement is agnostic as to whether correlation is applied at the system level or the organization level across all systems.

;3.3.6: Provide audit record reduction and report generation to support on-demand analysis and reporting.
:'''Discussion:''' Audit record reduction manipulates collected audit information and organizes it into a summary format more meaningful to analysts. Reduction and report generation capabilities do not always come from the same system or organizational entity conducting auditing activities, and can include modern data mining techniques with advanced data filters to identify anomalous behavior. Time ordering of audit records can be a significant issue if time stamp granularity in the record is insufficient.

;3.3.7: Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.
:'''Discussion:''' Internal system clocks generate time stamps, expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC. Granularity of time measurements refers to the degree of synchronization between system clocks and reference clocks (e.g., within hundreds or tens of milliseconds); organizations may define different granularities for different components. Time service can also be critical to other security capabilities such as access control and identification and authentication. This requirement provides uniformity of time stamps for systems with multiple clocks and systems connected over a network.

;3.3.8: Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
:'''Discussion:''' Audit information includes all information (e.g., audit records, audit log settings, and audit reports) needed to successfully audit system activity. Audit logging tools are the programs and devices used to conduct audit and logging activities. This requirement focuses on the technical protection of audit information and limits the ability to access and execute audit logging tools to authorized individuals; physical protection of audit information is addressed by media protection and physical/environmental protection requirements.

;3.3.9: Limit management of audit logging functionality to a subset of privileged users.
:'''Discussion:''' Individuals with privileged access to a system who are also subject to audit by that system may affect the reliability of audit information by inhibiting audit logging activities or modifying audit records. This requirement specifies that privileged access be further defined between audit-related privileges and other privileges, limiting the users who have audit-related privileges.

=== 3.4 Configuration Management ===
==== Basic Security Requirements ====
;3.4.1: Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.
:'''Discussion:''' Baseline configurations are documented, formally reviewed, and agreed-upon specifications for systems or configuration items within them, serving as a basis for future builds, releases, and changes. Baseline configurations include information about system components (e.g., standard software packages installed on workstations, notebook computers, servers, network components, or mobile devices; current version, update, and patch information for operating systems and applications; and configuration settings and parameters), network topology, and the logical placement of components within the system architecture. Maintaining effective baseline configurations requires creating new baselines as systems change over time, including reviewing and updating the baseline when changes are made based on security risks and deviations from the established configuration.

Organizations can implement centralized system component inventories spanning multiple organizational systems, ensuring the inventories include system-specific information required for proper component accountability (e.g., system association, system owner). Information for effective accountability includes hardware inventory specifications, software license information, software version numbers, component owners, and, for networked components, machine names and network addresses. NIST Special Publication 800-128 provides guidance on security-focused configuration management.

;3.4.2: Establish and enforce security configuration settings for information technology products employed in organizational systems.
:'''Discussion:''' Configuration settings are the parameters that can be changed in hardware, software, or firmware components that affect the security posture or functionality of the system. Products for which security-related settings can be defined include mainframe computers, servers, workstations, input/output devices, network components, operating systems, middleware, and applications.

Security parameters are those impacting the security state of systems, including parameters required to satisfy other security requirements, such as registry settings, account/file/directory permission settings, and settings for functions, ports, protocols, and remote connections. Organizations establish organization-wide configuration settings and derive specific settings for systems, which become part of the systems' configuration baseline. Common secure configurations (also called security configuration checklists, lockdown and hardening guides, security reference guides, or security technical implementation guides) provide recognized, standardized benchmarks for secure configuration of specific IT platforms/products. NIST Special Publications 800-70 and 800-128 provide guidance on security configuration settings.

==== Derived Security Requirements ====
;3.4.3: Track, review, approve or disapprove, and log changes to organizational systems.
:'''Discussion:''' Tracking, reviewing, approving/disapproving, and logging changes is called configuration change control, which involves the systematic proposal, justification, implementation, testing, review, and disposition of changes to systems, including upgrades and modifications. It includes changes to baseline configurations, changes to configuration settings for IT products, unscheduled and unauthorized changes, and changes to remediate vulnerabilities. Processes for managing configuration changes include Configuration Control Boards or Change Advisory Boards that review and approve proposed changes. NIST Special Publication 800-128 provides guidance on configuration change control.

;3.4.4: Analyze the security impact of changes prior to implementation.
:'''Discussion:''' Personnel with information security responsibilities (e.g., system administrators, security officers, security managers, security engineers) conduct security impact analyses, possessing the necessary skills and technical expertise to analyze changes and their security ramifications. This may include reviewing security plans and system design documentation to understand controls and how changes might affect them, and may include risk assessments to understand impact and determine if additional controls are required. NIST Special Publication 800-128 provides related guidance.

;3.4.5: Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.
:'''Discussion:''' Any changes to hardware, software, or firmware components can potentially have significant effects on overall system security. Organizations therefore permit only qualified and authorized individuals to access systems to initiate changes, including upgrades and modifications; access restrictions for change also include software libraries. Restrictions include physical and logical access control requirements, workflow automation, media libraries, abstract layers, and change windows. NIST Special Publication 800-128 provides related guidance.

;3.4.6: Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.
:'''Discussion:''' Systems can provide a wide variety of functions and services, some of which, though provided by default, may not be necessary to support essential organizational missions or operations. Providing multiple services from a single system component increases risk relative to limiting the services provided by any one component; where feasible, organizations limit component functionality to a single function per component. Organizations review functions and services to determine candidates for elimination, disable unused or unnecessary physical and logical ports and protocols, and can use network scanning tools, intrusion detection and prevention systems, and end-point protections to identify and prevent the use of prohibited functions, ports, protocols, and services.

;3.4.7: Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.
:'''Discussion:''' Restricting nonessential software includes restricting the roles allowed to approve program execution, prohibiting auto-execute, program blacklisting and whitelisting, or restricting the number of program instances executed simultaneously. Organizations make a security-based determination of which functions, ports, protocols, and services are restricted. Bluetooth, File Transfer Protocol (FTP), and peer-to-peer networking are examples of protocols organizations consider preventing, restricting, or disabling.

;3.4.8: Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.
:'''Discussion:''' The process used to identify software programs not authorized to execute is commonly called blacklisting; the process used to identify programs that are authorized to execute is commonly called whitelisting. Whitelisting is the stronger of the two policies. Organizations also consider verifying the integrity of whitelisted software using, for example, cryptographic checksums, digital signatures, or hash functions, either prior to execution or at system startup. NIST Special Publication 800-167 provides guidance on application whitelisting.

;3.4.9: Control and monitor user-installed software.
:'''Discussion:''' Users can install software in organizational systems if given the necessary privileges. To maintain control, organizations identify permitted and prohibited actions regarding software installation through policy. Permitted installations may include updates and security patches from organization-approved "app stores"; prohibited installations may include software with unknown or suspect pedigrees or software considered potentially malicious. Policy enforcement methods include procedural methods, automated methods, or both.

=== 3.5 Identification and Authentication ===
==== Basic Security Requirements ====
;3.5.1: Identify system users, processes acting on behalf of users, and devices.
:'''Discussion:''' Common device identifiers include Media Access Control (MAC) addresses, Internet Protocol (IP) addresses, or device-unique token identifiers. Management of individual identifiers does not apply to shared system accounts; typically, individual identifiers are the user names associated with system accounts assigned to individuals. Organizations may require unique identification of individuals in group accounts, and this requirement also addresses individual identifiers not necessarily associated with system accounts. Organizational devices requiring identification may be defined by type, by device, or by a combination of both. NIST Special Publication 800-63-3 provides guidance on digital identities.

;3.5.2: Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems.
:'''Discussion:''' Individual authenticators include passwords, key cards, cryptographic devices, and one-time password devices. Developers ship system components with factory default authentication credentials to allow for initial installation and configuration; default credentials are often well known, easily discoverable, and present a significant security risk. Systems support authenticator management through organization-defined settings and restrictions for authenticator characteristics, including minimum password length, validation time windows for time-synchronous one-time tokens, and the number of allowed rejections during biometric verification. Authenticator management includes issuing and revoking authenticators for temporary access, such as for remote maintenance. Device authenticators include certificates and passwords. NIST Special Publication 800-63-3 provides guidance on digital identities.

==== Derived Security Requirements ====
;3.5.3: Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.<ref>Multifactor authentication requires two or more different factors to achieve authentication: something you know (e.g., password/PIN); something you have (e.g., cryptographic identification device, token); or something you are (e.g., biometric). This requirement should not be interpreted as requiring federal Personal Identity Verification (PIV) card or Department of Defense Common Access Card (CAC)-like solutions. A variety of multifactor solutions (including those with replay resistance) using tokens and biometrics are commercially available, and may employ hard tokens (e.g., smartcards, key fobs, dongles) or soft tokens to store user credentials.</ref><ref>Local access is any access to a system by a user (or process acting on a user's behalf) communicating through a direct connection without the use of a network. Network access is any access to a system by a user (or process) communicating through a network (e.g., local area network, wide area network, Internet).</ref>
:'''Discussion:''' Multifactor authentication requires two or more different factors: something you know (e.g., password, PIN); something you have (e.g., cryptographic identification device, token); or something you are (e.g., biometric). Solutions featuring physical authenticators include hardware authenticators providing time-based or challenge-response authentication and smart cards. Organizations may also employ authentication mechanisms at the application level, when necessary.

Access to organizational systems is defined as local access or network access. Local access is any access obtained by direct connection without the use of networks; network access is access obtained through network connections. Remote access is a type of network access involving communication through external networks. Encrypted virtual private networks connecting organization-controlled and non-organization-controlled endpoints may be treated as internal networks with regard to confidentiality protection. NIST Special Publication 800-63-3 provides guidance on digital identities.

;3.5.4: Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.
:'''Discussion:''' Authentication processes resist replay attacks if it is impractical to successfully authenticate by recording or replaying previous authentication messages. Replay-resistant techniques include protocols using nonces or challenges, such as time-synchronous or challenge-response one-time authenticators. NIST Special Publication 800-63-3 provides guidance on digital identities.

;3.5.5: Prevent reuse of identifiers for a defined period.
:'''Discussion:''' Identifiers are provided for users, processes acting on their behalf, or devices (see 3.5.1). Preventing reuse implies preventing the assignment of previously used individual, group, role, or device identifiers to different individuals, groups, roles, or devices.

;3.5.6: Disable identifiers after a defined period of inactivity.
:'''Discussion:''' Inactive identifiers pose a risk because attackers may exploit them to gain undetected access to organizational devices; owners of inactive accounts may not notice if unauthorized access has occurred.

;3.5.7: Enforce a minimum password complexity and change of characters when new passwords are created.
:'''Discussion:''' This requirement applies to single-factor authentication of individuals using passwords as individual or group authenticators, and similarly when passwords are used as part of multifactor authenticators. The number of changed characters refers to the number of changes required relative to the total number of positions in the current password. Organizations may also consider salting passwords to mitigate certain brute-force attacks.

;3.5.8: Prohibit password reuse for a specified number of generations.
:'''Discussion:''' Password lifetime restrictions do not apply to temporary passwords.

;3.5.9: Allow temporary password use for system logons with an immediate change to a permanent password.
:'''Discussion:''' Changing temporary passwords to permanent passwords immediately after system logon ensures the necessary strength of the authentication mechanism is implemented at the earliest opportunity, reducing susceptibility to authenticator compromise.

;3.5.10: Store and transmit only cryptographically-protected passwords.
:'''Discussion:''' Cryptographically protected passwords use salted one-way cryptographic hashes of passwords.

;3.5.11: Obscure feedback of authentication information.
:'''Discussion:''' System feedback does not provide information that would allow unauthorized individuals to compromise authentication mechanisms. For systems with relatively large monitors (e.g., desktop or notebook computers), the threat of "shoulder surfing" may be significant; for systems with small displays (e.g., mobile devices) this threat may be less significant but is balanced against the increased likelihood of typographic input errors from small keyboards. The means for obscuring feedback — such as displaying asterisks when users type passwords, or showing feedback briefly before fully obscuring it — is selected accordingly.

=== 3.6 Incident Response ===
==== Basic Security Requirements ====
;3.6.1: Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.
:'''Discussion:''' Incident-handling capability depends on the capabilities of organizational systems and the mission/business processes they support; organizations consider incident handling as part of the definition, design, and development of those processes and systems. Incident-related information can come from audit monitoring, network monitoring, physical access monitoring, user and administrator reports, and reported supply chain events. Effective incident-handling capability includes coordination among many organizational entities, including mission/business owners, system owners, authorizing officials, human resources, physical and personnel security offices, legal departments, operations personnel, procurement offices, and the risk executive.

As part of user response activities, incident response training is linked to assigned roles and responsibilities: regular users may only need to know who to call or how to recognize an incident, system administrators may need additional training on handling or remediating incidents, and incident responders may receive more specific training on forensics, reporting, and system recovery and restoration. Training includes identifying and reporting suspicious activities from external and internal sources; user response activities also include help desk support, assistance groups, and access to forensics or consumer redress services when required. NIST Special Publication 800-61 provides guidance on incident handling; NIST Special Publications 800-86 and 800-101 provide guidance on integrating forensic techniques into incident response; NIST Special Publication 800-161 provides guidance on supply chain risk management.

;3.6.2: Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.
:'''Discussion:''' Tracking and documenting incidents includes maintaining records about each incident, its status, and other pertinent information necessary for forensics and for evaluating incident details, trends, and handling. Incident information can be obtained from incident reports, incident response teams, audit monitoring, network monitoring, physical access monitoring, and user/administrator reports.

Reporting incidents addresses specific internal reporting requirements as well as formal reporting requirements applicable to the organization. Suspected security incidents may also be reported, including the receipt of suspicious email communications that could contain malicious code. The types of incidents reported, the content and timeliness of reports, and the designated reporting authorities reflect applicable laws, executive orders, directives, regulations, and policies. NIST Special Publication 800-61 provides guidance on incident handling.

==== Derived Security Requirements ====
;3.6.3: Test the organizational incident response capability.
:'''Discussion:''' Organizations test incident response capabilities to determine their effectiveness and identify potential weaknesses or deficiencies. Testing includes checklists, walk-through or tabletop exercises, simulations (parallel and full interrupt), and comprehensive exercises, and can include determining the effects of incident response on organizational operations, assets, and individuals. NIST Special Publication 800-84 provides guidance on testing programs for information technology capabilities.

=== 3.7 Maintenance ===
==== Basic Security Requirements ====
;3.7.1: Perform maintenance on organizational systems.<ref>In general, system maintenance requirements tend to support the security objective of availability. However, improper system maintenance or a failure to perform maintenance can result in the unauthorized disclosure of CUI, thus compromising confidentiality of that information.</ref>
:'''Discussion:''' This requirement addresses the information security aspects of the system maintenance program and applies to all types of maintenance on any system component (including hardware, firmware, applications) conducted by any local or nonlocal entity. System maintenance also includes components not directly associated with information processing or data retention, such as scanners, copiers, and printers.

;3.7.2: Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance.
:'''Discussion:''' This requirement addresses security issues with maintenance tools that are outside the organizational system boundaries that process, store, or transmit CUI, but are used specifically for diagnostic and repair actions on those systems. Organizations have flexibility in determining controls for maintenance tools, which can include approving, controlling, and monitoring their use. Maintenance tools are potential vehicles for transporting malicious code into a facility and into organizational systems, and can include hardware, software, and firmware items such as diagnostic test equipment and packet sniffers.

==== Derived Security Requirements ====
;3.7.3: Ensure equipment removed for off-site maintenance is sanitized of any CUI.
:'''Discussion:''' This requirement addresses the information security aspects of system maintenance performed off-site and applies to all types of maintenance conducted by a local or nonlocal entity (e.g., in-contract, warranty, in-house, software maintenance agreement). NIST Special Publication 800-88 provides guidance on media sanitization.

;3.7.4: Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems.
:'''Discussion:''' If, upon inspection, organizations determine that media containing maintenance diagnostic and test programs contain malicious code, the incident is handled consistent with incident handling policies and procedures.

;3.7.5: Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete.
:'''Discussion:''' Nonlocal maintenance and diagnostic activities are conducted by individuals communicating through an external network. The authentication techniques employed for these sessions reflect the network access requirements in 3.5.3.

;3.7.6: Supervise the maintenance activities of maintenance personnel without required access authorization.
:'''Discussion:''' This requirement applies to individuals performing hardware or software maintenance on organizational systems, while 3.10.1 addresses physical access for individuals whose maintenance duties place them within the physical protection perimeter of the systems (e.g., custodial staff, physical plant maintenance personnel). Individuals not previously identified as authorized maintenance personnel — such as IT manufacturers, vendors, consultants, and systems integrators — may require privileged access, for example when conducting maintenance with little or no notice. Organizations may choose to issue temporary credentials to such individuals based on risk assessments; these may be for one-time use or very limited time periods.

=== 3.8 Media Protection ===
==== Basic Security Requirements ====
;3.8.1: Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital.
:'''Discussion:''' System media includes digital media (e.g., diskettes, magnetic tapes, external and removable hard disk drives, flash drives, compact disks, digital video disks) and non-digital media (e.g., paper, microfilm). Physically controlling system media includes conducting inventories, maintaining accountability for stored media, and ensuring procedures allow individuals to check out and return media to the media library. Secure storage includes a locked drawer, desk, or cabinet, or a controlled media library. NIST Special Publication 800-111 provides guidance on storage encryption technologies for end-user devices.

;3.8.2: Limit access to CUI on system media to authorized users.
:'''Discussion:''' Access can be limited by physically controlling system media and secure storage areas, including conducting inventories, ensuring procedures allow individuals to check out and return media to the media library, and maintaining accountability for all stored media.

;3.8.3: Sanitize or destroy system media containing CUI before disposal or release for reuse.
:'''Discussion:''' This requirement applies to all system media, digital and non-digital, subject to disposal or reuse. Examples include digital media found in workstations, network components, scanners, copiers, printers, notebook computers, and mobile devices, and non-digital media such as paper and microfilm. Sanitization removes information such that it cannot be retrieved or reconstructed; techniques include clearing, purging, cryptographic erase, and destruction. Organizations determine appropriate sanitization methods, recognizing destruction may be necessary when other methods cannot be applied, and use discretion for media containing information that is public, publicly releasable, or deemed to have no adverse impact if released. Sanitization of non-digital media includes destruction, removing CUI from documents, or redacting sections or words in a manner equivalent to removal. NARA policy and guidance control sanitization processes for CUI. NIST Special Publication 800-88 provides guidance on media sanitization.

==== Derived Security Requirements ====
;3.8.4: Mark media with necessary CUI markings and distribution limitations.<ref>Implementation of this requirement follows the marking guidance in 32 CFR 2002 and NARA's CUI guidance. Standard Form (SF) 902 and SF 903 can be used on media containing CUI such as hard drives or USB devices; both forms are available from GSA Advantage.</ref>
:'''Discussion:''' The term ''security marking'' refers to the application or use of human-readable security attributes. Marking of system media (digital and non-digital) reflects applicable federal laws, executive orders, directives, policies, and regulations.

;3.8.5: Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas.
:'''Discussion:''' Controlled areas are areas or spaces for which organizations provide physical or procedural controls to meet requirements for protecting systems and information. Controls to maintain accountability for media during transport include locked containers and cryptography, which can provide confidentiality and integrity protections depending on the mechanisms used. Activities associated with transport include the transport itself as well as releasing media for transport and ensuring media enters the appropriate transport processes; authorized transport and courier personnel may include individuals external to the organization. Maintaining accountability includes restricting transport activities to authorized personnel and tracking and obtaining explicit records of transport activities to prevent and detect loss, destruction, or tampering.

;3.8.6: Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards.
:'''Discussion:''' This requirement applies to portable storage devices (e.g., USB memory sticks, digital video disks, compact disks, external or removable hard disk drives). NIST Special Publication 800-111 provides guidance on storage encryption technologies for end-user devices.

;3.8.7: Control the use of removable media on system components.
:'''Discussion:''' In contrast to requirement 3.8.1, which restricts user access to media, this requirement restricts the use of certain types of media on systems, for example restricting or prohibiting flash drives or external hard disk drives. Organizations can employ technical and nontechnical controls (e.g., policies, procedures, rules of behavior), such as physical cages on workstations to prohibit access to certain external ports, or disabling the ability to insert, read, or write to such devices. Organizations may also limit use to approved devices only, or prohibit writeable portable devices by disabling or removing write capability.

;3.8.8: Prohibit the use of portable storage devices when such devices have no identifiable owner.
:'''Discussion:''' Requiring identifiable owners (individuals, organizations, or projects) for portable storage devices reduces overall risk by allowing organizations to assign responsibility and accountability for addressing known vulnerabilities in the devices (e.g., insertion of malicious code).

;3.8.9: Protect the confidentiality of backup CUI at storage locations.
:'''Discussion:''' Organizations can employ cryptographic mechanisms or alternative physical controls to protect the confidentiality of backup information at designated storage locations. Backed-up information containing CUI may include system-level information (system-state information, operating system software, application software, licenses) and user-level information (information other than system-level information).

=== 3.9 Personnel Security ===
==== Basic Security Requirements ====
;3.9.1: Screen individuals prior to authorizing access to organizational systems containing CUI.
:'''Discussion:''' Personnel security screening (vetting) activities involve evaluating an individual's conduct, integrity, judgment, loyalty, reliability, and stability (i.e., trustworthiness) prior to authorizing access to organizational systems containing CUI. Screening activities reflect applicable federal laws, executive orders, directives, policies, regulations, and criteria established for the level of access required for assigned positions.

;3.9.2: Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers.
:'''Discussion:''' Protecting CUI during and after personnel actions may include returning system-related property (e.g., hardware authentication tokens, identification cards, technical manuals, keys, building passes) and conducting exit interviews, which can address nondisclosure agreements and potential limitations on future employment. Exit interviews may not be possible for some terminated individuals (e.g., job abandonment, illness, non-availability of supervisors); for cause terminations, timely execution is essential, and organizations may consider disabling accounts prior to notifying the individual.

This requirement applies to reassignments or transfers when the personnel action is permanent or of such extended duration as to require protection. Organizations define appropriate protections, which may include returning old and issuing new keys, identification cards, and building passes; changing system access authorizations; closing old accounts and establishing new ones; and providing access to official records the individual had access to at previous work locations and accounts.

''(This family has no Derived Security Requirements.)''

=== 3.10 Physical Protection ===
==== Basic Security Requirements ====
;3.10.1: Limit physical access to organizational systems, equipment, and the respective operating environments to authorized individuals.
:'''Discussion:''' This requirement applies to employees, individuals with permanent physical access authorization credentials, and visitors. Authorized individuals have credentials that include badges, identification cards, and smart cards; organizations determine the necessary strength of credentials consistent with applicable laws, policies, and standards. The requirement applies only to areas within facilities not designated as publicly accessible. Limiting physical access to equipment may include placing equipment in locked rooms or secured areas accessible only to authorized individuals, and in locations that can be monitored by organizational personnel. Examples of equipment include computing devices, external disk drives, networking devices, monitors, printers, copiers, scanners, facsimile machines, and audio devices.

;3.10.2: Protect and monitor the physical facility and support infrastructure for organizational systems.
:'''Discussion:''' Monitoring of physical access includes publicly accessible areas within organizational facilities, accomplished for example through guards, sensor devices, or video surveillance. Examples of support infrastructure include system distribution, transmission, and power lines; security controls applied to support infrastructure prevent accidental damage, disruption, and physical tampering, and may also prevent eavesdropping or modification of unencrypted transmissions. Physical access controls for support infrastructure include locked wiring closets, disconnected or locked spare jacks, protection of cabling by conduit or cable trays, and wiretapping sensors.

==== Derived Security Requirements ====
;3.10.3: Escort visitors and monitor visitor activity.
:'''Discussion:''' Individuals with permanent physical access authorization credentials are not considered visitors. Audit logs can be used to monitor visitor activity.

;3.10.4: Maintain audit logs of physical access.
:'''Discussion:''' Organizations have flexibility in the types of audit logs employed, which can be procedural (e.g., a written log), automated (e.g., capturing ID from a PIV card), or a combination. Physical access points can include facility access points, interior access points to systems or components requiring supplemental access controls, or both.

;3.10.5: Control and manage physical access devices.
:'''Discussion:''' Physical access devices include keys, locks, combinations, and card readers.

;3.10.6: Enforce safeguarding measures for CUI at alternate work sites.
:'''Discussion:''' Alternate work sites may include government facilities or the private residences of employees. Organizations may define different security requirements for specific alternate work sites or types of sites depending on the work-related activities conducted there. NIST Special Publications 800-46 and 800-114 provide guidance on enterprise and user security when teleworking.

=== 3.11 Risk Assessment ===
==== Basic Security Requirements ====
;3.11.1: Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI.
:'''Discussion:''' Clearly defined system boundaries are a prerequisite for effective risk assessments, which consider threats, vulnerabilities, likelihood, and impact based on the operation and use of organizational systems, as well as risk from external parties (e.g., service providers, contractors, individuals accessing organizational systems, outsourcing entities). Risk assessments, formal or informal, can be conducted at the organization, mission/business process, or system level, and at any phase of the system development life cycle. NIST Special Publication 800-30 provides guidance on conducting risk assessments.

==== Derived Security Requirements ====
;3.11.2: Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
:'''Discussion:''' Organizations determine required vulnerability scanning for all system components, ensuring potential sources such as networked printers, scanners, and copiers are not overlooked, and update the vulnerabilities scanned for as new ones are discovered. Vulnerability analyses for custom software applications may require static analysis, dynamic analysis, binary analysis, or a hybrid approach. Scanning includes patch levels, functions/ports/protocols/services that should not be accessible, and improperly configured information flow control mechanisms. Organizations consider using SCAP-validated products, tools that use the CVE naming convention and OVAL, and sources such as the Common Weakness Enumeration (CWE) and the National Vulnerability Database (NVD).

Security assessments such as red team exercises provide additional sources of potential vulnerabilities to scan for; organizations also consider tools that express impact using the Common Vulnerability Scoring System (CVSS). Privileged access authorization to selected components facilitates thorough scanning and protects the sensitive nature of such scanning. NIST Special Publication 800-40 provides guidance on vulnerability management.

;3.11.3: Remediate vulnerabilities in accordance with risk assessments.
:'''Discussion:''' Vulnerabilities discovered, for example via the scanning conducted per 3.11.2, are remediated with consideration given to the related assessment of risk, which influences the prioritization of remediation efforts and the level of effort expended for specific vulnerabilities.

=== 3.12 Security Assessment ===
==== Basic Security Requirements ====
;3.12.1: Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.
:'''Discussion:''' Organizations assess security controls in organizational systems and their operating environments as part of the system development life cycle. Security controls are the safeguards or countermeasures implemented to satisfy security requirements; assessing them determines whether they are in place and operating as intended. Assessments ensure information security is built into organizational systems, identify weaknesses and deficiencies early, provide information for risk-based decisions, and ensure compliance with vulnerability mitigation procedures. Assessment reports document results in sufficient detail to determine accuracy, completeness, and whether controls are implemented correctly and producing the desired outcome, and results are provided to appropriate individuals or roles.

Organizations ensure assessment results are current, relevant, and obtained with appropriate assessor independence, and can use other activities such as vulnerability scanning and system monitoring to maintain security posture throughout the system life cycle. NIST Special Publication 800-53 provides guidance on security and privacy controls; NIST Special Publication 800-53A provides guidance on developing assessment plans and conducting assessments.

;3.12.2: Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.
:'''Discussion:''' The plan of action is a key document in the information security program, describing how unimplemented security requirements will be met and how planned mitigations will be implemented. Organizations can document the system security plan and plan of action as separate or combined documents in any chosen format. Federal agencies may consider submitted system security plans and plans of action as critical inputs to risk management decisions about hosting CUI on a nonfederal system.

;3.12.3: Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.
:'''Discussion:''' Continuous monitoring programs facilitate ongoing awareness of threats, vulnerabilities, and information security to support risk management decisions. "Continuous" and "ongoing" imply that organizations assess and analyze security controls and risks at a frequency sufficient to support risk-based decisions; results generate appropriate risk response actions. Providing access to security information through reports or dashboards gives officials the capability to make effective, timely decisions; automation supports more frequent inventory updates. Effectiveness is enhanced when monitoring outputs are specific, measurable, actionable, relevant, and timely. NIST Special Publication 800-137 provides guidance on continuous monitoring.

;3.12.4: Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.<ref>There is no prescribed format or specified level of detail for system security plans; however, organizations ensure the required information is conveyed in those plans.</ref>
:'''Discussion:''' System security plans relate security requirements to a set of security controls and describe, at a high level, how the controls meet those requirements, without providing detailed technical descriptions of design or implementation. Plans contain sufficient information to enable a design and implementation unambiguously compliant with the plan's intent, and need not be single documents — they can be a collection of various documents, including ones that already exist, making extensive use of references to policies, procedures, and additional documents. This reduces documentation requirements and keeps security-related information within established management/operational areas related to enterprise architecture, system development life cycle, systems engineering, and acquisition.

Federal agencies may consider submitted system security plans and plans of action as critical inputs to risk management decisions about hosting CUI on a nonfederal system. NIST Special Publication 800-18 provides guidance on developing security plans.

''(This family has no additional Derived Security Requirements.)''

=== 3.13 System and Communications Protection ===
==== Basic Security Requirements ====
;3.13.1: Monitor, control, and protect communications (i.e., information transmitted or received by organizational systems) at the external boundaries and key internal boundaries of organizational systems.
:'''Discussion:''' Communications can be monitored, controlled, and protected at boundary components and by restricting or prohibiting interfaces in organizational systems. Boundary components include gateways, routers, firewalls, guards, network-based malicious code analysis and virtualization systems, or encrypted tunnels implemented within a system security architecture. Restricting or prohibiting interfaces includes restricting external web communications traffic to designated web servers within managed interfaces and prohibiting external traffic that appears to be spoofing internal addresses.

Organizations consider the shared nature of commercial telecommunications services when implementing security requirements, since such services are commonly based on network components and consolidated management systems shared by all attached commercial customers, which may represent sources of increased risk despite contract security provisions. NIST Special Publication 800-41 provides guidance on firewalls and firewall policy; NIST Special Publication 800-125B provides guidance on security for virtualization technologies.

;3.13.2: Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.
:'''Discussion:''' Organizations apply systems security engineering principles to new development systems or systems undergoing major upgrades, and, to the extent feasible, to legacy system upgrades and modifications. Applying these concepts and principles helps develop trustworthy, secure, and resilient systems and reduces susceptibility to disruptions, hazards, and threats. Examples include developing layered protections; establishing security policies, architecture, and controls as the foundation for design; incorporating security requirements into the system development life cycle; delineating physical and logical security boundaries; training developers to build secure software; and performing threat modeling to identify use cases, threat agents, attack vectors and patterns, design patterns, and compensating controls needed to mitigate risk. NIST Special Publication 800-160, Volume 1 provides guidance on systems security engineering.

==== Derived Security Requirements ====
;3.13.3: Separate user functionality from system management functionality.
:'''Discussion:''' System management functionality includes functions necessary to administer databases, network components, workstations, or servers, and typically requires privileged user access. Separation of user functionality from system management functionality is physical or logical, and can be implemented using different computers, different central processing units, different operating system instances, different network addresses, virtualization techniques, or combinations thereof. This includes web administrative interfaces using separate authentication methods from other system resources, and may include isolating administrative interfaces on different domains with additional access controls.

;3.13.4: Prevent unauthorized and unintended information transfer via shared system resources.
:'''Discussion:''' Control of information in shared system resources (e.g., registers, cache memory, main memory, hard disks) is also commonly referred to as object reuse and residual information protection. This requirement prevents information produced by prior users or roles from being available to current users or roles that obtain access to shared system resources after those resources have been released back to the system, and also applies to encrypted representations of information. It does not address information remanence, covert channels, or components with only single users or roles.

;3.13.5: Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
:'''Discussion:''' Subnetworks physically or logically separated from internal networks are referred to as demilitarized zones (DMZs), typically implemented with boundary control devices and techniques including routers, gateways, firewalls, virtualization, or cloud-based technologies. NIST Special Publications 800-41 and 800-125B provide related guidance.

;3.13.6: Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).
:'''Discussion:''' This requirement applies to inbound and outbound network communications traffic at the system boundary and at identified points within the system. A deny-all, permit-by-exception policy ensures that only essential and approved connections are allowed.

;3.13.7: Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling).
:'''Discussion:''' Split tunneling might be desirable for remote users to communicate with local system resources such as printers or file servers, but it allows unauthorized external connections, making the system more vulnerable to attack and exfiltration. This requirement is implemented in remote devices through configuration settings that disable split tunneling and prevent users from readily reconfiguring them, and in the system by detecting split tunneling on the remote device and prohibiting the connection if detected.

;3.13.8: Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.
:'''Discussion:''' This requirement applies to internal and external networks and any system components that can transmit information, including servers, notebook and desktop computers, mobile devices, printers, copiers, scanners, and facsimile machines. Communication paths outside the physical protection of controlled boundaries are susceptible to interception and modification. Organizations relying on commercial providers offering transmission as a commodity service rather than a dedicated service may find it difficult to obtain the necessary assurances, and in such cases implement compensating safeguards or explicitly accept the additional risk. An example of an alternative physical safeguard is a protected distribution system (PDS), where the distribution medium is protected against electronic or physical intercept.

;3.13.9: Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity.
:'''Discussion:''' This requirement applies to internal and external networks. Terminating network connections includes de-allocating associated TCP/IP address or port pairs at the operating system level, or de-allocating networking assignments at the application level if multiple application sessions share a single operating-system-level network connection. Organizations may establish time periods of inactivity by type of network access or for specific network accesses.

;3.13.10: Establish and manage cryptographic keys for cryptography employed in organizational systems.
:'''Discussion:''' Cryptographic key management and establishment can be performed using manual procedures or mechanisms supported by manual procedures. Organizations define key management requirements in accordance with applicable federal laws, executive orders, policies, directives, regulations, and standards. NIST Special Publications 800-56A and 800-57 Part 1 provide guidance on cryptographic key management and establishment.

;3.13.11: Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.
:'''Discussion:''' Cryptography can support many security solutions, including protecting CUI, providing digital signatures, enforcing information separation, and supporting random number and hash generation. Cryptographic standards include FIPS-validated cryptography and/or NSA-approved cryptography.

;3.13.12: Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device.<ref>Dedicated video conferencing systems, which rely on one of the participants calling or connecting to the other party to activate the video conference, are excluded.</ref>
:'''Discussion:''' Collaborative computing devices include networked white boards, cameras, and microphones. Indication of use includes signals to users when such devices are activated.

;3.13.13: Control and monitor the use of mobile code.
:'''Discussion:''' Mobile code technologies include Java, JavaScript, ActiveX, Postscript, PDF, Flash animations, and VBScript. Decisions on the use of mobile code are based on its potential to cause damage if used maliciously; usage restrictions apply both to mobile code installed on servers and to code downloaded and executed on individual workstations, notebook computers, and devices. Mobile code policy and procedures address controlling or preventing the development, acquisition, or introduction of unacceptable mobile code, including requiring mobile code to be digitally signed by a trusted source. NIST Special Publication 800-28 provides guidance on mobile code.

;3.13.14: Control and monitor the use of Voice over Internet Protocol (VoIP) technologies.
:'''Discussion:''' VoIP has different requirements, features, functionality, availability, and service limitations compared with plain old telephone service (POTS). To address VoIP-related threats — which are similar to those inherent in any Internet-based application — usage restrictions and implementation guidelines are based on the technology's potential to cause damage if used maliciously. NIST Special Publication 800-58 provides guidance on VoIP systems.

;3.13.15: Protect the authenticity of communications sessions.
:'''Discussion:''' Authenticity protection includes protecting against man-in-the-middle attacks, session hijacking, and the insertion of false information into communications sessions. This requirement addresses communications protection at the session level (as opposed to the packet level) and establishes confidence at both ends of a session in the ongoing identity of the other party and the validity of information transmitted. NIST Special Publications 800-77, 800-95, and 800-113 provide guidance on secure communications sessions.

;3.13.16: Protect the confidentiality of CUI at rest.
:'''Discussion:''' Information at rest refers to the state of information when it is not in process or in transit and is located on storage devices as specific components of systems. Protection focuses on the state of the information rather than the type of storage device or frequency of access. Organizations can use mechanisms such as cryptography and file share scanning to achieve confidentiality protection, and may also use secure off-line storage or continuous monitoring to identify malicious code at rest.

=== 3.14 System and Information Integrity ===
==== Basic Security Requirements ====
;3.14.1: Identify, report, and correct system flaws in a timely manner.
:'''Discussion:''' Organizations identify systems affected by announced software and firmware flaws, including potential vulnerabilities resulting from those flaws, and report this information to designated personnel with information security responsibilities. Security-relevant updates include patches, service packs, hot fixes, and anti-virus signatures. Organizations address flaws discovered during security assessments, continuous monitoring, incident response activities, and system error handling, and can take advantage of resources such as the Common Weakness Enumeration (CWE) and Common Vulnerabilities and Exposures (CVE) databases. Organization-defined time periods for updating security-relevant software and firmware may vary based on factors such as the criticality of the update, and some remediation may require more testing than others. NIST Special Publication 800-40 provides guidance on patch management technologies.

;3.14.2: Provide protection from malicious code at designated locations within organizational systems.
:'''Discussion:''' Designated locations include system entry and exit points, which may include firewalls, remote-access servers, workstations, electronic mail servers, web servers, proxy servers, notebook computers, and mobile devices. Malicious code includes viruses, worms, Trojan horses, and spyware, and can be encoded in various formats, contained within compressed or hidden files, or hidden using techniques such as steganography; it can be inserted via web accesses, email and attachments, and portable storage devices, typically through the exploitation of system vulnerabilities.

Malicious code protection mechanisms include anti-virus signature definitions and reputation-based technologies. Pervasive configuration management and comprehensive software integrity controls may be effective in preventing execution of unauthorized code. Malicious code may also be present in custom-built software (e.g., logic bombs, back doors), which traditional protection mechanisms cannot always detect; in these situations organizations rely on secure coding practices, configuration management and control, trusted procurement processes, and monitoring practices. NIST Special Publication 800-83 provides guidance on malware incident prevention.

;3.14.3: Monitor system security alerts and advisories and take action in response.
:'''Discussion:''' There are many publicly available sources of system security alerts and advisories, for example the Department of Homeland Security's Cybersecurity and Infrastructure Security Agency (CISA), which generates alerts and advisories to maintain situational awareness across the federal government and nonfederal organizations. Software vendors, subscription services, and industry information sharing and analysis centers (ISACs) may also provide alerts and advisories. Response actions can include notifying relevant external organizations, such as mission/business partners, supply chain partners, external service providers, and peer or supporting organizations. NIST Special Publication 800-161 provides guidance on supply chain risk management.

==== Derived Security Requirements ====
;3.14.4: Update malicious code protection mechanisms when new releases are available.
:'''Discussion:''' Malicious code protection mechanisms include anti-virus signature definitions and reputation-based technologies. As with 3.14.2, pervasive configuration management and comprehensive software integrity controls help prevent execution of unauthorized code, including custom-built malicious code that traditional mechanisms cannot always detect, in which case organizations rely on secure coding practices, configuration management, trusted procurement, and monitoring.

;3.14.5: Perform periodic scans of organizational systems and real-time scans of files from external sources as files are downloaded, opened, or executed.
:'''Discussion:''' Periodic and real-time scans can detect malicious code, which can be encoded in various formats, contained within compressed or hidden files, or hidden using techniques such as steganography, and inserted through web accesses, email and attachments, or portable storage devices via the exploitation of system vulnerabilities.

;3.14.6: Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.
:'''Discussion:''' System monitoring includes external monitoring (observation of events at the system boundary, part of perimeter defense and boundary protection) and internal monitoring (observation of events within the system). Organizations can monitor systems by observing audit record activities in real time or by observing access patterns and other actions, using tools such as intrusion detection and prevention systems, malicious code protection software, scanning tools, audit record monitoring software, and network monitoring software. Strategic locations for monitoring devices include selected perimeter locations and near server farms supporting critical applications.

System monitoring is an integral part of continuous monitoring and incident response programs. Unusual or unauthorized activities or conditions related to inbound/outbound communications traffic include internal traffic indicating the presence of malicious code, unauthorized exporting of information, or signaling to external systems; evidence of malicious code is used to identify potentially compromised systems or components. NIST Special Publication 800-94 provides guidance on intrusion detection and prevention systems.

;3.14.7: Identify unauthorized use of organizational systems.
:'''Discussion:''' System monitoring, comprising external and internal monitoring, can detect unauthorized use of organizational systems and is an integral part of continuous monitoring and incident response programs, achieved through tools such as intrusion detection and prevention systems, malicious code protection software, scanning tools, audit record monitoring software, and network monitoring software. Unusual/unauthorized activities or conditions related to communications traffic include internal traffic indicating malicious code, unauthorized exporting of information, or signaling to external systems. NIST Special Publication 800-94 provides guidance on intrusion detection and prevention systems.

<references/>

== Appendix A: References ==
''Laws, executive orders, regulations, instructions, standards, and guidelines. References in this section without specific publication dates or revision numbers are assumed to refer to the most recent updates to those publications.''

=== Laws And Executive Orders ===
; [ATOM54]
: Atomic Energy Act (P.L. 83-703), August 1954.

; [FOIA96]
: Freedom of Information Act (FOIA), 5 U.S.C. § 552, As Amended By Public Law No. 104-231, 110 Stat. 3048, Electronic Freedom of Information Act Amendments of 1996. https://www.govinfo.gov/app/details/STATUTE-68/STATUTE-68-Pg919 https://www.govinfo.gov/app/details/PLAW-104publ231

; [FISMA]
: Federal Information Security Modernization Act (P.L. 113-283), December 2014. https://www.govinfo.gov/app/details/PLAW-113publ283

; [40 USC 11331]
: Title 40 U.S. Code, Sec. 11331, Responsibilities for Federal information systems standards. 2017 ed. https://www.govinfo.gov/app/details/USCODE-2017-title40/USCODE-2017-title40subtitleIII-chap113-subchapIII-sec11331

; [44 USC 3502]
: Title 44 U.S. Code, Sec. 3502, Definitions. 2017 ed.

; [44 USC 3552]
: Title 44 U.S. Code, Sec. 3552, Definitions. 2017 ed.

; [44 USC 3554]
: Title 44 U.S. Code, Sec. 3554, Federal agency responsibilities. 2017 ed.

; [EO 13526]
: Executive Order 13526 (2009) Classified National Security Information. (The White House, Washington, DC), DCPD-200901022, December 29, 2009. https://www.govinfo.gov/app/details/USCODE-2017-title44/USCODE-2017-title44chap35-subchapI-sec3502 https://www.govinfo.gov/app/details/USCODE-2017-title44/USCODE-2017-title44chap35-subchapII-sec3552 https://www.govinfo.gov/app/details/USCODE-2017-title44/USCODE-2017-title44chap35-subchapII-sec3554 https://www.govinfo.gov/app/details/DCPD-200901022

; [EO 13556]
: Executive Order 13556 (2010) Controlled Unclassified Information. (The White House, Washington, DC), DCPD-201000942, November 4, 2010. https://www.govinfo.gov/app/details/DCPD-201000942

=== Policies, Regulations, Directives, And Instructions ===
; [32 CFR 2002]
: 32 CFR Part 2002, Controlled Unclassified Information, September 2016. https://www.govinfo.gov/app/details/CFR-2017-title32-vol6/CFR-2017-title32vol6-part2002/summary

; [OMB A-130]
: Office of Management and Budget (2016) Managing Information as a Strategic Resource. (The White House, Washington, DC), OMB Circular A130, July 2016. https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A130/a130revised.pdf

; [CNSSI 4009]
: Committee on National Security Systems (2015) Committee on National Security Systems (CNSS) Glossary. (National Security Agency, Fort George G. Meade, MD), CNSS Instruction 4009. https://www.cnss.gov/CNSS/issuances/Instructions.cfm

=== Standards, Guidelines, And Reports ===
; [ISO 27001]
: International Organization for Standardization/International Electrotechnical Commission (2013) Information Technology—Security techniques— Information security management systems—Requirements. (International Organization for Standardization, Geneva, Switzerland), ISO/IEC 27001:2013. https://www.iso.org/standard/54534.html

; [FIPS 199]
: National Institute of Standards and Technology (2004) Standards for Security Categorization of Federal Information and Information Systems. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 199. https://doi.org/10.6028/NIST.FIPS.199

; [FIPS 200]
: National Institute of Standards and Technology (2006) Minimum Security Requirements for Federal Information and Information Systems. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 200. https://doi.org/10.6028/NIST.FIPS.200

; [SP 800-18]
: Swanson MA, Hash J, Bowen P (2006) Guide for Developing Security Plans for Federal Information Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-18, Rev. 1. https://doi.org/10.6028/NIST.SP.800-18r1

; [SP 800-28]
: Jansen W, Winograd T, Scarfone KA (2008) Guidelines on Active Content and Mobile Code. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-28, Version 2. https://doi.org/10.6028/NIST.SP.800-28ver2

; [SP 800-30]
: Joint Task Force Transformation Initiative (2012) Guide for Conducting Risk Assessments. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-30, Rev. 1. https://doi.org/10.6028/NIST.SP.800-30r1

; [SP 800-39]
: Joint Task Force Transformation Initiative (2011) Managing Information Security Risk: Organization, Mission, and Information System View. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-39. https://doi.org/10.6028/NIST.SP.800-39

; [SP 800-40]
: Souppaya MP, Scarfone KA (2013) Guide to Enterprise Patch Management Technologies. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-40, Rev. 3. https://doi.org/10.6028/NIST.SP.800-40r3

; [SP 800-41]
: Scarfone KA, Hoffman P (2009) Guidelines on Firewalls and Firewall Policy. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-41, Rev. 1. https://doi.org/10.6028/NIST.SP.800-41r1

; [SP 800-46]
: Souppaya MP, Scarfone KA (2016) Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-46, Rev. 2. https://doi.org/10.6028/NIST.SP.800-46r2

; [SP 800-50]
: Wilson M, Hash J (2003) Building an Information Technology Security Awareness and Training Program. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-50. https://doi.org/10.6028/NIST.SP.800-50

; [SP 800-53]
: Joint Task Force Transformation Initiative (2013) Security and Privacy Controls for Federal Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53, Rev. 4, Includes updates as of January 22, 2015. https://doi.org/10.6028/NIST.SP.800-53r4

; [SP 800-53A]
: Joint Task Force Transformation Initiative (2014) Assessing Security and Privacy Controls in Federal Information Systems and Organizations: Building Effective Assessment Plans. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53A, Rev. 4, Includes updates as of December 18, 2014. https://doi.org/10.6028/NIST.SP.800-53Ar4

; [SP 800-53B]
: Control Baselines and Tailoring Guidance for Federal Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), Draft NIST Special Publication (SP) 800-53B. [Forthcoming].

; [SP 800-56A]
: Barker EB, Chen L, Roginsky A, Vassilev A, Davis R (2018) Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-56A, Rev. 3. https://doi.org/10.6028/NIST.SP.800-56Ar3

; [SP 800-57-1]
: Barker EB (2016) Recommendation for Key Management, Part 1: General. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-57 Part 1, Rev. 4. https://doi.org/10.6028/NIST.SP.800-57pt1r4

; [SP 800-58]
: Kuhn R, Walsh TJ, Fries S (2005) Security Considerations for Voice Over IP Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-58. https://doi.org/10.6028/NIST.SP.800-58

; [SP 800-60-1]
: Stine KM, Kissel RL, Barker WC, Fahlsing J, Gulick J (2008) Guide for Mapping Types of Information and Information Systems to Security Categories. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-60, Vol. 1, Rev. 1. https://doi.org/10.6028/NIST.SP.800-60v1r1

; [SP 800-60-2]
: Stine KM, Kissel RL, Barker WC, Lee A, Fahlsing J (2008) Guide for Mapping Types of Information and Information Systems to Security Categories: Appendices. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-60, Vol. 2, Rev. 1. https://doi.org/10.6028/NIST.SP.800-60v2r1

; [SP 800-61]
: Cichonski PR, Millar T, Grance T, Scarfone KA (2012) Computer Security Incident Handling Guide. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-61, Rev. 2. https://doi.org/10.6028/NIST.SP.800-61r2

; [SP 800-63-3]
: Grassi PA, Garcia ME, Fenton JL (2017) Digital Identity Guidelines. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-63-3, Includes updates as of December 1, 2017. https://doi.org/10.6028/NIST.SP.800-63-3

; [SP 800-70]
: Quinn SD, Souppaya MP, Cook MR, Scarfone KA (2018) National Checklist Program for IT Products: Guidelines for Checklist Users and Developers. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-70, Rev. 4. https://doi.org/10.6028/NIST.SP.800-70r4

; [SP 800-77]
: Frankel SE, Kent K, Lewkowski R, Orebaugh AD, Ritchey RW, Sharma SR (2005) Guide to IPsec VPNs. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-77. https://doi.org/10.6028/NIST.SP.800-77

; [SP 800-83]
: Souppaya MP, Scarfone KA (2013) Guide to Malware Incident Prevention and Handling for Desktops and Laptops. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-83, Rev. 1. https://doi.org/10.6028/NIST.SP.800-83r1

; [SP 800-84]
: Grance T, Nolan T, Burke K, Dudley R, White G, Good T (2006) Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-84. https://doi.org/10.6028/NIST.SP.800-84

; [SP 800-86]
: Kent K, Chevalier S, Grance T, Dang H (2006) Guide to Integrating Forensic Techniques into Incident Response. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-86. https://doi.org/10.6028/NIST.SP.800-86

; [SP 800-88]
: Kissel RL, Regenscheid AR, Scholl MA, Stine KM (2014) Guidelines for Media Sanitization. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-88, Rev. 1. https://doi.org/10.6028/NIST.SP.800-88r1

; [SP 800-92]
: Kent K, Souppaya MP (2006) Guide to Computer Security Log Management. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-92. https://doi.org/10.6028/NIST.SP.800-92

; [SP 800-94]
: Scarfone KA, Mell PM (2007) Guide to Intrusion Detection and Prevention Systems (IDPS). (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-94. https://doi.org/10.6028/NIST.SP.800-94

; [SP 800-95]
: Singhal A, Winograd T, Scarfone KA (2007) Guide to Secure Web Services. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-95. https://doi.org/10.6028/NIST.SP.800-95

; [SP 800-97]
: Frankel SE, Eydt B, Owens L, Scarfone KA (2007) Establishing Wireless Robust Security Networks: A Guide to IEEE 802.11i. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-97. https://doi.org/10.6028/NIST.SP.800-97

; [SP 800-101]
: Ayers RP, Brothers S, Jansen W (2014) Guidelines on Mobile Device Forensics. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-101, Rev. 1. https://doi.org/10.6028/NIST.SP.800-101r1

; [SP 800-111]
: Scarfone KA, Souppaya MP, Sexton M (2007) Guide to Storage Encryption Technologies for End User Devices. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-111. https://doi.org/10.6028/NIST.SP.800-111

; [SP 800-113]
: Frankel SE, Hoffman P, Orebaugh AD, Park R (2008) Guide to SSL VPNs. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-113. https://doi.org/10.6028/NIST.SP.800-113

; [SP 800-114]
: Souppaya MP, Scarfone KA (2016) User's Guide to Telework and Bring Your Own Device (BYOD) Security. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-114, Rev. 1. https://doi.org/10.6028/NIST.SP.800-114r1

; [SP 800-124]
: Souppaya MP, Scarfone KA (2013) Guidelines for Managing the Security of Mobile Devices in the Enterprise. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-124, Rev. 1. https://doi.org/10.6028/NIST.SP.800-124r1

; [SP 800-125B]
: Chandramouli R (2016) Secure Virtual Network Configuration for Virtual Machine (VM) Protection. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-125B. https://doi.org/10.6028/NIST.SP.800-125B

; [SP 800-128]
: Johnson LA, Dempsey KL, Ross RS, Gupta S, Bailey D (2011) Guide for Security-Focused Configuration Management of Information Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-128. https://doi.org/10.6028/NIST.SP.800-128

; [SP 800-137]
: Dempsey KL, Chawla NS, Johnson LA, Johnston R, Jones AC, Orebaugh AD, Scholl MA, Stine KM (2011) Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-137. https://doi.org/10.6028/NIST.SP.800-137

; [SP 800-160-1]
: Ross RS, Oren JC, McEvilley M (2016) Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-160, Vol. 1, Includes updates as of March 21, 2018. https://doi.org/10.6028/NIST.SP.800-160v1

; [SP 800-161]
: Boyens JM, Paulsen C, Moorthy R, Bartol N (2015) Supply Chain Risk Management Practices for Federal Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-161. https://doi.org/10.6028/NIST.SP.800-161

; [SP 800-167]
: Sedgewick A, Souppaya MP, Scarfone KA (2015) Guide to Application Whitelisting. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-167. https://doi.org/10.6028/NIST.SP.800-167

; [SP 800-171A]
: Ross RS, Dempsey KL, Pillitteri VY (2018) Assessing Security Requirements for Controlled Unclassified Information. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-171A. https://doi.org/10.6028/NIST.SP.800-171A

; [SP 800-181]
: Newhouse WD, Witte GA, Scribner B, Keith S (2017) National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-181. https://doi.org/10.6028/NIST.SP.800-181

=== Miscellaneous Publications And Websites ===
; [IETF 5905]
: Mills D, Martin J (ed.), Burbank J, Kasch W (2010) Network Time Protocol Version 4: Protocol and Algorithms Specification. (Internet Engineering Task Force), IETF Request for Comments (RFC) 5905. https://doi.org/10.17487/RFC5905

; [NARA CUI]
: National Archives and Records Administration (2019) Controlled Unclassified Information (CUI) Registry. https://www.archives.gov/cui

; [NARA MARK]
: National Archives and Records Administration (2016) Marking Controlled Unclassified Information, Version 1.1. (National Archives, Washington, DC). https://www.archives.gov/files/cui/20161206-cui-marking-handbook-v1-1.pdf CUI Notice 2019-01, Controlled Unclassified Information Coversheets and Labels. https://www.archives.gov/files/cui/documents/20190222-cui-notice-2019-01coversheet-label.pdf

; [NIST CAVP]
: National Institute of Standards and Technology (2019) Cryptographic Algorithm Validation Program. https://csrc.nist.gov/projects/cavp

; [NIST CMVP]
: National Institute of Standards and Technology (2019) Cryptographic Module Validation Program. https://csrc.nist.gov/projects/cmvp

; [NIST CRYPTO]
: National Institute of Standards and Technology (2019) Cryptographic Standards and Guidelines. https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines

; [NIST CSF]
: National Institute of Standards and Technology (2018) Framework for Improving Critical Infrastructure Cybersecurity, Version 1.1. (National Institute of Standards and Technology, Gaithersburg, MD). https://doi.org/10.6028/NIST.CSWP.04162018

; [NIST CUI]
: National Institute of Standards and Technology (2019) Special Publication 800-171 Publication and Supporting Resources. https://csrc.nist.gov/publications/detail/sp/800-171/rev-1/final

== Appendix B: Glossary ==
''Common terms and definitions used within this publication. Unless specifically defined in this glossary, all terms are consistent with the definitions in CNSSI 4009, the ''National Information Assurance Glossary''.''

; advanced persistent threat
: An adversary that possesses sophisticated levels of expertise and significant resources which allow it to create opportunities to achieve its objectives by using multiple attack vectors including, for example, cyber, physical, and deception. These objectives typically include establishing and extending footholds within the IT infrastructure of the targeted organizations for purposes of exfiltrating information, undermining or impeding critical aspects of a mission, program, or organization; or positioning itself to carry out these objectives in the future. The advanced persistent threat pursues its objectives repeatedly over an extended period; adapts to defenders’ efforts to resist it; and is determined to maintain the level of interaction needed to execute its objectives.

; agency
: Any executive agency or department, military department, Federal Government corporation, Federal Government-controlled corporation, or other establishment in the Executive Branch of the Federal Government, or any independent regulatory agency.

; assessment
: See security control assessment.

; assessor
: See security control assessor.

; audit log
: A chronological record of system activities, including records of system accesses and operations performed in a given period.

; audit record
: An individual entry in an audit log related to an audited event.

; authentication
: Verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in a system. [FIPS 200, Adapted]

; availability
: Ensuring timely and reliable access to and use of information.

; baseline configuration
: A documented set of specifications for a system, or a configuration item within a system, that has been formally reviewed and agreed on at a given point in time, and which can be changed only through change control procedures. [OMB A-130] [44 USC 3552] [SP 800-39]

; bidirectional authentication
: Two parties authenticating each other at the same time. Also known as mutual authentication or two-way authentication.

; blacklisting
: A process used to identify software programs that are not authorized to execute on a system or prohibited Universal Resource Locators (URL)/websites.

; confidentiality
: Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.

; configuration management
: A collection of activities focused on establishing and maintaining the integrity of information technology products and systems, through control of processes for initializing, changing, and monitoring the configurations of those products and systems throughout the system development life cycle.

; configuration settings
: The set of parameters that can be changed in hardware, software, or firmware that affect the security posture and/or functionality of the system.

; controlled area
: Any area or space for which the organization has confidence that the physical and procedural protections provided are sufficient to meet the requirements established for protecting the information or system.

; controlled unclassified information
: Information that law, regulation, or governmentwide policy requires to have safeguarding or disseminating controls, excluding information that is classified under Executive Order 13526, Classified National Security Information, December 29, 2009, or any predecessor or successor order, or the Atomic Energy Act of 1954, as amended.

; CUI categories
: Those types of information for which laws, regulations, or governmentwide policies require or permit agencies to exercise safeguarding or dissemination controls, and which the CUI Executive Agent has approved and listed in the CUI Registry.

; CUI Executive Agent
: The National Archives and Records Administration (NARA), which implements the executive branch-wide CUI Program and oversees federal agency actions to comply with Executive Order 13556. NARA has delegated this authority to the Director of the Information Security Oversight Office (ISOO).

; CUI program
: The executive branch-wide program to standardize CUI handling by all federal agencies. The program includes the rules, organization, and procedures for CUI, established by Executive Order 13556, 32 CFR Part 2002, and the CUI Registry. [44 USC 3552] [EO 13556] [32 CFR 2002]

; CUI registry
: The online repository for all information, guidance, policy, and requirements on handling CUI, including everything issued by the CUI Executive Agent other than 32 CFR Part 2002. Among other information, the CUI Registry identifies all approved CUI categories, provides general descriptions for each, identifies the basis for controls, establishes markings, and includes guidance on handling procedures.

; cyber-physical systems
: Interacting digital, analog, physical, and human components engineered for function through integrated physics and logic.

; dual authorization
: The system of storage and handling designed to prohibit individual access to certain resources by requiring the presence and actions of at least two authorized persons, each capable of detecting incorrect or unauthorized security procedures with respect to the task being performed.

; executive agency
: An executive department specified in 5 U.S.C. Sec. 101; a military department specified in 5 U.S.C. Sec. 102; an independent establishment as defined in 5 U.S.C. Sec. 104(1); and a wholly owned Government corporation fully subject to the provisions of 31 U.S.C. Chapter 91.

; external network
: A network not controlled by the organization.

; external system (or component)
: A system or component of a system that is outside of the authorization boundary established by the organization and for which the organization typically has no direct control over the application of required security controls or the assessment of security control effectiveness.

; external system service
: A system service that is implemented outside of the authorization boundary of the organizational system (i.e., a service that is used by, but not a part of, the organizational system) and for which the organization typically has no direct control over the application of required security controls or the assessment of security control effectiveness.

; external system service provider
: A provider of external system services to an organization through a variety of consumer-producer relationships including, but not limited to: joint ventures; business partnerships; outsourcing arrangements (i.e., through contracts, interagency agreements, lines of business arrangements); licensing agreements; and/or supply chain exchanges.

; federal agency
: See executive agency.

; federal information system
: An information system used or operated by an executive agency, by a contractor of an executive agency, or by another organization on behalf of an executive agency. [32 CFR 2002] [CNSSI 4009, Adapted] [OMB A-130] [40 USC 11331]

; FIPS-validated cryptography
: A cryptographic module validated by the Cryptographic Module Validation Program (CMVP) to meet requirements specified in FIPS Publication 140-2 (as amended). As a prerequisite to CMVP validation, the cryptographic module is required to employ a cryptographic algorithm implementation that has successfully passed validation testing by the Cryptographic Algorithm Validation Program (CAVP). See NSA-approved cryptography.

; firmware
: Computer programs and data stored in hardware - typically in read-only memory (ROM) or programmable read-only memory (PROM) - such that the programs and data cannot be dynamically written or modified during execution of the programs. See hardware and software.

; hardware
: The material physical components of a system. See software and firmware.

; identifier
: Unique data used to represent a person’s identity and associated attributes. A name or a card number are examples of identifiers. A unique label used by a system to indicate a specific entity, object, or group.

; impact
: With respect to security, the effect on organizational operations, organizational assets, individuals, other organizations, or the Nation (including the national security interests of the United States) of a loss of confidentiality, integrity, or availability of information or a system. With respect to privacy, the adverse effects that individuals could experience when an information system processes their PII.

; impact value
: The assessed worst-case potential impact that could result from a compromise of the confidentiality, integrity, or availability of information expressed as a value of low, moderate or high.

; incident
: An occurrence that actually or imminently jeopardizes, without lawful authority, the confidentiality, integrity, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies.

; information
: Any communication or representation of knowledge such as facts, data, or opinions in any medium or form, including textual, numerical, graphic, cartographic, narrative, electronic, or audiovisual forms.

; information flow control
: Procedure to ensure that information transfers within a system are not made in violation of the security policy.

; information resources
: Information and related resources, such as personnel, equipment, funds, and information technology. [CNSSI 4009] [FIPS 199] [44 USC 3552] [OMB A-130] [44 USC 3502]

; information security
: The protection of information and systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide confidentiality, integrity, and availability.

; information system
: A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.

; information technology
: Any services, equipment, or interconnected system(s) or subsystem(s) of equipment, that are used in the automatic acquisition, storage, analysis, evaluation, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the agency. For purposes of this definition, such services or equipment if used by the agency directly or is used by a contractor under a contract with the agency that requires its use; or to a significant extent, its use in the performance of a service or the furnishing of a product. Information technology includes computers, ancillary equipment (including imaging peripherals, input, output, and storage devices necessary for security and surveillance), peripheral equipment designed to be controlled by the central processing unit of a computer, software, firmware and similar procedures, services (including cloud computing and help-desk services or other professional services which support any point of the life cycle of the equipment or service), and related resources. Information technology does not include any equipment that is acquired by a contractor incidental to a contract which does not require its use.

; insider threat
: The threat that an insider will use her/his authorized access, wittingly or unwittingly, to do harm to the security of the United States. This threat can include damage to the United States through espionage, terrorism, unauthorized disclosure, or through the loss or degradation of departmental resources or capabilities.

; integrity
: Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity.

; internal network
: A network where establishment, maintenance, and provisioning of security controls are under the direct control of organizational employees or contractors; or the cryptographic encapsulation or similar security technology implemented between organizationcontrolled endpoints, provides the same effect (with regard to confidentiality and integrity). An internal network is typically organization-owned, yet may be organization-controlled while not being organization-owned. [44 USC 3552] [44 USC 3502] [OMB A-130]

; least privilege
: The principle that a security architecture is designed so that each entity is granted the minimum system authorizations and resources that the entity needs to perform its function.

; local access
: Access to an organizational system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network.

; malicious code
: Software or firmware intended to perform an unauthorized process that will have adverse impact on the confidentiality, integrity, or availability of a system. A virus, worm, Trojan horse, or other code-based entity that infects a host. Spyware and some forms of adware are also examples of malicious code.

; media
: Physical devices or writing surfaces including, but not limited to, magnetic tapes, optical disks, magnetic disks, Large-Scale Integration (LSI) memory chips, and printouts (but not including display media) onto which information is recorded, stored, or printed within a system.

; mobile code
: Software programs or parts of programs obtained from remote systems, transmitted across a network, and executed on a local system without explicit installation or execution by the recipient.

; mobile device
: A portable computing device that has a small form factor such that it can easily be carried by a single individual; is designed to operate without a physical connection (e.g., wirelessly transmit or receive information); possesses local, nonremovable/removable data storage; and includes a selfcontained power source. Mobile devices may also include voice communication capabilities, on-board sensors that allow the devices to capture information, or built-in features that synchronize local data with remote locations. Examples include smartphones, tablets, and E-readers.

; multifactor authentication
: Authentication using two or more different factors to achieve authentication. Factors include something you know (e.g., PIN, password); something you have (e.g., cryptographic identification device, token); or something you are (e.g., biometric). See authenticator.

; mutual authentication [CNSSI 4009]
: The process of both entities involved in a transaction verifying each other. See bidirectional authentication.

; network
: A system implemented with a collection of interconnected components. Such components may include routers, hubs, cabling, telecommunications controllers, key distribution centers, and technical control devices. [FIPS 200]

; network access
: Access to a system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, Internet).

; nonfederal organization
: An entity that owns, operates, or maintains a nonfederal system.

; nonfederal system
: A system that does not meet the criteria for a federal system.

; nonlocal maintenance
: Maintenance activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network.

; on behalf of (an agency)
: A situation that occurs when: (i) a non-executive branch entity uses or operates an information system or maintains or collects information for the purpose of processing, storing, or transmitting Federal information; and (ii) those activities are not incidental to providing a service or product to the government.

; organization
: An entity of any size, complexity, or positioning within an organizational structure.

; personnel security
: The discipline of assessing the conduct, integrity, judgment, loyalty, reliability, and stability of individuals for duties and responsibilities requiring trustworthiness.

; portable storage device
: A system component that can be inserted into and removed from a system, and that is used to store data or information (e.g., text, video, audio, and/or image data). Such components are typically implemented on magnetic, optical, or solid-state devices (e.g., floppy disks, compact/digital video disks, flash/thumb drives, external hard disk drives, and flash memory cards/drives that contain nonvolatile memory).

; potential impact
: The loss of confidentiality, integrity, or availability could be expected to have: (i) a limited adverse effect (FIPS Publication 199 low); (ii) a serious adverse effect (FIPS Publication 199 moderate); or (iii) a severe or catastrophic adverse effect (FIPS Publication 199 high) on organizational operations, organizational assets, or individuals.

; privileged account
: A system account with authorizations of a privileged user.

; privileged user
: A user that is authorized (and therefore, trusted) to perform security-relevant functions that ordinary users are not authorized to perform.

; records
: The recordings (automated and/or manual) of evidence of activities performed or results achieved (e.g., forms, reports, test results), which serve as a basis for verifying that the organization and the system are performing as intended. Also used to refer to units of related data fields (i.e., groups of data fields that can be accessed by a program and that contain the complete set of information on particular items).

; remote access
: Access to an organizational system by a user (or a process acting on behalf of a user) communicating through an external network (e.g., the Internet). [32 CFR 2002] [FIPS 200, Adapted] [SP 800-53] [FIPS 199]

; remote maintenance
: Maintenance activities conducted by individuals communicating through an external network (e.g., the Internet).

; replay resistance
: Protection against the capture of transmitted authentication or access control information and its subsequent retransmission with the intent of producing an unauthorized effect or gaining unauthorized access.

; risk
: A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically is a function of: (i) the adverse impact, or magnitude of harm, that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence.

; risk assessment
: The process of identifying risks to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation of a system.

; sanitization
: Actions taken to render data written on media unrecoverable by both ordinary and, for some forms of sanitization, extraordinary means. Process to remove information from media such that data recovery is not possible. It includes removing all classified labels, markings, and activity logs.

; security
: A condition that results from the establishment and maintenance of protective measures that enable an organization to perform its mission or critical functions despite risks posed by threats to its use of systems. Protective measures may involve a combination of deterrence, avoidance, prevention, detection, recovery, and correction that should form part of the organization’s risk management approach.

; security assessment
: See security control assessment.

; security control
: The safeguards or countermeasures prescribed for an information system or an organization to protect the confidentiality, integrity, and availability of the system and its information.

; security control assessment
: The testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization.

; security domain
: A domain that implements a security policy and is administered by a single authority.

; security functions
: The hardware, software, or firmware of the system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. [OMB A-130] [SP 800-30] [CNSSI 4009] [CNSSI 4009, Adapted]

; split tunneling
: The process of allowing a remote user or device to establish a non-remote connection with a system and simultaneously communicate via some other connection to a resource in an external network. This method of network access enables a user to access remote devices (e.g., a networked printer) at the same time as accessing uncontrolled networks.

; system
: See information system.

; system component
: A discrete identifiable information technology asset that represents a building block of a system and may include hardware, software, and firmware.

; system security plan
: A document that describes how an organization meets the security requirements for a system or how an organization plans to meet the requirements. In particular, the system security plan describes the system boundary; the environment in which the system operates; how the security requirements are implemented; and the relationships with or connections to other systems.

; system service
: A capability provided by a system that facilitates information processing, storage, or transmission.

; system user
: Individual, or (system) process acting on behalf of an individual, authorized to access a system.

; threat
: Any circumstance or event with the potential to adversely impact organizational operations, organizational assets, individuals, other organizations, or the Nation through a system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service.

; whitelisting
: A process used to identify software programs that are authorized to execute on a system or authorized Universal Resource Locators (URL)/websites.

; wireless technology
: Technology that permits the transfer of information between separated points without physical connection. Wireless technologies include microwave, packet radio (ultra-high frequency or very high frequency), 802.11x, and Bluetooth. [SP 800-128] [SP 800-30]

== Appendix C: Acronyms ==
{| class="wikitable"
|-
! Acronym !! Meaning
|-
| CFR || Code of Federal Regulations
|-
| CNSS || Committee on National Security Systems
|-
| CUI || Controlled Unclassified Information
|-
| CISA || Cybersecurity and Infrastructure Security Agency
|-
| DMZ || Demilitarized Zone
|-
| FAR || Federal Acquisition Regulation
|-
| FIPS || Federal Information Processing Standards
|-
| FISMA || Federal Information Security Modernization Act
|-
| IoT || Internet of Things
|-
| IP || Internet Protocol
|-
| ISO/IEC || International Organization for Standardization/International Electrotechnical Commission
|-
| ISOO || Information Security Oversight Office
|-
| IT || Information Technology
|-
| ITL || Information Technology Laboratory
|-
| NARA || National Archives and Records Administration
|-
| NFO || Nonfederal Organization
|-
| NIST || National Institute of Standards and Technology
|-
| OMB || Office of Management and Budget
|-
| SP || Special Publication
|-
| VoIP || Voice over Internet Protocol
|}

== Appendix D: Mapping Tables ==
Appendix D provides informal mappings between the CUI security requirements in Chapter Three and the relevant security controls in NIST Special Publication 800-53, Revision 4 (the moderate security control baseline).<ref>The security controls in Tables D-1 through D-14 are taken from NIST Special Publication 800-53, Revision 4. These tables were to be updated upon publication of the draft NIST Special Publication 800-53B, which would provide an update to the moderate security control baseline consistent with NIST Special Publication 800-53, Revision 5. Changes to the moderate baseline affect future updates to the basic and derived security requirements in Chapter Three.</ref> The original publication also cross-references each requirement to the relevant control(s) in ISO/IEC 27001:2013, Annex A; because that cross-reference spans a complex, multi-column table, it is summarized narratively below rather than reproduced cell-by-cell. Organizations that have implemented or plan to implement the NIST Framework for Improving Critical Infrastructure Cybersecurity can use the mapping of security requirements to SP 800-53 and ISO/IEC 27001 controls to locate the equivalent controls in the Categories and Subcategories associated with the Cybersecurity Framework's core functions: Identify, Protect, Detect, Respond, and Recover.

''Note: this summary lists the primary NIST SP 800-53, Revision 4 control(s) associated with each requirement. Consult the original publication for the full, detailed ISO/IEC 27001 sub-control cross-references, which are organized in a multi-column table not fully reproduced here.''

=== 3.1 Access Control ===
'''Table D-1: Mapping Access Control Requirements to Controls'''
{| class="wikitable"
|-
! Security Requirement !! NIST SP 800-53 Relevant Security Control(s)
|-
| 3.1.1 || AC-2
|-
| 3.1.2 || AC-3
|-
| 3.1.3 || AC-4
|-
| 3.1.4 || AC-5
|-
| 3.1.5 || AC-6
|-
| 3.1.6 || AC-6(2)
|-
| 3.1.7 || AC-6(9), AC-6(10)
|-
| 3.1.8 || AC-7
|-
| 3.1.9 || AC-8
|-
| 3.1.10 || AC-11, AC-11(1)
|-
| 3.1.11 || AC-12
|-
| 3.1.12 || AC-17(1)
|-
| 3.1.13 || AC-17(2)
|-
| 3.1.14 || AC-17(3)
|-
| 3.1.15 || AC-17(4)
|-
| 3.1.16 || AC-18
|-
| 3.1.17 || AC-18(1)
|-
| 3.1.18 || AC-19
|-
| 3.1.19 || AC-19(5)
|-
| 3.1.20 || AC-20, AC-20(1)
|-
| 3.1.21 || AC-20(2)
|-
| 3.1.22 || AC-22
|}

=== 3.2 Awareness and Training ===
'''Table D-2: Mapping Awareness and Training Requirements to Controls'''
{| class="wikitable"
|-
! Security Requirement !! NIST SP 800-53 Relevant Security Control(s)
|-
| 3.2.1 || AT-2
|-
| 3.2.2 || AT-3
|-
| 3.2.3 || AT-2(2)
|}

=== 3.3 Audit and Accountability ===
'''Table D-3: Mapping Audit and Accountability Requirements to Controls'''
{| class="wikitable"
|-
! Security Requirement !! NIST SP 800-53 Relevant Security Control(s)
|-
| 3.3.1 || AU-2, AU-3, AU-12
|-
| 3.3.2 || AU-6, AU-12
|-
| 3.3.3 || AU-2
|-
| 3.3.4 || AU-5
|-
| 3.3.5 || AU-6
|-
| 3.3.6 || AU-7
|-
| 3.3.7 || AU-8
|-
| 3.3.8 || AU-9
|-
| 3.3.9 || AU-9(4)
|}

=== 3.4 Configuration Management ===
'''Table D-4: Mapping Configuration Management Requirements to Controls'''
{| class="wikitable"
|-
! Security Requirement !! NIST SP 800-53 Relevant Security Control(s)
|-
| 3.4.1 || CM-2, CM-8
|-
| 3.4.2 || CM-6
|-
| 3.4.3 || CM-3
|-
| 3.4.4 || CM-4
|-
| 3.4.5 || CM-5
|-
| 3.4.6 || CM-7
|-
| 3.4.7 || CM-7(1)
|-
| 3.4.8 || CM-7(2), CM-7(5)
|-
| 3.4.9 || CM-11
|}

=== 3.5 Identification and Authentication ===
'''Table D-5: Mapping Identification and Authentication Requirements to Controls'''
{| class="wikitable"
|-
! Security Requirement !! NIST SP 800-53 Relevant Security Control(s)
|-
| 3.5.1 || IA-2, IA-4, IA-5, IA-8
|-
| 3.5.2 || IA-2, IA-8
|-
| 3.5.3 || IA-2(1), IA-2(2), IA-2(3), IA-2(4)
|-
| 3.5.4 || IA-2(8), IA-2(9)
|-
| 3.5.5 || IA-4
|-
| 3.5.6 || IA-4
|-
| 3.5.7 || IA-5(1)
|-
| 3.5.8 || IA-5(1)
|-
| 3.5.9 || IA-5(1)
|-
| 3.5.10 || IA-5(1)
|-
| 3.5.11 || IA-6
|}

=== 3.6 Incident Response ===
'''Table D-6: Mapping Incident Response Requirements to Controls'''
{| class="wikitable"
|-
! Security Requirement !! NIST SP 800-53 Relevant Security Control(s)
|-
| 3.6.1 || IR-2, IR-4, IR-5, IR-6, IR-7
|-
| 3.6.2 || IR-6
|-
| 3.6.3 || IR-3
|}

=== 3.7 Maintenance ===
'''Table D-7: Mapping Maintenance Requirements to Controls'''
{| class="wikitable"
|-
! Security Requirement !! NIST SP 800-53 Relevant Security Control(s)
|-
| 3.7.1 || MA-2
|-
| 3.7.2 || MA-3
|-
| 3.7.3 || MA-2, MA-3(3)
|-
| 3.7.4 || MA-3(2)
|-
| 3.7.5 || MA-4
|-
| 3.7.6 || MA-5
|}

=== 3.8 Media Protection ===
'''Table D-8: Mapping Media Protection Requirements to Controls'''
{| class="wikitable"
|-
! Security Requirement !! NIST SP 800-53 Relevant Security Control(s)
|-
| 3.8.1 || MP-2, MP-4
|-
| 3.8.2 || MP-2
|-
| 3.8.3 || MP-6
|-
| 3.8.4 || MP-3
|-
| 3.8.5 || MP-5
|-
| 3.8.6 || MP-5(4)
|-
| 3.8.7 || MP-7
|-
| 3.8.8 || MP-7(1)
|-
| 3.8.9 || CP-9
|}

=== 3.9 Personnel Security ===
'''Table D-9: Mapping Personnel Security Requirements to Controls'''
{| class="wikitable"
|-
! Security Requirement !! NIST SP 800-53 Relevant Security Control(s)
|-
| 3.9.1 || PS-3
|-
| 3.9.2 || PS-4, PS-5
|}

=== 3.10 Physical Protection ===
'''Table D-10: Mapping Physical Protection Requirements to Controls'''
{| class="wikitable"
|-
! Security Requirement !! NIST SP 800-53 Relevant Security Control(s)
|-
| 3.10.1 || PE-2, PE-3, PE-5, PE-6
|-
| 3.10.2 || PE-6, PE-20
|-
| 3.10.3 || PE-3
|-
| 3.10.4 || PE-6, PE-8
|-
| 3.10.5 || PE-3
|-
| 3.10.6 || PE-17
|}

=== 3.11 Risk Assessment ===
'''Table D-11: Mapping Risk Assessment Requirements to Controls'''
{| class="wikitable"
|-
! Security Requirement !! NIST SP 800-53 Relevant Security Control(s)
|-
| 3.11.1 || RA-3
|-
| 3.11.2 || RA-5
|-
| 3.11.3 || RA-5
|}

=== 3.12 Security Assessment ===
'''Table D-12: Mapping Security Assessment Requirements to Controls'''
{| class="wikitable"
|-
! Security Requirement !! NIST SP 800-53 Relevant Security Control(s)
|-
| 3.12.1 || CA-2
|-
| 3.12.2 || CA-5
|-
| 3.12.3 || CA-7
|-
| 3.12.4 || PL-2
|}

=== 3.13 System and Communications Protection ===
'''Table D-13: Mapping System and Communications Protection Requirements to Controls'''
{| class="wikitable"
|-
! Security Requirement !! NIST SP 800-53 Relevant Security Control(s)
|-
| 3.13.1 || SC-7
|-
| 3.13.2 || SA-8
|-
| 3.13.3 || SC-2
|-
| 3.13.4 || SC-4
|-
| 3.13.5 || SC-7(3)
|-
| 3.13.6 || SC-7(5)
|-
| 3.13.7 || SC-7(7)
|-
| 3.13.8 || SC-8, SC-8(1)
|-
| 3.13.9 || SC-10
|-
| 3.13.10 || SC-12
|-
| 3.13.11 || SC-13
|-
| 3.13.12 || SC-15
|-
| 3.13.13 || SC-18
|-
| 3.13.14 || SC-19
|-
| 3.13.15 || SC-23
|-
| 3.13.16 || SC-28
|}

=== 3.14 System and Information Integrity ===
'''Table D-14: Mapping System and Information Integrity Requirements to Controls'''
{| class="wikitable"
|-
! Security Requirement !! NIST SP 800-53 Relevant Security Control(s)
|-
| 3.14.1 || SI-2
|-
| 3.14.2 || SI-3
|-
| 3.14.3 || SI-5
|-
| 3.14.4 || SI-3
|-
| 3.14.5 || SI-3(2)
|-
| 3.14.6 || SI-4
|-
| 3.14.7 || SI-4(24)
|}

<references/>

== Appendix E: Tailoring Criteria ==
This appendix lists the security controls in the SP 800-53 moderate baseline — one of the sources, along with FIPS 200, used to develop the CUI security requirements in Chapter Three — together with the tailoring action applied to each. Tables E-1 through E-17 contain the specific tailoring actions carried out on the controls in accordance with the tailoring criteria established by NIST and NARA, which facilitated development of the CUI derived security requirements that supplement the basic security requirements.<ref>The same tailoring criteria were applied to the security requirements in FIPS 200, resulting in the CUI basic security requirements described in Chapter Three.</ref> There are three primary criteria for eliminating a security control or control enhancement from the moderate baseline:
* The control or control enhancement is uniquely federal (i.e., primarily the responsibility of the federal government);
* The control or control enhancement is not directly related to protecting the confidentiality of CUI;<ref>While the primary purpose of this publication is to define requirements to protect the confidentiality of CUI, there is a close relationship between the security objectives of confidentiality and integrity. Therefore, the security controls in the SP 800-53 moderate baseline that support protection against unauthorized disclosure also support protection against unauthorized modification.</ref> or
* The control or control enhancement is expected to be routinely satisfied by nonfederal organizations without specification.<ref>The security controls tailored out of the moderate baseline (i.e., controls marked NCO or NFO) are often included as part of an organization's comprehensive security program.</ref>

'''Table E: Tailoring action symbols'''
{| class="wikitable"
|-
! Symbol !! Tailoring criteria
|-
| NCO || Not directly related to protecting the confidentiality of CUI
|-
| FED || Uniquely federal, primarily the responsibility of the federal government
|-
| NFO || Expected to be routinely satisfied by nonfederal organizations without specification
|-
| CUI || The CUI basic or derived security requirement is reflected in, and is traceable to, the security control, control enhancement, or specific elements of the control/enhancement
|}

''Note: the security controls in these tables are taken from NIST Special Publication 800-53, Revision 4.''

=== Table E-1: Tailoring Actions For Access Controls ===
{| class="wikitable"
|-
! NIST SP 800-53 Moderate Baseline Security Control !! Tailoring Action
|-
| AC-1 — Access Control Policy and Procedures || NFO
|-
| AC-2 — Account Management || CUI
|-
| AC-2(1) — Account management | Automated system account management || NCO
|-
| AC-2(2) — Account management | Removal of temporary / emergency accounts || NCO
|-
| AC-2(3) — Account management | Disable inactive accounts || NCO
|-
| AC-2(4) — Account management | Automated audit actions || NCO
|-
| AC-3 — Access Enforcement || CUI
|-
| AC-4 — Information Flow Enforcement || CUI
|-
| AC-5 — Separation of Duties || CUI
|-
| AC-6 — Least Privilege || CUI
|-
| AC-6(1) — Least privilege | Authorize access to security functions || CUI
|-
| AC-6(2) — Least privilege | Non-privileged access for nonsecurity functions || CUI
|-
| AC-6(5) — Least privilege | Privileged accounts || CUI
|-
| AC-6(9) — Least privilege | Auditing use of privileged functions || CUI
|-
| AC-6(10) — Least privilege | Prohibit non-privileged users from executing privileged functions || CUI
|-
| AC-7 — Unsuccessful Logon Attempts || CUI
|-
| AC-8 — System Use Notification || CUI
|-
| AC-11 — Session Lock || CUI
|-
| AC-11(1) — Session lock | Pattern-hiding displays || CUI
|-
| AC-12 — Session Termination || CUI
|-
| AC-14 — Permitted Actions without Identification or Authentication || FED
|-
| AC-17 — Remote Access || CUI
|-
| AC-17(1) — Remote access | Automated monitoring / control || CUI
|-
| AC-17(2) — Remote access | Protection of confidentiality / integrity using encryption || CUI
|-
| AC-17(3) — Remote access | Managed access control points || CUI
|-
| AC-17(4) — Remote access | Privileged commands / access || CUI
|-
| AC-18 — Wireless Access || CUI
|-
| AC-18(1) — Wireless access | Authentication and encryption || CUI
|-
| AC-19 — Access Control for Mobile Devices || CUI
|-
| AC-19(5) — Access control for mobile devices | Full device / container-based encryption || CUI
|-
| AC-20 — Use of External Systems || CUI
|-
| AC-20(1) — Use of external systems | Limits on authorized use || CUI
|-
| AC-20(2) — Use of external systems | Portable storage devices || CUI
|-
| AC-21 — Information Sharing || FED
|-
| AC-22 — Publicly Accessible Content || CUI
|}

=== Table E-2: Tailoring Actions For Awareness And Training Controls ===
{| class="wikitable"
|-
! NIST SP 800-53 Moderate Baseline Security Control !! Tailoring Action
|-
| AT-1 — Security Awareness and Training Policy and Procedures || NFO
|-
| AT-2 — Security Awareness Training || CUI
|-
| AT-2(2) — Security awareness | Insider threat || CUI
|-
| AT-3 — Role-Based Security Training || CUI
|-
| AT-4 — Security Training Records || NFO
|}

=== Table E-3: Tailoring Actions For Audit And Accountability Controls ===
{| class="wikitable"
|-
! NIST SP 800-53 Moderate Baseline Security Control !! Tailoring Action
|-
| AU-1 — Audit and Accountability Policy and Procedures || NFO
|-
| AU-2 — Audit Events || CUI
|-
| AU-2(3) — Audit events | Reviews and updates || CUI
|-
| AU-3 — Content of Audit Records || CUI
|-
| AU-3(1) — Content of audit records | Additional audit information || CUI
|-
| AU-4 — Audit Storage Capacity || NCO
|-
| AU-5 — Response to Audit Logging Process Failures || CUI
|-
| AU-6 — Audit Review, Analysis, and Reporting || CUI
|-
| AU-6(1) — Audit review, analysis, and reporting | Process integration || NCO
|-
| AU-6(3) — Audit review, analysis, and reporting | Correlate audit repositories || CUI
|-
| AU-7 — Audit Reduction and Report Generation || CUI
|-
| AU-7(1) — Audit reduction and report generation | Automatic processing || NCO
|-
| AU-8 — Time Stamps || CUI
|-
| AU-8(1) — Time stamps | Synchronization with authoritative time source || CUI
|-
| AU-9 — Protection of Audit Information || CUI
|-
| AU-9(4) — Protection of audit information | Access by subset of privileged users || CUI
|-
| AU-11 — Audit Record Retention || NCO
|-
| AU-12 — Audit Generation || CUI
|}

=== Table E-4: Tailoring Actions For Security Assessment And Authorization Controls ===
{| class="wikitable"
|-
! NIST SP 800-53 Moderate Baseline Security Control !! Tailoring Action
|-
| CA-1 — Security Assessment and Authorization Policies and Procedures || NFO
|-
| CA-2 — Security Assessments || CUI
|-
| CA-2(1) — Security assessments | Independent assessors || NFO
|-
| CA-3 — System Interconnections || NFO
|-
| CA-3(5) — System interconnections | Restrictions on external system connections || NFO
|-
| CA-5 — Plan of Action and Milestones || CUI
|-
| CA-6 — Security Authorization || FED
|-
| CA-7 — Continuous Monitoring || CUI
|-
| CA-7(1) — Continuous monitoring | Independent assessment || NFO
|-
| CA-9 — Internal System Connections || NFO
|}

=== Table E-5: Tailoring Actions For Configuration Management Controls ===
{| class="wikitable"
|-
! NIST SP 800-53 Moderate Baseline Security Control !! Tailoring Action
|-
| CM-1 — Configuration Management Policy and Procedures || NFO
|-
| CM-2 — Baseline Configuration || CUI
|-
| CM-2(1) — Baseline configuration | Reviews and updates || NFO
|-
| CM-2(3) — Baseline configuration | Retention of previous configurations || NCO
|-
| CM-2(7) — Baseline configuration | Configure systems, components, or devices for high-risk areas || NFO
|-
| CM-3 — Configuration Change Control || CUI
|-
| CM-3(2) — Configuration change control | Test / validate / document changes || NFO
|-
| CM-4 — Security Impact Analysis || CUI
|-
| CM-5 — Access Restrictions for Change || CUI
|-
| CM-6 — Configuration Settings || CUI
|-
| CM-7 — Least Functionality || CUI
|-
| CM-7(1) — Least functionality | Periodic review || CUI
|-
| CM-7(2) — Least functionality | Prevent program execution || CUI
|-
| CM-8 — System Component Inventory || CUI
|-
| CM-8(1) — System component inventory | Updates during installations / removals || CUI
|-
| CM-8(3) — System component inventory | Automated unauthorized component detection || NCO
|-
| CM-8(5) — System component inventory | No duplicate accounting of components || NFO
|-
| CM-9 — Configuration Management Plan || NFO
|-
| CM-10 — Software Usage Restrictions || NCO
|-
| CM-11 — User-Installed Software || CUI
|}

=== Table E-6: Tailoring Actions For Contingency Planning Controls ===
{| class="wikitable"
|-
! NIST SP 800-53 Moderate Baseline Security Control !! Tailoring Action
|-
| CP-1 — Contingency Planning Policy and Procedures || NCO
|-
| CP-2 — Contingency Plan || NCO
|-
| CP-2(1) — Contingency plan | Coordinate with related plans || NCO
|-
| CP-2(3) — Contingency plan | Resume essential missions / business functions || NCO
|-
| CP-2(8) — Contingency plan | Identify critical assets || NCO
|-
| CP-3 — Contingency Training || NCO
|-
| CP-4 — Contingency Plan Testing || NCO
|-
| CP-4(1) — Contingency plan testing | Coordinate with related plans || NCO
|-
| CP-6 — Alternate Storage Site || NCO
|-
| CP-6(1) — Alternate storage site | Separation from primary site || NCO
|-
| CP-6(3) — Alternate storage site | Accessibility || NCO
|-
| CP-7 — Alternate Processing Site || NCO
|-
| CP-7(1) — Alternate processing site | Separation from primary site || NCO
|-
| CP-7(2) — Alternate processing site | Accessibility || NCO
|-
| CP-7(3) — Alternate processing site | Priority of service || NCO
|-
| CP-8 — Telecommunications Services || NCO
|-
| CP-8(1) — Telecommunications services | Priority of service provisions || NCO
|-
| CP-8(2) — Telecommunications services | Single points of failure || NCO
|-
| CP-9 — System Backup || CUI
|-
| CP-9(1) — System backup | Testing for reliability / integrity || NCO
|-
| CP-10 — System Recovery and Reconstitution || NCO
|-
| CP-10(2) — System recovery and reconstitution | Transaction recovery || NCO
|}

=== Table E-7: Tailoring Actions For Identification And Authentication Controls ===
{| class="wikitable"
|-
! NIST SP 800-53 Moderate Baseline Security Control !! Tailoring Action
|-
| IA-1 — Identification and Authentication Policy and Procedures || NFO
|-
| IA-2 — Identification and Authentication (Organizational Users) || CUI
|-
| IA-2(1) — Identification and authentication (organizational users) | Network access to privileged || CUI
|-
| IA-2(2) — Identification and authentication (organizational users) | Network access to non-privileged || CUI
|-
| IA-2(3) — Identification and authentication (organizational users) | Local access to privileged || CUI
|-
| IA-2(8) — Identification and authentication (organizational users) | Network access to privileged || CUI
|-
| IA-2(9) — Identification and authentication (organizational users) | Network access to non-privileged || CUI
|-
| IA-2(11) — Identification and authentication (organizational users) | Remote access - separate device || FED
|-
| IA-2(12) — Identification and authentication (organizational users) | Acceptance of piv credentials || FED
|-
| IA-3 — Device Identification and Authentication || CUI
|-
| IA-4 — Identifier Management || CUI
|-
| IA-5 — Authenticator Management || CUI
|-
| IA-5(1) — Authenticator management | Password-based authentication || CUI
|-
| IA-5(2) — Authenticator management | Pki-based authentication || FED
|-
| IA-5(3) — Authenticator management | In-person or trusted third-party registration || FED
|-
| IA-5(11) — Authenticator management | Hardware token-based authentication || FED
|-
| IA-6 — Authenticator Feedback || CUI
|-
| IA-7 — Cryptographic Module Authentication || FED
|-
| IA-8 — Identification and Authentication (Non-Organizational Users) || FED
|-
| IA-8(1) — Identification and authentication (non-organizational users) | Acceptance of piv credentials || FED
|-
| IA-8(2) — Identification and authentication (non-organizational users) | Acceptance of third-party || FED
|-
| IA-8(3) — Identification and authentication (non-organizational users) | Use of ficam-approved || FED
|-
| IA-8(4) — Appendix e identification and authentication (non-organizational users) | Use of ficam-issued profiles || FED
|}

=== Table E-8: Tailoring Actions For Incident Response Controls ===
{| class="wikitable"
|-
! NIST SP 800-53 Moderate Baseline Security Control !! Tailoring Action
|-
| IR-1 — Incident Response Policy and Procedures || NFO
|-
| IR-2 — Incident Response Training || CUI
|-
| IR-3 — Incident Response Testing || CUI
|-
| IR-3(2) — Incident response testing | Coordination with related plans || NCO
|-
| IR-4 — Incident Handling || CUI
|-
| IR-4(1) — Incident handling | Automated incident handling processes || NCO
|-
| IR-5 — Incident Monitoring || CUI
|-
| IR-6 — Incident Reporting || CUI
|-
| IR-6(1) — Incident reporting | Automated reporting || NCO
|-
| IR-7 — Incident Response Assistance || CUI
|-
| IR-7(1) — Incident response assistance | Automation support for availability of information / support || NCO
|-
| IR-8 — Incident Response Plan || NFO
|}

=== Table E-9: Tailoring Actions For Maintenance Controls ===
{| class="wikitable"
|-
! NIST SP 800-53 Moderate Baseline Security Control !! Tailoring Action
|-
| MA-1 — System Maintenance Policy and Procedures || NFO
|-
| MA-2 — Controlled Maintenance || CUI
|-
| MA-3 — Maintenance Tools || CUI
|-
| MA-3(1) — Maintenance tools | Inspect tools || CUI
|-
| MA-3(2) — Maintenance tools | Inspect media || CUI
|-
| MA-4 — Nonlocal Maintenance || CUI
|-
| MA-4(2) — Nonlocal maintenance | Document nonlocal maintenance || NFO
|-
| MA-5 — Maintenance Personnel || CUI
|-
| MA-6 — Timely Maintenance || NCO
|}

=== Table E-10: Tailoring Actions For Media Protection Controls ===
{| class="wikitable"
|-
! NIST SP 800-53 Moderate Baseline Security Control !! Tailoring Action
|-
| MP-1 — Media Protection Policy and Procedures || NFO
|-
| MP-2 — Media Access || CUI
|-
| MP-3 — Media Marking || CUI
|-
| MP-4 — Media Storage || CUI
|-
| MP-5 — Media Transport || CUI
|-
| MP-5(4) — Media transport | Cryptographic protection || CUI
|-
| MP-6 — Media Sanitization || CUI
|-
| MP-7 — Media Use || CUI
|-
| MP-7(1) — Media use | Prohibit use without owner || CUI
|}

=== Table E-11: Tailoring Actions For Physical And Environmental Protection Controls ===
{| class="wikitable"
|-
! NIST SP 800-53 Moderate Baseline Security Control !! Tailoring Action
|-
| PE-1 — Physical and Environmental Protection Policy and Procedures || NFO
|-
| PE-2 — Physical Access Authorizations || CUI
|-
| PE-3 — Physical Access Control || CUI
|-
| PE-4 — Access Control for Transmission Medium || CUI
|-
| PE-5 — Access Control for Output Devices || CUI
|-
| PE-6 — Monitoring Physical Access || CUI
|-
| PE-6(1) — Monitoring physical access | Intrusion alarms / surveillance equipment || NFO
|-
| PE-8 — Visitor Access Records || NFO
|-
| PE-9 — Power Equipment and Cabling || NCO
|-
| PE-10 — Emergency Shutoff || NCO
|-
| PE-11 — Emergency Power || NCO
|-
| PE-12 — Emergency Lighting || NCO
|-
| PE-13 — Fire Protection || NCO
|-
| PE-13(3) — Fire protection | Automatic fire suppression || NCO
|-
| PE-14 — Temperature and Humidity Controls || NCO
|-
| PE-15 — Water Damage Protection || NCO
|-
| PE-16 — Delivery and Removal || NFO
|-
| PE-17 — Alternate Work Site || CUI
|}

=== Table E-12: Tailoring Actions For Planning Controls ===
{| class="wikitable"
|-
! NIST SP 800-53 Moderate Baseline Security Control !! Tailoring Action
|-
| PL-1 — Security Planning Policy and Procedures || NFO
|-
| PL-2 — System Security Plan || CUI
|-
| PL-2(3) — System security plan | Plan / coordinate with other organizational entities || NFO
|-
| PL-4 — Rules of Behavior || NFO
|-
| PL-4(1) — Rules of behavior | Social media and networking restrictions || NFO
|-
| PL-8 — Information Security Architecture || NFO
|}

=== Table E-13: Tailoring Actions For Personnel Security Controls ===
{| class="wikitable"
|-
! NIST SP 800-53 Moderate Baseline Security Control !! Tailoring Action
|-
| PS-1 — Personnel Security Policy and Procedures || NFO
|-
| PS-2 — Position Risk Designation || FED
|-
| PS-3 — Personnel Screening || CUI
|-
| PS-4 — Personnel Termination || CUI
|-
| PS-5 — Personnel Transfer || CUI
|-
| PS-6 — Access Agreements || NFO
|-
| PS-7 — Third-Party Personnel Security || NFO
|-
| PS-8 — Personnel Sanctions || NFO
|}

=== Table E-14: Tailoring Actions For Risk Assessment Controls ===
{| class="wikitable"
|-
! NIST SP 800-53 Moderate Baseline Security Control !! Tailoring Action
|-
| RA-1 — Risk Assessment Policy and Procedures || NFO
|-
| RA-2 — Security Categorization || FED
|-
| RA-3 — Risk Assessment || CUI
|-
| RA-5 — Vulnerability Scanning || CUI
|-
| RA-5(1) — Vulnerability scanning | Update tool capability || NFO
|-
| RA-5(2) — Vulnerability scanning | Update by frequency / prior to new scan / when identified || NFO
|-
| RA-5(5) — Vulnerability scanning | Privileged access || CUI
|}

=== Table E-15: Tailoring Actions For System And Services Acquisition Controls ===
{| class="wikitable"
|-
! NIST SP 800-53 Moderate Baseline Security Control !! Tailoring Action
|-
| SA-1 — System and Services Acquisition Policy and Procedures || NFO
|-
| SA-2 — Allocation of Resources || NFO
|-
| SA-3 — System Development Life Cycle || NFO
|-
| SA-4 — Acquisition Process || NFO
|-
| SA-4(1) — Acquisition process | Functional properties of security controls || NFO
|-
| SA-4(2) — Acquisition process | Design / implementation information for security controls || NFO
|-
| SA-4(9) — Acquisition process | Functions / ports / protocols / services in use || NFO
|-
| SA-4(10) — Acquisition process | Use of approved piv products || NFO
|-
| SA-5 — System Documentation || NFO
|-
| SA-8 — Security Engineering Principles || CUI
|-
| SA-9 — External System Services || NFO
|-
| SA-9(2) — External systems | Identification of functions / ports / protocols / services || NFO
|-
| SA-10 — Developer Configuration Management || NFO
|-
| SA-11 — Developer Security Testing and Evaluation || NFO
|}

=== Table E-16: Tailoring Actions For System And Communications Protection Controls ===
{| class="wikitable"
|-
! NIST SP 800-53 Moderate Baseline Security Control !! Tailoring Action
|-
| SC-1 — System and Communications Protection Policy and Procedures || NFO
|-
| SC-2 — Application Partitioning || CUI
|-
| SC-4 — Information in Shared Resources || CUI
|-
| SC-5 — Denial of Service Protection || NCO
|-
| SC-7 — Boundary Protection || CUI
|-
| SC-7(3) — Boundary protection | Access points || NFO
|-
| SC-7(4) — Boundary protection | External telecommunications services || NFO
|-
| SC-7(5) — Boundary protection | Deny by default / allow by exception || CUI
|-
| SC-7(7) — Boundary protection | Prevent split tunneling for remote devices || CUI
|-
| SC-8 — Transmission Confidentiality and Integrity || CUI
|-
| SC-8(1) — Transmission confidentiality and integrity | Cryptographic or alternate physical protection || CUI
|-
| SC-10 — Network Disconnect || CUI
|-
| SC-12 — Cryptographic Key Establishment and Management || CUI
|-
| SC-13 — Cryptographic Protection || CUI
|-
| SC-15 — Collaborative Computing Devices || CUI
|-
| SC-17 — Public Key Infrastructure Certificates || FED
|-
| SC-18 — Mobile Code || CUI
|-
| SC-19 — Voice over Internet Protocol || CUI
|-
| SC-20 — Secure Name /Address Resolution Service (Authoritative Source) || NFO
|-
| SC-21 — Secure Name /Address Resolution Service (Recursive or Caching Resolver) || NFO
|-
| SC-22 — Architecture and Provisioning for Name/Address Resolution Service || NFO
|-
| SC-23 — Session Authenticity || CUI
|-
| SC-28 — Protection of Information at Rest || CUI
|-
| SC-39 — Process Isolation || NFO
|}

=== Table E-17: Tailoring Actions For System And Information Integrity Controls ===
{| class="wikitable"
|-
! NIST SP 800-53 Moderate Baseline Security Control !! Tailoring Action
|-
| SI-1 — System and Information Integrity Policy and Procedures || NFO
|-
| SI-2 — Flaw Remediation || CUI
|-
| SI-2(2) — Flaw remediation | Automated flaw remediation status || NCO
|-
| SI-3 — Malicious Code Protection || CUI
|-
| SI-3(1) — Malicious code protection | Central management || NCO
|-
| SI-3(2) — Malicious code protection | Automatic updates || NCO
|-
| SI-4 — System Monitoring || CUI
|-
| SI-4(2) — System monitoring | Automated tools for real-time analysis || NCO
|-
| SI-4(4) — System monitoring | Inbound and outbound communications traffic || CUI
|-
| SI-4(5) — System monitoring | System-generated alerts || NFO
|-
| SI-5 — Security Alerts, Advisories, and Directives || CUI
|-
| SI-7 — Software, Firmware, and Information Integrity || NCO
|-
| SI-7(1) — Software, firmware, and information integrity | Integrity checks || NCO
|-
| SI-7(7) — Software, firmware, and information integrity | Integration of detection and response || NCO
|-
| SI-8 — Spam Protection || NCO
|-
| SI-8(1) — Spam protection | Central management || NCO
|-
| SI-8(2) — Spam protection | Automatic updates || NCO
|-
| SI-10 — Information Input Validation || NCO
|-
| SI-11 — Error Handling || NCO
|-
| SI-12 — Information Handling and Retention || FED
|-
| SI-16 — Memory Protection || NFO
|}

<references/>

MediaWiki:Sidebar

2026-07-26T01:33:03Z

David:

* navigation
** mainpage | mainpage-description
* CMMC Model and Rule
** Model_Overview | Model Overview
** 32_CFR_Part_170 | 32 CFR Part 170
** 48_CFR_Parts_204_212_217_252 | 48 CFR Parts 204, 212, 217, and 252
* Scoping and Assessment Guides
** Level_1_Scoping_Guidance | Level 1 Scoping Guidance
** Level_1_Self-Assessment_Guide | Level 1 Self-Assessment Guide
** Level_2_Scoping_Guidance | Level 2 Scoping Guidance
** Level_2_Assessment_Guide | Level 2 Assessment Guide
** Level_3_Scoping_Guidance | Level 3 Scoping Guidance
** Level_3_Assessment_Guide | Level 3 Assessment Guide
* CMMC Guides and Tools
** CMMC_Hashing_Guide | CMMC Hashing Guide
** CMMC_Assessment_Process | CMMC Assessment Process (CAP) by CyberAB
** DoD_Assessment_Methodology | DoD Assessment Methodology
** Evidence_Collection_Approach | CMMC Evidence Collection Approach
** DoD Memo on ODPs for 800-171 Revision 3 | DoD Memo on Organization-Defined Parameters for NIST 800-171 Revision 3
* Other Publications and Tools
** NIST_Cybersecurity_Framework | NIST Cybersecurity Framework (CSF): NIST Cybersecurity Framework
** NIST_SP_800-17_R2 | NIST SP 800-171 Rev. 2: Protecting CUI in Nonfederal Systems and Organizations
** NIST_SP_800-171A | NIST SP 800-171A: Assessing Security Requirements for CUI
** NIST_SP_800-17_R3 | NIST SP 800-171 Rev. 3: Protecting CUI in Nonfederal Systems and Organizations
** NIST_SP_800-171A_R3 | NIST SP 800-171A Rev. 3: Assessing Security Requirements for CUI
** NIST_SP_800-53 | NIST SP 800-53: Security and Privacy Controls for Information Systems and Organizations
** External_References | External References

MediaWiki:Sidebar

2026-07-26T01:32:13Z

David:

* navigation
** mainpage | mainpage-description
* CMMC Model and Rule
** Model_Overview | Model Overview
** 32_CFR_Part_170 | 32 CFR Part 170
** 48_CFR_Parts_204_212_217_252 | 48 CFR Parts 204, 212, 217, and 252
* Scoping and Assessment Guides
** Level_1_Scoping_Guidance | Level 1 Scoping Guidance
** Level_1_Self-Assessment_Guide | Level 1 Self-Assessment Guide
** Level_2_Scoping_Guidance | Level 2 Scoping Guidance
** Level_2_Assessment_Guide | Level 2 Assessment Guide
** Level_3_Scoping_Guidance | Level 3 Scoping Guidance
** Level_3_Assessment_Guide | Level 3 Assessment Guide
* CMMC Guides and Tools
** CMMC_Hashing_Guide | CMMC Hashing Guide
** CMMC_Assessment_Process | CMMC Assessment Process (CAP) by CyberAB
** DoD_Assessment_Methodology | DoD Assessment Methodology
** Evidence_Collection_Approach | CMMC Evidence Collection Approach
** DoD Memo on ODPs for 800-171 Revision 3 | DoD Memo on Organization-Defined Parameters for NIST 800-171 Revision 3
* Other Publications and Tools
** NIST_Cybersecurity_Framework | NIST Cybersecurity Framework (CSF): NIST Cybersecurity Framework
** NIST_SP_800-17_R2 | NIST SP 800-171 Rev. 2: Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
** NIST_SP_800-171A | NIST SP 800-171A: Assessing Security Requirements for Controlled Unclassified Information
** NIST_SP_800-17_R3 | NIST SP 800-171 Rev. 3: Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
** NIST_SP_800-171A_R3 | NIST SP 800-171A Rev. 3: Assessing Security Requirements for Controlled Unclassified Information
** NIST_SP_800-53 | NIST SP 800-53: Security and Privacy Controls for Information Systems and Organizations
** External_References | External References

48 CFR Parts 204 212 217 252

2026-07-26T01:21:57Z

David:

{{DISPLAYTITLE:Defense Federal Acquisition Regulation Supplement: Assessing Contractor Implementation of Cybersecurity Requirements (DFARS Case 2019–D041)}}
'''Source of Reference: The official [https://www.federalregister.gov/documents/2025/09/10/2025-17359/defense-federal-acquisition-regulation-supplement-assessing-contractor-implementation-of Defense Federal Acquisition Regulation Supplement: Assessing Contractor Implementation of Cybersecurity Requirements (DFARS Case 2019-D041)] final rule.'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmcwiki.org contact us]. Thank you.

== Agency Information ==

{| class="wikitable"
|-
! Field !! Value
|-
| Agency || Defense Acquisition Regulations System, Department of Defense (DoD)
|-
| Action || Final rule
|-
| Docket || DARS–2020–0034
|-
| RIN || 0750–AK81
|-
| Effective Date || November 10, 2025
|-
| Contact || Ms. Heather Kitchens, telephone 571–296–7152
|}

== Summary ==

DoD is issuing a final rule amending the Defense Federal Acquisition Regulation Supplement (DFARS) to incorporate contractual requirements related to the final Cybersecurity Maturity Model Certification (CMMC) program rule. This final DFARS rule also partially implements a section of the National Defense Authorization Act for Fiscal Year 2020 that directed the Secretary of Defense to develop a consistent, comprehensive framework to enhance cybersecurity for the U.S. defense industrial base.

== I. Background ==

* DoD published an interim rule in the Federal Register at 85 FR 61505 on September 29, 2020, to assess contractor implementation of cybersecurity requirements and enhance the protection of unclassified information within the DoD supply chain.
* DoD subsequently published a proposed rule at 89 FR 66327 on August 15, 2024, to implement the contractual requirements related to CMMC. Ninety-seven respondents submitted public comments in response to the proposed rule.
* Separately, a proposed rule to establish the CMMC program at 32 CFR part 170 was published at 88 FR 89058 on December 26, 2023. A final rule was published at 89 FR 83092 on October 15, 2024, and became effective on December 16, 2024.

== II. Discussion and Analysis ==

=== A. Summary of Significant Changes From the Proposed Rule ===

==== 1. Definitions ====

The final rule adds and modifies certain definitions at DFARS 204.7501, Definitions.

* The definition of "current" was changed to clarify that it is related to having no changes in compliance with the requirements at 32 CFR part 170, and to clarify what "current" means when referring to "Conditional CMMC Status," "Final CMMC Status," and "affirmation of continuous compliance."
* The term "DoD unique identifier" was updated to "CMMC unique identifier" to match the naming convention in the Supplier Performance Risk System (SPRS). The CMMC UID means ten alpha-numeric characters assigned to each contractor CMMC assessment and reflected in SPRS for each contractor information system.
* The final rule adds the definition of "Federal contract information" based on the definition from the clause at FAR 52.204–21.
* The final rule adds a definition of "plan of action and milestones" (POA&M) based on the definition codified at 32 CFR part 170.
* The final rule adds the term "CMMC status" and a definition for the term.

==== 2. Policy ====

DFARS 204.7502, Policy, includes language to add clarity by stating that for CMMC levels 2 and 3 only, a conditional CMMC status is permitted for a period not to exceed 180 days from the conditional CMMC date, in accordance with 32 CFR 170.21, and an award can occur with a CMMC conditional status. The language also clarifies that a final CMMC is achieved upon successful closeout of a valid POA&M.

==== 3. Procedures ====

* Language at DFARS 204.7503 was updated to add paragraph headings.
* Language clarifies that contracting officers are required to check SPRS and not award a contract, task order, or delivery order to an offeror that does not have a current CMMC status posted in SPRS at the CMMC level required by the solicitation, or higher, for each CMMC UID provided by the offeror.
* Paragraph (d) clarifies that all offerors are required to provide the CMMC UIDs applicable to each contractor information system that processes, stores, or transmits FCI or CUI and that will be used in performance of the contract.

==== 4. Clause Prescription ====

At DFARS 204.7504, the prescription for the contract clause has been updated to clarify the phased implementation approach:

* '''Until three years after the effective date of the rule''': the clause will be prescribed for use if program managers and requiring activities make a determination to apply a CMMC requirement to contracts, excluding awards solely for the acquisition of commercially available off-the-shelf (COTS) items (unless the requirements at 32 CFR 170.5(d) are met).
* '''Beginning three years and one day after the effective date of the rule''': the clause will be prescribed for use if program managers and requiring activities determine that the contractor will be required to use contractor information systems in the performance of the contract to process, store, or transmit FCI or CUI, excluding awards solely for the acquisition of COTS items.

==== 5. Solicitation Provision and Contract Clause ====

* The contract clause has been updated to include a fill-in for the contracting officer to identify the CMMC level required by the contract.
* The subcontract flowdown language has been updated to identify that subcontractors also must submit affirmations of continuous compliance and the results of self-assessments in SPRS.
* The clause has been updated to include the term "affirming official" in place of "senior company official" to match 32 CFR part 170.
* The solicitation provision and contract clause include the terminology needed for entering the CMMC level: '''CMMC Level 1 (Self)'''; '''CMMC Level 2 (Self)'''; '''CMMC Level 2 (C3PAO)'''; or '''CMMC Level 3 (DIBCAC)'''.
* The solicitation provision clarifies that offerors will not be eligible for award if the offeror does not have a current CMMC status entered in SPRS at the required level and a current affirmation of continuous compliance for each applicable contractor information system.

=== B. Analysis of Public Comments ===

''Note: Technical and programmatic comments on CMMC, and comments related to the CMMC cost analysis, were addressed in the CMMC program rule that codified 32 CFR part 170. This DFARS rule addresses the nontechnical and nonprogrammatic comments.''

==== 1. Clarification of "Changes" ====

'''Comment:''' Several respondents asked for more clarity regarding what "changes" means in the proposed rule.

'''Response:''' Based on public comment, the final DFARS rule adds the sentence: "Submit to the Contracting Officer . . . any changes in the CMMC UIDs generated in SPRS throughout the life of the contract, task order, or delivery order, if applicable." The notification requirement to report lapses in information security or changes in compliance with 32 CFR part 170 was removed, since the reporting requirement at DFARS 252.204–7012 paragraph (c) already provides sufficient notification of relevant information security incidents.

==== 2. Clarification of "Lapses in Information Security" ====

'''Comment:''' Several respondents asked for clarity on "lapses in information security" in proposed paragraph (b)(4) at DFARS 252.204–7021; several recommended it be removed.

'''Response:''' The requirement to notify the contracting officer of lapses in information security or changes in CMMC status has been removed from the final rule.

==== 3. Editorial Changes ====

'''Comment:''' Respondents identified typos and recommended using "and/or" instead of "or" for CMMC UIDs.

'''Response:''' Editorial comments were noted; most were mooted by other final-rule changes. The "and/or" recommendation was '''not''' implemented because it could narrow the scope of the requirement beyond what was intended.

==== 4. CMMC Level Notification and Compliance ====

'''Comment:''' Respondents asked how the required CMMC level will be communicated and determined, and requested clarity on phase-in exemptions for small businesses.

'''Response:''' The CMMC level determination is made in accordance with 32 CFR 170.19 (CMMC scoping) by the program office/requiring activity (for the prime contract) or the prime/next higher-tier subcontractor (for subcontracts). CMMC levels are: CMMC Level 1 (Self); CMMC Level 2 (Self); CMMC Level 2 (C3PAO); and CMMC Level 3 (DIBCAC) (see 32 CFR 170.14). DoD did not incorporate the recommendation to limit CMMC inclusion in existing contracts, as contracting officers already have discretion to bilaterally modify existing contracts.

==== 5. COTS Item Exclusion ====

'''Comment:''' Respondents requested clarification on the scope of the COTS exclusion.

'''Response:''' The rule does not apply to awards that are exclusively for COTS items, as defined at FAR 2.101. Any award exclusively for items meeting the FAR definition is considered an "exclusively COTS" award.

==== 6. Extending the Certification Time for New Bidders ====

'''Comment:''' A respondent requested an extension of certification time for new bidders.

'''Response:''' Per 32 CFR part 170, contractors must have a CMMC self-assessment or certification at time of award; there is no delayed implementation for new bidders, though 32 CFR 170.21 allows a POA&M in certain instances.

==== 7. Flowdown Requirements When Subcontractors Use Prime Contractor Information System ====

'''Comment:''' Respondents asked about flowdown when subcontractors use the prime's information system rather than their own.

'''Response:''' A subcontractor that does not process, store, or transmit FCI or CUI on its own systems has no CMMC assessment requirement. DoD does not have an automated tool giving primes visibility into subcontractor certification status in SPRS, but subcontractors may voluntarily share scores/certificates.

==== 8. Definitions ====

'''a. CUI'''

'''Comment:''' Respondents asked to define CUI and streamline it with "covered defense information."

'''Response:''' The definition of CUI incorporates the definition codified at 32 CFR part 170; modifying it further is outside the scope of this rule.

'''b. FCI'''

'''Comment:''' A respondent requested clarification of "not intended for public release" and "simple transactional information," and whether FOIA-subject information is still FCI.

'''Response:''' A definition of FCI was added, based on FAR 52.204–21, with "information necessary to process payments" as an example of simple transactional information. Marking/FOIA comments are outside scope.

'''c. Current'''

'''Comment:''' Clarify whether "current" refers to date of assessment or date of certification.

'''Response:''' The final rule changes the definition of "current" to address this; the underlying requirements were established in 32 CFR part 170, and DoD cannot make changes beyond that in this DFARS rule.

'''d. Data'''

'''Comment:''' Respondents asked that "data" be replaced with "FCI and/or CUI" to narrow scope.

'''Response:''' Based on public comments, the rule was revised to remove the term "data." The rule applies to information that is FCI and CUI only.

'''e. Contractor Information Systems'''

'''Comment:''' Respondents asked that "contractor information systems" be limited/defined more narrowly, similar to "covered contractor information systems."

'''Response:''' The rule clarifies that "contractor information systems" throughout the rule means systems "that process, store, or transmit FCI or CUI in performance of the contract."

==== 9. Regulatory Impact Analysis (RIA) Estimate ====

'''Comment:''' Several respondents said the RIA cost estimate was too low and should include all offerors and a revised estimate of average information systems per contractor.

'''Response:''' The RIA only covers costs of contractual requirements to upload self-assessments and complete affirmations in SPRS (technical/programmatic CMMC costs are addressed under 32 CFR part 170). The RIA was revised to expand the estimated impacted entities to include, in year four and beyond, all entities in the Federal Procurement Data System awarded DoD contracts FY2022–FY2024. The estimate of five information systems per contractor remains a DoD subject-matter-expert estimate.

==== 10. Application to Fundamental Research ====

'''Comment:''' Respondents raised concerns about applying CMMC to fundamental research that could become CUI.

'''Response:''' Fundamental research (per NSDD 189) is published and broadly shared and cannot be safeguarded as FCI or CUI; however, if it has the potential to become CUI, it would be subject to CMMC once it becomes CUI.

==== 11. Applicability ====

'''Comment:''' Respondents raised numerous applicability questions: FCI-only Level 1 self-assessment carve-outs, program manager documentation of rationale, existing vs. new contracts, micro-purchase threshold subcontracts, and scope of paragraph (b)(3).

'''Response:''' The clause will be included in solicitations issued on/after the effective date and in resulting contracts; contracting officers may also bilaterally incorporate the clause into existing contracts (see FAR 1.108(d)). Until three years after the effective date, CMMC applies only where program managers/requiring activities determine to apply it (excluding COTS-only awards); afterward, it applies wherever contractor information systems will process, store, or transmit FCI or CUI. 32 CFR part 170 does not allow spot checks and requires the CMMC requirement be met at time of award.

==== 12. Flowdown ====

'''Comment:''' Respondents requested clarification on flowdown scope, CUI dissemination limits, and lower-tier CMMC level determination.

'''Response:''' See 32 CFR 170.23 for flowdown guidance. Clause paragraph (d)(1) was revised to clarify flowdown applies only where the subcontract requires a CMMC level, and to no longer exclude paragraph (b)(3) (affirmation of continuous compliance) from subcontractor flowdown. The rule was '''not''' revised regarding which subcontractors must receive CUI — that determination remains with the prime contractor.

==== 13. CMMC as an Evaluation Factor ====

'''Comment:''' Is CMMC a competition evaluation factor or set-aside requirement?

'''Response:''' No. CMMC is not an evaluation factor or set-aside requirement; DFARS 204.7503 requires contracting officers not to award to an offeror that fails to meet the CMMC requirements in the solicitation, and if included in the solicitation, it becomes a contract requirement.

==== 14. Program Office Requirements ====

'''Comment:''' Require the program office to review contractor-provided information.

'''Response:''' The rule was revised to require the contracting officer to work with the program office/requiring activity to review the offeror's CMMC status and affirmation information.

==== 15. Clarifying When FCI Applies ====

'''Comment:''' Clarify that systems processing FCI (not CUI) need only CMMC Level 1.

'''Response:''' Not included in the final rule; contracting officers do not determine the required CMMC level.

==== 16. International Applicability ====

'''Comment:''' Respondents raised questions about C3PAO assessments outside the U.S., international harmonization, and foreign verification bodies (e.g., Taiwan's TAF).

'''Response:''' Contracts subject to NIST SP 800–171 compliance (e.g., via DFARS 252.204–7012) require foreign or domestic contractors to secure their systems. See 32 CFR 179 regarding foreign C3PAO accreditation; DoD permits an equivalent process for personnel ineligible for a Tier 3 background investigation, for CMMC Program purposes only.

==== 17. POA&M ====

'''Comment:''' Respondents sought clarity on POA&M closeout, conditional certification for subcontract award, and continued reliance on POA&Ms for newly discovered risks.

'''Response:''' The rule was revised to clarify (via the "current" definition) that for CMMC Levels 2 and 3 only, conditional CMMC status is permitted for up to 180 days from the conditional CMMC status date, and that final CMMC status is achieved upon successful POA&M closeout. 32 CFR part 170 does not allow additional POA&Ms beyond established scoping, other than for scenarios appropriate for an "operational plan of action" (32 CFR 170.4).

==== 18. Subcontractor Compliance ====

'''Comment:''' Respondents asked how primes monitor/verify subcontractor CMMC adherence, requested an automated SPRS visibility tool, and asked when subcontractors must be compliant.

'''Response:''' Contractors can only access their own CMMC information in SPRS; DoD has no tool for automatic sharing with primes. Subcontractors may screenshot/print their own SPRS status to share voluntarily. Prior to awarding a subcontract, the prime must ensure the subcontractor has a current CMMC status at the appropriate level. 32 CFR part 170 does not allow limiting enforcement to direct suppliers only.

==== 19. Senior Company Official ====

'''Comment:''' Respondents noted the proposed rule's "senior company official" term does not match 32 CFR part 170's "affirming official," and asked for a clear definition.

'''Response:''' The final rule updates terminology to "affirming official" to align with 32 CFR part 170 (the proposed DFARS rule used the older term due to timing of the two rulemakings).

==== 20. Task Orders and Delivery Orders ====

'''Comment:''' Will existing IDIQ contracts' task/delivery orders issued after the rule contain a CMMC requirement?

'''Response:''' Task orders or delivery orders issued after the rule's effective date may include a CMMC requirement under the prescribed clause/provision.

==== 21. Relationship Between "Covered Contractor Information Systems" and "Contractor Information Systems" ====

'''Comment:''' Clarify the relationship between the two terms and possible over-broad scope.

'''Response:''' The rule clarifies that "contractor information systems" are limited to those "that process, store, or transmit FCI or CUI during performance of the contract."

==== 22. CMMC Unique Identifiers ====

'''Comment:''' Respondents sought clarification on CMMC UIDs vs. CAGE codes, mandatory vs. optional UID submission, and prime vs. subcontractor UID reporting obligations.

'''Response:''' A CMMC UID is assigned per CMMC Assessment Scope as defined by the Organization Seeking Assessment (OSA) (see 32 CFR 170.19). SPRS/eMASS assigns the UID upon submission of assessment results. OSAs must obtain a CAGE code (via sam.gov) or NCAGE code (for non-U.S. businesses, via NSPA) and a PIEE account. Only prime contractors with a CMMC requirement must submit CMMC UIDs to the contracting officer (which may include subcontractors' UIDs); subcontractors themselves do not submit UIDs to the contracting officer. A new UID is generated whenever a new SPRS score is entered (e.g., at reassessment or 3-year renewal).

==== 23. Creation of Exception ====

'''Comment:''' Requests for exceptional-circumstance relief and small-business exemptions for second-tier suppliers.

'''Response:''' 32 CFR part 170 does not include an exemption for exceptional circumstances, and this DFARS rule cannot create one. DoD does not require flowdown to subcontractors that do not receive FCI or CUI.

==== 24. Period of Performance ====

'''Comment:''' Should contracting officers validate CMMC compliance before extending a period of performance?

'''Response:''' Yes — 32 CFR part 170 requires CMMC statuses to be maintained for the life of the contract, so contracting officers must validate compliance before extending performance periods or exercising options.

==== 25. Prime Contractor Protection From Subcontractor Noncompliance ====

'''Comment:''' Clarify that primes won't be rendered ineligible due to subcontractor noncompliance.

'''Response:''' The Government does not establish the prime/subcontractor relationship and does not indemnify the prime from its subcontractors, as it lacks privity of contract with subcontractors.

==== 26. Application of CMMC to FAR Part 16 Contract Types ====

'''Comment:''' Require CMMC Program Office/USD(A&S) approval before applying CMMC to FAR part 16 contract types during phase-in.

'''Response:''' 32 CFR part 170 does not include such an approval process, and this rule cannot create one.

==== 27. Acquiring Entities Without CMMC Certification ====

'''Comment:''' How are newly acquired entities or new sites added to an existing certification?

'''Response:''' Per DFARS 252.204–7021(c)(1), contractors must report changes to UIDs to the contracting officer. Adding new users to an existing system does not necessarily change the CMMC assessment scope (see 32 CFR 170.19).

==== 28. Applicability to Civilian Agencies ====

'''Comment:''' Does CMMC apply to CUI from non-DoD agencies?

'''Response:''' This rule amends the DFARS and applies only to DoD or DoD-funded acquisitions.

==== 29. Provision and Clause Clarifications ====

'''Comment:''' Questions on subcontractor UID updates and the "unless electronically posted" language.

'''Response:''' The clause was updated to require subcontractors to enter self-assessment results in SPRS and complete annual affirmations, which they may share via screenshot. "Unless electronically posted" language was removed. Paragraph (c)(1) is excluded from subcontractor flowdown because the Government lacks privity of contract with subcontractors, though primes are encouraged to flow down similar language voluntarily.

==== 30. Outside the Scope of the Rule ====

DoD received numerous comments outside the scope of this rule, including topics related to: the DFARS Case 2022–D017 timeline; CUI marking and definitions; the CMMC Program's underlying policy at 32 CFR part 170 (permissible changes, exemptions for MWR/NAF procurements, ISO/IEC 27001 relationship, phase-in timeline, spot checks, FedRAMP, waivers, eMASS training, and more); cost impacts; and various sector-specific applicability questions (medical devices, furniture manufacturers, common carriers, etc.).

'''Response (selected points):'''
* CMMC level selection is made by the program office/requiring activity per DoD policy and 32 CFR 170.5; contracting officers do not determine the level.
* All CUI categories require at least a self-assessment; DoD Organizational Index group CUI categories generally require a C3PAO assessment at minimum.
* MWR/NAF procurements requiring NIST SP 800–171 implementation are subject to the CMMC requirement.
* Waivers are established at 32 CFR 170.5 and are at the discretion of the program office/requiring activity, prior to contracting officer involvement.
* Contractors do not have access to CMMC eMASS (used only for certification assessments); all CMMC assessments are reflected in SPRS.
* Enclave scoping is determined by the contractor per 32 CFR 170.19.
* Reassessments are expected to be infrequent and DoD-conducted, per updates to 32 CFR part 170.
* Flowdown requirements are at 32 CFR 170.23.

=== C. Other Changes ===

* DFARS 204.7500 was updated to remove a web address and replace it with a reference to 32 CFR part 170.
* Clarified throughout that a higher CMMC level than required is also permissible.
* The term "CMMC status" was added throughout, clarifying that contracts may be awarded with a current Final Level 1 (Self), Conditional Level 2 (Self), Final Level 2 (Self), Conditional Level 2 (C3PAO), or Final Level 2 (C3PAO) CMMC status. A definition of "CMMC status" was added to DFARS subpart 204.75, clause 252.204–7021, and provision 252.204–7025.

== III. Applicability to Contracts at or Below the SAT, Commercial Products, and Commercial Services ==

The clause at DFARS 252.204–7021 is prescribed at DFARS 204.7504 for use:

* '''Until November 9, 2028''' (three years after the effective date): in solicitations and contracts, task orders, or delivery orders — including FAR part 12 commercial product/service acquisitions, except those solely for COTS items — if the program office or requiring activity determines the contractor is required to have a specific CMMC level (unless 32 CFR 170.5(d) requirements are met).
* '''On or after November 10, 2028''': in solicitations and contracts, task orders, or delivery orders — including FAR part 12 acquisitions, except those solely for COTS items — if the program office or requiring activity determines the contractor must use contractor information systems to process, store, or transmit FCI or CUI.

The provision at DFARS 252.204–7025 is prescribed at DFARS 204.7504(b) for use in solicitations that include the clause at DFARS 252.204–7021.

Consistent with DoD's analysis of section 1648 of the NDAA for FY 2020, DoD applies the statute (as implemented in these clause/provision) to contracts at or below the Simplified Acquisition Threshold (SAT), to commercial products (excluding COTS items), and to commercial services as defined at FAR 2.101.

== IV. Expected Impact of the Rule ==

=== A. Background ===

DoD is amending the DFARS to implement contractual requirements tied to the CMMC policy (32 CFR part 170, 89 FR 83092, October 15, 2024). New solicitation/contractual requirements include:

* Offeror/contractor requirement to post CMMC Level 1 or Level 2 self-assessment results to SPRS prior to award, option exercise, or period-of-performance extension, if not already posted.
* Contractor requirement to maintain the required CMMC status for the life of the contract.
* Contractor requirement for an affirming official to complete an annual affirmation of continuous compliance in SPRS for each applicable CMMC UID.
* Offeror/contractor requirement to identify contractor information systems used to process, store, or transmit FCI or CUI, by providing CMMC UIDs generated by SPRS.

=== B. Summary of Impact ===

The rule will be implemented over a phased, three-year period, after which it applies to all contracts where the contractor processes, stores, or transmits FCI or CUI on contractor information systems (except COTS-only contracts).

'''Estimated impacted entities (Year 4 and beyond):'''

{| class="wikitable"
|-
! Metric !! Value
|-
| Average unique entities awarded DoD contracts above micro-purchase threshold (FY2022–FY2024) || 32,756
|-
| Unique entities awarded using only commercial procedures || 18,370
|-
| Estimated COTS-only awardees (25% of 18,370) || 4,592
|-
| Unique entities after removing COTS-only awardees || 28,164
|-
| Assumed offerors per solicitation || 2
|-
| Total prime offerors (28,164 × 2) || 56,328
|-
| Assumed subcontractors per prime offer || 5
|-
| '''Total estimated impacted entities''' (primes + subcontractors) || '''337,968'''
|-
| Of which, small entities (68%) || 229,818
|}

'''Estimated time burden per contractor information system:'''

* Offerors/contractors: ~5 minutes to post CMMC self-assessment results in SPRS; ~5 minutes to complete the required affirmation; ~5 minutes to retrieve and submit CMMC UIDs.
* Government: ~5 minutes to validate CMMC level/currency prior to award, option exercise, or performance extension; ~5 minutes to validate affirmation currency; ~5 minutes to validate CMMC status/affirmation when UIDs change during performance.

'''Benefits:''' Verification of DIB contractors' implementation of system security requirements, protection of CUI/FCI and intellectual property, and reduced exposure to malicious cyber activity. The Council of Economic Advisers estimated malicious cyber activity cost the U.S. economy $57–109 billion in 2016 (a 10-year burden of an estimated $400–765 billion at a 7% discount rate, or $486–929 billion at a 3% discount rate). GAO cited Treasury reporting that ransomware-related incidents reached $886 million in 2021.

'''Estimated public and Government costs over a 10-year period:'''

{| class="wikitable"
|-
! Summary (3% discount rate) !! Public !! Government !! Total
|-
| Present Value || $329,097,922 || $15,812,069 || $344,909,991
|-
| Annualized Costs || $38,580,316 || $1,760,303 || $40,340,619
|}

{| class="wikitable"
|-
! Summary (7% discount rate) !! Public !! Government !! Total
|-
| Present Value || $254,756,766 || $11,533,649 || $266,290,415
|-
| Annualized Costs || $36,271,632 || $1,642,132 || $37,913,764
|}

== V. Executive Orders 12866 and 13563 ==

This is a significant regulatory action, subject to review under section 6(b) of E.O. 12866, Regulatory Planning and Review, as amended.

== VI. Executive Order 14192 ==

This rule is '''not''' subject to E.O. 14192, because it is issued with respect to a national security function of the United States. Implementation of CMMC Program requirements is urgently needed to strengthen protection of DoD information, protect critical defense technologies from exfiltration, and protect the DIB's intellectual property and the broader U.S. economy from malicious cyber actors.

== VII. Congressional Review Act ==

DoD will submit the rule to the U.S. Senate, House of Representatives, and Comptroller General as required by the Congressional Review Act (5 U.S.C. 801–808). The Office of Information and Regulatory Affairs has determined this rule is '''not''' a major rule as defined by 5 U.S.C. 804(2).

== VIII. Regulatory Flexibility Act ==

A final regulatory flexibility analysis was prepared under 5 U.S.C. 601 ''et seq.'' Key points:

* This rule responds to threats posed by malicious cyber activity targeting U.S. intellectual property and DoD CUI.
* Requirements apply to all offerors/contractors under a CMMC-requirement solicitation/contract: (1) post current CMMC status in SPRS; (2) maintain CMMC status for contract life; (3) provide CMMC UIDs to the contracting officer, with updates; (4) maintain a current affirmation of continuous compliance.
* These requirements do '''not''' apply to awards not involving FCI or CUI.
* No public comments were submitted in response to the initial regulatory flexibility analysis.

'''Estimated small entities impacted, phased rollout:'''

{| class="wikitable"
|-
! Year !! Estimated Small Entities
|-
| Year 1 || 1,104
|-
| Year 2 || 5,565
|-
| Year 3 || 18,554
|-
| Year 4+ || 229,818
|}

'''Anticipated mix of CMMC statuses starting Year 4:'''

{| class="wikitable"
|-
! CMMC Level !! Percentage !! Small Entities !! Large Entities !! Total Entities
|-
| Level 1 Self-assessment || 62% || 142,487 || 67,053 || 209,540
|-
| Level 2 Self-assessment || 2% || 4,596 || 2,163 || 6,759
|-
| Level 2 Certificate || 35% || 80,436 || 37,853 || 118,289
|-
| Level 3 Certificate || 1% || 2,298 || 1,082 || 3,380
|-
| '''Total''' || '''100%''' || '''229,818''' || '''108,150''' || '''337,968'''
|}

'''New reporting/recordkeeping requirements for small entities:'''

# Post current CMMC status (not covered by C3PAO/DIBCAC assessment) to SPRS for each applicable CMMC UID.
# Provide CMMC UIDs prior to award and upon any changes.
# Affirming official completes and maintains, annually (or upon compliance status change), the affirmation of continuous compliance in SPRS.

DoD identified no alternatives that would accomplish the statutory objectives while further reducing small-entity burden; the phased rollout and COTS exemption are intended to minimize economic impact.

== IX. Paperwork Reduction Act ==

This final rule's information collection requirements have been approved by OMB under the Paperwork Reduction Act (44 U.S.C. chapter 35), OMB Control Number '''0750–0008''', DFARS Part 204, Contractor Implementation of Cybersecurity Requirements.

== List of Subjects in 48 CFR Parts 204, 212, 217, and 252 ==

Government procurement.

''Signed:'' Kimberly R. Ziegler, Editor/Publisher, Defense Acquisition Regulations System.

The interim rule amending 48 CFR parts 204, 212, 217, and 252 (published at 85 FR 61505 on September 29, 2020) is adopted as final with the following changes.

'''Authority citation for parts 204, 212, 217, and 252:''' 41 U.S.C. 1303 and 48 CFR chapter 1.

== PART 204—Administrative and Information Matters ==

=== Subpart 204.75—Cybersecurity Maturity Model Certification ===

'''Contents:'''
* 204.7500 Scope of subpart.
* 204.7501 Definitions.
* 204.7502 Policy.
* 204.7503 Procedures.
* 204.7504 Solicitation provision and contract clause.

==== 204.7500 Scope of subpart ====

(a) This subpart prescribes policies and procedures for including the Cybersecurity Maturity Model Certification (CMMC) level requirements in DoD contracts. CMMC is a framework (see 32 CFR part 170) for assessing a contractor's information security protections.

(b) This subpart does not abrogate any other requirements regarding contractor physical, personnel, information, technical, or general administrative security operations governing the protection of unclassified information, nor does it affect requirements of the National Industrial Security Program.

(c) This subpart applies to unclassified contractor information systems.

==== 204.7501 Definitions ====

As used in this subpart—

'''Controlled unclassified information''' means information the Government creates or possesses, or information an entity creates or possesses for or on behalf of the Government, that a law, regulation, or Governmentwide policy requires or permits an agency to handle using safeguarding or dissemination controls (32 CFR 2002.4(h)).

'''Current''' means—

(1) With regard to Conditional Cybersecurity Maturity Model Certification (CMMC) Status—

:(i) Not older than 180 days for Conditional Level 2 (Self) assessments and Conditional Level 2 (certified third-party assessment organization (C3PAO)) assessments, with—
::(A) No changes in compliance with the requirements at 32 CFR part 170 since the Conditional CMMC Status date (see 32 CFR 170.16 and 170.17); and
::(B) A corresponding affirmation of continuous compliance by an affirming official (see 32 CFR 170.4); and

:(ii) Not older than 180 days for Conditional Level 3 (Defense Industrial Base Cybersecurity Assessment Center (DIBCAC)) assessments, with—
::(A) No changes in compliance with the requirements at 32 CFR part 170 since the Conditional CMMC Status date (see 32 CFR 170.18); and
::(B) A corresponding affirmation of continuous compliance by an affirming official;

(2) With regard to Final CMMC Status—

:(i) Not older than 1 year for Final Level 1 (Self), with—
::(A) No changes in compliance with the requirements at 32 CFR part 170 since the Final CMMC Status date (see 32 CFR 170.15); and
::(B) A corresponding affirmation of continuous compliance, not older than 1 year, by an affirming official;

:(ii) Not older than 3 years for Final Level 2 (Self) assessments and Final Level 2 (C3PAO) assessments, with—
::(A) No changes in compliance with the requirements at 32 CFR part 170 since the Final CMMC Status date (see 32 CFR 170.16 and 170.17); and
::(B) A corresponding affirmation of continuous compliance, not older than 1 year, by an affirming official; and

:(iii) Not older than 3 years for Final Level 3 (DIBCAC) assessments, with—
::(A) No changes in compliance with the requirements at 32 CFR part 170 since the Final CMMC Status date (see 32 CFR 170.18); and
::(B) A corresponding affirmation of continuous compliance, not older than 1 year, by an affirming official; and

(3) With regard to affirmation of continuous compliance (32 CFR 170.22), not older than 1 year with no changes in compliance with the requirements at 32 CFR part 170.

'''Cybersecurity Maturity Model Certification (CMMC) status''' means the result of meeting or exceeding the minimum required score for the corresponding assessment. The potential statuses are as follows:

# Final Level 1 (Self).
# Conditional Level 2 (Self).
# Final Level 2 (Self).
# Conditional Level 2 (C3PAO).
# Final Level 2 (C3PAO).
# Conditional Level 3 (DIBCAC).
# Final Level 3 (DIBCAC).

'''Cybersecurity Maturity Model Certification unique identifier (CMMC UID)''' means 10 alpha-numeric characters assigned to each CMMC assessment and reflected in the Supplier Performance Risk System (SPRS) for each contractor information system.

'''Federal contract information (FCI)''' means information, not intended for public release, that is provided by or generated for the Government under a contract to develop or deliver a product or service to the Government. It does not include information provided by the Government to the public, such as on public websites, or simple transactional information, such as information necessary to process payments.

==== 204.7502 Policy ====

'''(a) Award eligibility.'''

(1) The contracting officer shall include in the solicitation the required CMMC level, if provided by the program office or the requiring activity.

(2) Contracting officers shall not award a contract, task order, or delivery order to an offeror that does not have a current CMMC status at the CMMC level required by the solicitation.

(3) Contractors are required to achieve, at time of award, a CMMC status at the CMMC level specified in the solicitation, or higher, for all information systems used in the performance of the contract, task order, or delivery order that will process, store, or transmit FCI or CUI. Contractors are required to maintain a current CMMC status at the specified CMMC level or higher, if required by the contract, task order, or delivery order, throughout the life of the contract, task order, or delivery order.

'''(b) CMMC status.'''

(1) Contracting officers may award a contract, task order, delivery order, or modification to exercise an option or extend a period of performance, if the offeror's or contractor's CMMC status is—

:(i) Listed in the definition of "CMMC status"; and
:(ii) Equal to or higher than the CMMC level required by the solicitation or contract, task order, or delivery order.

(2) CMMC levels 2 and 3 can be in a conditional level for a period not to exceed 180 days from the CMMC status date (32 CFR 170.21), and award can occur with a conditional CMMC level. CMMC level 1 requires a final CMMC level for award.

==== 204.7503 Procedures ====

'''(a) CMMC level.''' The contracting officer shall include the CMMC level (see 32 CFR 170.19) required by the program office or requiring activity in the solicitation provision and contract clause prescribed at 204.7504.

'''(b) Award.''' Contracting officers shall check SPRS and not award a contract, task order, or delivery order to an offeror that does not have a current CMMC status posted in SPRS at the CMMC level (see 32 CFR 170.15 through 170.18) required by the solicitation, or higher, for each CMMC UID provided by the offeror. The CMMC UIDs are applicable to each of the contractor information systems that will process, store, or transmit FCI or CUI and that will be used in performance of the contract.

'''(c) Option exercise or period of performance extension.''' Contracting officers shall check SPRS and not exercise an option or extend the period of performance on a contract, task order, or delivery order, unless the contractor has a current CMMC status posted in SPRS at the CMMC level (see 32 CFR 170.15 through 170.18) required by the contract, task order, or delivery order, or higher, for each CMMC UID provided by the contractor. The contractor's CMMC UIDs are applicable to each of the contractor information systems that process, store, or transmit FCI or CUI and that are or will be used in performance of the contract.

'''(d) CMMC UIDs.''' If the contractor provides new CMMC UIDs during performance of the contract, task order, or delivery order, the contracting officer shall check in SPRS, using the CMMC UIDs assigned by SPRS, that the contractor has a current CMMC status at the required CMMC level, or higher, for each of the contractor information systems identified that will process, store, or transmit FCI or CUI during contract performance.

==== 204.7504 Solicitation provision and contract clause ====

(a) Unless the requirements at 32 CFR 170.5(d) are met, use the clause at 252.204–7021, ''Contractor Compliance with the Cybersecurity Maturity Model Certification Level Requirements'', as follows:

(1) '''Until November 9, 2028''', in solicitations and contracts, task orders, or delivery orders, including those using FAR part 12 procedures for the acquisition of commercial products and commercial services, except for those solely for the acquisition of commercially available off-the-shelf (COTS) items, if the program office or requiring activity determines that the contractor is required to have a specific CMMC level.

(2) '''On or after November 10, 2028''', in solicitations and contracts, task orders, or delivery orders, including those using FAR part 12 procedures for the acquisition of commercial products and commercial services, except for those solely for the acquisition of COTS items, if the program office or requiring activity determines that the contractor is required to use contractor information systems in the performance of the contract, task order, or delivery order to process, store, or transmit FCI or CUI.

(b) Use the provision at 252.204–7025, ''Notice of Cybersecurity Maturity Model Certification Level Requirements'', in solicitations that include the clause at 252.204–7021.

== PART 212—Acquisition of Commercial Products and Commercial Services ==

=== 212.301 Solicitation provisions and contract clauses for the acquisition of commercial products and commercial services ===

'''Amendment:'''
* In paragraph (f)(ii)(L), remove "204.7503 (a) and (b)" and add "204.7504(a)" in its place.
* Add paragraph (f)(ii)(P):

:(P) Use the provision at 252.204–7025, Notice of Cybersecurity Maturity Model Certification Level Requirements, as prescribed in 204.7504(b).

== PART 217—Special Contracting Methods ==

=== 217.207 Exercise of options ===

(c) In addition to the requirements at FAR 17.207(c), exercise an option only after—

(1) Determining that the contractor's record in the System for Award Management database is active and the contractor's unique entity identifier number, Commercial and Government Entity (CAGE) code, name, and physical address are accurately reflected in the contract document. (See PGI 217.207 for the requirement to perform cost or price analysis of spare parts prior to exercising any option for firm-fixed-price contracts containing spare parts.); and

(2) Working with the program office or requiring activity to verify in the Supplier Performance Risk System (https://piee.eb.mil) that—

:(i) The summary level score of a current NIST SP 800–171 DoD Assessment (i.e., not more than 3 years old, unless a lesser time is specified in the solicitation) for each covered contractor information system that is relevant to an offer, contract, task order, or delivery order are posted (see 204.7303); and

:(ii) If there is a requirement for the contractor to have a Cybersecurity Maturity Model Certification (CMMC) status at a specific CMMC level, the contractor has a current CMMC status at the CMMC level required by the contract, or higher, for each of the CMMC unique identifiers applicable to each of the contractor information systems that process, store, or transmit Federal contract information or controlled unclassified information (see 204.7503(c)).

== PART 252—Solicitation Provisions and Contract Clauses ==

=== 252.204–7021 Contractor Compliance With the Cybersecurity Maturity Model Certification Level Requirements ===

''As prescribed in 204.7504(a), use the following clause:''

'''CONTRACTOR COMPLIANCE WITH THE CYBERSECURITY MATURITY MODEL CERTIFICATION LEVEL REQUIREMENTS (NOV 2025)'''

'''(a) Definitions.''' As used in this clause—

'''Controlled unclassified information''' means information the Government creates or possesses, or information an entity creates or possesses for or on behalf of the Government, that a law, regulation, or Governmentwide policy requires or permits an agency to handle using safeguarding or dissemination controls (32 CFR 2002.4(h)).

'''Current''' means— ''(see definition under DFARS 204.7501 above, which is incorporated identically into this clause)''

'''Cybersecurity Maturity Model Certification (CMMC) status''' means the result of meeting or exceeding the minimum required score for the corresponding assessment. The potential statuses are as follows:

# Final Level 1 (Self).
# Conditional Level 2 (Self).
# Final Level 2 (Self).
# Conditional Level 2 (C3PAO).
# Final Level 2 (C3PAO).
# Conditional Level 3 (DIBCAC).
# Final Level 3 (DIBCAC).

'''Cybersecurity Maturity Model Certification unique identifier (CMMC UID)''' means 10 alpha-numeric characters assigned to each CMMC assessment and reflected in the Supplier Performance Risk System (SPRS) for each contractor information system.

'''Federal contract information (FCI)''' means information, not intended for public release, that is provided by or generated for the Government under a contract to develop or deliver a product or service to the Government. It does not include information provided by the Government to the public, such as on public websites, or simple transactional information, such as information necessary to process payments.

'''Plan of action and milestones''' means a document that identifies tasks to be accomplished. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks, and scheduled completion dates for the milestones, as defined in National Institute of Standards and Technology Special Publication 800–115 (32 CFR 170.21).

'''(b) Framework.''' The Cybersecurity Maturity Model Certification (CMMC) is a framework for assessing a contractor's compliance with applicable information security protections (see 32 CFR part 170).

'''(c) Duplication.''' The CMMC assessments will not duplicate efforts from any other comparable DoD assessment, except for rare circumstances when a reassessment may be necessary, for example, when there are indications of issues with cybersecurity and/or compliance with CMMC requirements.

'''(d) Requirements.''' The Contractor shall—

(1)(i) Have and maintain for the duration of the contract a current CMMC status at the following CMMC level, or higher: _____ [Contracting Officer insert: CMMC Level 1 (Self); CMMC Level 2 (Self); CMMC Level 2 (C3PAO); or CMMC Level 3 (DIBCAC)] for all information systems used in performance of the contract, task order, or delivery order that process, store, or transmit FCI or CUI; and

:(ii) Consult 32 CFR 170.23 related to the flowdown of the CMMC requirements, and flow down the correct CMMC level to subcontracts and other contractual instruments;

(2) Only process, store, or transmit FCI or CUI on contractor information systems that have a CMMC status at the CMMC level required in paragraph (d)(1) of this clause, or higher;

(3) Complete on an annual basis, and maintain as current, an affirmation, by the affirming official (see 32 CFR 170.4), of continuous compliance with the requirements associated with the CMMC level required in paragraph (d)(1) of this clause in the Supplier Performance Risk System (SPRS) (https://piee.eb.mil) for each CMMC UID applicable to each of the contractor information systems that process, store, or transmit FCI or CUI and that are used in performance of the contract;

(4) Ensure all subcontractors and suppliers complete prior to subcontract award, and maintain on an annual basis, an affirmation, by the affirming official (see 32 CFR 170.4), of continuous compliance with the requirements associated with the CMMC level required for the subcontract or other contractual instrument for each of the subcontractor information systems that process, store, or transmit FCI or CUI and that are used in performance of the subcontract; and

(5) If the Contractor has a CMMC Status of Conditional, successfully close out a valid plan of action and milestones (32 CFR 170.21) to achieve a CMMC Status of Final.

'''(e) Reporting.''' The Contractor shall—

(1) Submit to the Contracting Officer—

:(i) The CMMC UID(s) issued by SPRS for contractor information systems that will process, store, or transmit FCI or CUI during performance of the contract; and

:(ii) Any changes in the CMMC UIDs generated in SPRS throughout the life of the contract, task order, or delivery order, if applicable;

(2) Enter into SPRS the results of a current self-assessment for each CMMC UID, not covered by a C3PAO assessment or DIBCAC assessment, applicable to each of the contractor information systems that process, store, or transmit FCI or CUI and that are used in performance of the contract; and

(3) Complete in SPRS on an annual basis and maintain as current an affirmation of continuous compliance by the affirming official (see 32 CFR 170.4) for each self-assessment, C3PAO assessment, or DIBCAC assessment required under the contract in SPRS.

'''(f) Subcontracts.''' The Contractor shall—

(1) Insert the substance of this clause, including this paragraph (f) and excluding paragraph (e)(1), in subcontracts and other contractual instruments, including those for the acquisition of commercial products and commercial services, excluding commercially available off-the-shelf items, if the subcontract or other contractual instrument will contain a requirement to process, store, or transmit FCI or CUI; and

(2) Prior to awarding a subcontract or other contractual instrument, ensure that the subcontractor has a current CMMC certificate or current CMMC status at the CMMC level that is appropriate for the information that is being flowed down to the subcontractor based on the requirements at 32 CFR 170.23.

''(End of clause)''

=== 252.204–7025 Notice of Cybersecurity Maturity Model Certification Level Requirements ===

''As prescribed in 204.7504(b), use the following provision:''

'''NOTICE OF CYBERSECURITY MATURITY MODEL CERTIFICATION LEVEL REQUIREMENTS (NOV 2025)'''

'''(a) Definitions.''' As used in this provision, ''controlled unclassified information (CUI)'', ''current'', ''Cybersecurity Maturity Model Certification (CMMC) status'', ''Cybersecurity Maturity Model Certification unique identifier (CMMC UID)'', ''Federal contract information (FCI)'', and ''Plan of action and milestones'' have the meaning given in the Defense Federal Acquisition Regulation Supplement 252.204–7021, ''Contractor Compliance With the Cybersecurity Maturity Model Certification Level Requirements'', clause of this solicitation.

'''(b)(1) Cybersecurity Maturity Model Certification (CMMC) level.''' The CMMC level required by this solicitation is: _____ [Contracting Officer insert: CMMC Level 1 (Self); CMMC Level 2 (Self); CMMC Level 2 (C3PAO); or CMMC Level 3 (DIBCAC)]. This CMMC level, or higher (see 32 CFR part 170), is required prior to award for each contractor information system that will process, store, or transmit Federal contract information (FCI) or controlled unclassified information (CUI) during performance of the contract.

'''(2)''' The Offeror will not be eligible for award of a contract, task order, or delivery order resulting from this solicitation if the Offeror does not have, for each of the contractor information systems that will process, store, or transmit FCI or CUI and that will be used in performance of a contract resulting from this solicitation—

:(i) The current CMMC status entered in the Supplier Performance Risk System (SPRS) (https://piee.eb.mil) at the CMMC level required by paragraph (b)(1) of this provision; and

:(ii) A current affirmation of continuous compliance with the security requirements identified at 32 CFR part 170 in SPRS.

'''(c) Plan of action and milestones.''' If the Offeror has a CMMC Status of Conditional, the Offeror shall successfully close out a valid plan of action and milestones (32 CFR 170.21) to achieve a CMMC Status of Final.

'''(d) CMMC unique identifiers.''' The Offeror shall provide, in the proposal, the CMMC unique identifier(s) (CMMC UIDs) issued by SPRS for each contractor information system that will process, store, or transmit FCI or CUI during performance of a contract, task order, or delivery order resulting from this solicitation. The Offeror also shall update the list when new CMMC UIDs are generated in SPRS. The CMMC UIDs are provided in SPRS after the Offeror enters the results of self-assessment(s) for each such information system.

''(End of provision)''

----

'''[FR Doc. 2025–17359 Filed 9–9–25; 8:45 am]'''

'''BILLING CODE 6001–FR–P'''

[[Category:Federal Register]]
[[Category:DFARS]]
[[Category:Cybersecurity Maturity Model Certification]]
[[Category:Defense Acquisition Regulations]]

48 CFR Parts 204 212 217 252

2026-07-26T01:21:12Z

David:

{{DISPLAYTITLE:Defense Federal Acquisition Regulation Supplement: Assessing Contractor Implementation of Cybersecurity Requirements (DFARS Case 2019–D041)}}
'''Source of Reference: The official [https://www.federalregister.gov/documents/2025/09/10/2025-17359/defense-federal-acquisition-regulation-supplement-assessing-contractor-implementation-of Defense Federal Acquisition Regulation Supplement: Assessing Contractor Implementation of Cybersecurity Requirements (DFARS Case 2019-D041)] final rule.'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmcwiki.org contact us]. Thank you.

'''Federal Register''' / Vol. 90, No. 173 / Wednesday, September 10, 2025 / Rules and Regulations

== Agency Information ==

{| class="wikitable"
|-
! Field !! Value
|-
| Agency || Defense Acquisition Regulations System, Department of Defense (DoD)
|-
| Action || Final rule
|-
| Docket || DARS–2020–0034
|-
| RIN || 0750–AK81
|-
| Effective Date || November 10, 2025
|-
| Contact || Ms. Heather Kitchens, telephone 571–296–7152
|}

== Summary ==

DoD is issuing a final rule amending the Defense Federal Acquisition Regulation Supplement (DFARS) to incorporate contractual requirements related to the final Cybersecurity Maturity Model Certification (CMMC) program rule. This final DFARS rule also partially implements a section of the National Defense Authorization Act for Fiscal Year 2020 that directed the Secretary of Defense to develop a consistent, comprehensive framework to enhance cybersecurity for the U.S. defense industrial base.

== I. Background ==

* DoD published an interim rule in the Federal Register at 85 FR 61505 on September 29, 2020, to assess contractor implementation of cybersecurity requirements and enhance the protection of unclassified information within the DoD supply chain.
* DoD subsequently published a proposed rule at 89 FR 66327 on August 15, 2024, to implement the contractual requirements related to CMMC. Ninety-seven respondents submitted public comments in response to the proposed rule.
* Separately, a proposed rule to establish the CMMC program at 32 CFR part 170 was published at 88 FR 89058 on December 26, 2023. A final rule was published at 89 FR 83092 on October 15, 2024, and became effective on December 16, 2024.

== II. Discussion and Analysis ==

=== A. Summary of Significant Changes From the Proposed Rule ===

==== 1. Definitions ====

The final rule adds and modifies certain definitions at DFARS 204.7501, Definitions.

* The definition of "current" was changed to clarify that it is related to having no changes in compliance with the requirements at 32 CFR part 170, and to clarify what "current" means when referring to "Conditional CMMC Status," "Final CMMC Status," and "affirmation of continuous compliance."
* The term "DoD unique identifier" was updated to "CMMC unique identifier" to match the naming convention in the Supplier Performance Risk System (SPRS). The CMMC UID means ten alpha-numeric characters assigned to each contractor CMMC assessment and reflected in SPRS for each contractor information system.
* The final rule adds the definition of "Federal contract information" based on the definition from the clause at FAR 52.204–21.
* The final rule adds a definition of "plan of action and milestones" (POA&M) based on the definition codified at 32 CFR part 170.
* The final rule adds the term "CMMC status" and a definition for the term.

==== 2. Policy ====

DFARS 204.7502, Policy, includes language to add clarity by stating that for CMMC levels 2 and 3 only, a conditional CMMC status is permitted for a period not to exceed 180 days from the conditional CMMC date, in accordance with 32 CFR 170.21, and an award can occur with a CMMC conditional status. The language also clarifies that a final CMMC is achieved upon successful closeout of a valid POA&M.

==== 3. Procedures ====

* Language at DFARS 204.7503 was updated to add paragraph headings.
* Language clarifies that contracting officers are required to check SPRS and not award a contract, task order, or delivery order to an offeror that does not have a current CMMC status posted in SPRS at the CMMC level required by the solicitation, or higher, for each CMMC UID provided by the offeror.
* Paragraph (d) clarifies that all offerors are required to provide the CMMC UIDs applicable to each contractor information system that processes, stores, or transmits FCI or CUI and that will be used in performance of the contract.

==== 4. Clause Prescription ====

At DFARS 204.7504, the prescription for the contract clause has been updated to clarify the phased implementation approach:

* '''Until three years after the effective date of the rule''': the clause will be prescribed for use if program managers and requiring activities make a determination to apply a CMMC requirement to contracts, excluding awards solely for the acquisition of commercially available off-the-shelf (COTS) items (unless the requirements at 32 CFR 170.5(d) are met).
* '''Beginning three years and one day after the effective date of the rule''': the clause will be prescribed for use if program managers and requiring activities determine that the contractor will be required to use contractor information systems in the performance of the contract to process, store, or transmit FCI or CUI, excluding awards solely for the acquisition of COTS items.

==== 5. Solicitation Provision and Contract Clause ====

* The contract clause has been updated to include a fill-in for the contracting officer to identify the CMMC level required by the contract.
* The subcontract flowdown language has been updated to identify that subcontractors also must submit affirmations of continuous compliance and the results of self-assessments in SPRS.
* The clause has been updated to include the term "affirming official" in place of "senior company official" to match 32 CFR part 170.
* The solicitation provision and contract clause include the terminology needed for entering the CMMC level: '''CMMC Level 1 (Self)'''; '''CMMC Level 2 (Self)'''; '''CMMC Level 2 (C3PAO)'''; or '''CMMC Level 3 (DIBCAC)'''.
* The solicitation provision clarifies that offerors will not be eligible for award if the offeror does not have a current CMMC status entered in SPRS at the required level and a current affirmation of continuous compliance for each applicable contractor information system.

=== B. Analysis of Public Comments ===

''Note: Technical and programmatic comments on CMMC, and comments related to the CMMC cost analysis, were addressed in the CMMC program rule that codified 32 CFR part 170. This DFARS rule addresses the nontechnical and nonprogrammatic comments.''

==== 1. Clarification of "Changes" ====

'''Comment:''' Several respondents asked for more clarity regarding what "changes" means in the proposed rule.

'''Response:''' Based on public comment, the final DFARS rule adds the sentence: "Submit to the Contracting Officer . . . any changes in the CMMC UIDs generated in SPRS throughout the life of the contract, task order, or delivery order, if applicable." The notification requirement to report lapses in information security or changes in compliance with 32 CFR part 170 was removed, since the reporting requirement at DFARS 252.204–7012 paragraph (c) already provides sufficient notification of relevant information security incidents.

==== 2. Clarification of "Lapses in Information Security" ====

'''Comment:''' Several respondents asked for clarity on "lapses in information security" in proposed paragraph (b)(4) at DFARS 252.204–7021; several recommended it be removed.

'''Response:''' The requirement to notify the contracting officer of lapses in information security or changes in CMMC status has been removed from the final rule.

==== 3. Editorial Changes ====

'''Comment:''' Respondents identified typos and recommended using "and/or" instead of "or" for CMMC UIDs.

'''Response:''' Editorial comments were noted; most were mooted by other final-rule changes. The "and/or" recommendation was '''not''' implemented because it could narrow the scope of the requirement beyond what was intended.

==== 4. CMMC Level Notification and Compliance ====

'''Comment:''' Respondents asked how the required CMMC level will be communicated and determined, and requested clarity on phase-in exemptions for small businesses.

'''Response:''' The CMMC level determination is made in accordance with 32 CFR 170.19 (CMMC scoping) by the program office/requiring activity (for the prime contract) or the prime/next higher-tier subcontractor (for subcontracts). CMMC levels are: CMMC Level 1 (Self); CMMC Level 2 (Self); CMMC Level 2 (C3PAO); and CMMC Level 3 (DIBCAC) (see 32 CFR 170.14). DoD did not incorporate the recommendation to limit CMMC inclusion in existing contracts, as contracting officers already have discretion to bilaterally modify existing contracts.

==== 5. COTS Item Exclusion ====

'''Comment:''' Respondents requested clarification on the scope of the COTS exclusion.

'''Response:''' The rule does not apply to awards that are exclusively for COTS items, as defined at FAR 2.101. Any award exclusively for items meeting the FAR definition is considered an "exclusively COTS" award.

==== 6. Extending the Certification Time for New Bidders ====

'''Comment:''' A respondent requested an extension of certification time for new bidders.

'''Response:''' Per 32 CFR part 170, contractors must have a CMMC self-assessment or certification at time of award; there is no delayed implementation for new bidders, though 32 CFR 170.21 allows a POA&M in certain instances.

==== 7. Flowdown Requirements When Subcontractors Use Prime Contractor Information System ====

'''Comment:''' Respondents asked about flowdown when subcontractors use the prime's information system rather than their own.

'''Response:''' A subcontractor that does not process, store, or transmit FCI or CUI on its own systems has no CMMC assessment requirement. DoD does not have an automated tool giving primes visibility into subcontractor certification status in SPRS, but subcontractors may voluntarily share scores/certificates.

==== 8. Definitions ====

'''a. CUI'''

'''Comment:''' Respondents asked to define CUI and streamline it with "covered defense information."

'''Response:''' The definition of CUI incorporates the definition codified at 32 CFR part 170; modifying it further is outside the scope of this rule.

'''b. FCI'''

'''Comment:''' A respondent requested clarification of "not intended for public release" and "simple transactional information," and whether FOIA-subject information is still FCI.

'''Response:''' A definition of FCI was added, based on FAR 52.204–21, with "information necessary to process payments" as an example of simple transactional information. Marking/FOIA comments are outside scope.

'''c. Current'''

'''Comment:''' Clarify whether "current" refers to date of assessment or date of certification.

'''Response:''' The final rule changes the definition of "current" to address this; the underlying requirements were established in 32 CFR part 170, and DoD cannot make changes beyond that in this DFARS rule.

'''d. Data'''

'''Comment:''' Respondents asked that "data" be replaced with "FCI and/or CUI" to narrow scope.

'''Response:''' Based on public comments, the rule was revised to remove the term "data." The rule applies to information that is FCI and CUI only.

'''e. Contractor Information Systems'''

'''Comment:''' Respondents asked that "contractor information systems" be limited/defined more narrowly, similar to "covered contractor information systems."

'''Response:''' The rule clarifies that "contractor information systems" throughout the rule means systems "that process, store, or transmit FCI or CUI in performance of the contract."

==== 9. Regulatory Impact Analysis (RIA) Estimate ====

'''Comment:''' Several respondents said the RIA cost estimate was too low and should include all offerors and a revised estimate of average information systems per contractor.

'''Response:''' The RIA only covers costs of contractual requirements to upload self-assessments and complete affirmations in SPRS (technical/programmatic CMMC costs are addressed under 32 CFR part 170). The RIA was revised to expand the estimated impacted entities to include, in year four and beyond, all entities in the Federal Procurement Data System awarded DoD contracts FY2022–FY2024. The estimate of five information systems per contractor remains a DoD subject-matter-expert estimate.

==== 10. Application to Fundamental Research ====

'''Comment:''' Respondents raised concerns about applying CMMC to fundamental research that could become CUI.

'''Response:''' Fundamental research (per NSDD 189) is published and broadly shared and cannot be safeguarded as FCI or CUI; however, if it has the potential to become CUI, it would be subject to CMMC once it becomes CUI.

==== 11. Applicability ====

'''Comment:''' Respondents raised numerous applicability questions: FCI-only Level 1 self-assessment carve-outs, program manager documentation of rationale, existing vs. new contracts, micro-purchase threshold subcontracts, and scope of paragraph (b)(3).

'''Response:''' The clause will be included in solicitations issued on/after the effective date and in resulting contracts; contracting officers may also bilaterally incorporate the clause into existing contracts (see FAR 1.108(d)). Until three years after the effective date, CMMC applies only where program managers/requiring activities determine to apply it (excluding COTS-only awards); afterward, it applies wherever contractor information systems will process, store, or transmit FCI or CUI. 32 CFR part 170 does not allow spot checks and requires the CMMC requirement be met at time of award.

==== 12. Flowdown ====

'''Comment:''' Respondents requested clarification on flowdown scope, CUI dissemination limits, and lower-tier CMMC level determination.

'''Response:''' See 32 CFR 170.23 for flowdown guidance. Clause paragraph (d)(1) was revised to clarify flowdown applies only where the subcontract requires a CMMC level, and to no longer exclude paragraph (b)(3) (affirmation of continuous compliance) from subcontractor flowdown. The rule was '''not''' revised regarding which subcontractors must receive CUI — that determination remains with the prime contractor.

==== 13. CMMC as an Evaluation Factor ====

'''Comment:''' Is CMMC a competition evaluation factor or set-aside requirement?

'''Response:''' No. CMMC is not an evaluation factor or set-aside requirement; DFARS 204.7503 requires contracting officers not to award to an offeror that fails to meet the CMMC requirements in the solicitation, and if included in the solicitation, it becomes a contract requirement.

==== 14. Program Office Requirements ====

'''Comment:''' Require the program office to review contractor-provided information.

'''Response:''' The rule was revised to require the contracting officer to work with the program office/requiring activity to review the offeror's CMMC status and affirmation information.

==== 15. Clarifying When FCI Applies ====

'''Comment:''' Clarify that systems processing FCI (not CUI) need only CMMC Level 1.

'''Response:''' Not included in the final rule; contracting officers do not determine the required CMMC level.

==== 16. International Applicability ====

'''Comment:''' Respondents raised questions about C3PAO assessments outside the U.S., international harmonization, and foreign verification bodies (e.g., Taiwan's TAF).

'''Response:''' Contracts subject to NIST SP 800–171 compliance (e.g., via DFARS 252.204–7012) require foreign or domestic contractors to secure their systems. See 32 CFR 179 regarding foreign C3PAO accreditation; DoD permits an equivalent process for personnel ineligible for a Tier 3 background investigation, for CMMC Program purposes only.

==== 17. POA&M ====

'''Comment:''' Respondents sought clarity on POA&M closeout, conditional certification for subcontract award, and continued reliance on POA&Ms for newly discovered risks.

'''Response:''' The rule was revised to clarify (via the "current" definition) that for CMMC Levels 2 and 3 only, conditional CMMC status is permitted for up to 180 days from the conditional CMMC status date, and that final CMMC status is achieved upon successful POA&M closeout. 32 CFR part 170 does not allow additional POA&Ms beyond established scoping, other than for scenarios appropriate for an "operational plan of action" (32 CFR 170.4).

==== 18. Subcontractor Compliance ====

'''Comment:''' Respondents asked how primes monitor/verify subcontractor CMMC adherence, requested an automated SPRS visibility tool, and asked when subcontractors must be compliant.

'''Response:''' Contractors can only access their own CMMC information in SPRS; DoD has no tool for automatic sharing with primes. Subcontractors may screenshot/print their own SPRS status to share voluntarily. Prior to awarding a subcontract, the prime must ensure the subcontractor has a current CMMC status at the appropriate level. 32 CFR part 170 does not allow limiting enforcement to direct suppliers only.

==== 19. Senior Company Official ====

'''Comment:''' Respondents noted the proposed rule's "senior company official" term does not match 32 CFR part 170's "affirming official," and asked for a clear definition.

'''Response:''' The final rule updates terminology to "affirming official" to align with 32 CFR part 170 (the proposed DFARS rule used the older term due to timing of the two rulemakings).

==== 20. Task Orders and Delivery Orders ====

'''Comment:''' Will existing IDIQ contracts' task/delivery orders issued after the rule contain a CMMC requirement?

'''Response:''' Task orders or delivery orders issued after the rule's effective date may include a CMMC requirement under the prescribed clause/provision.

==== 21. Relationship Between "Covered Contractor Information Systems" and "Contractor Information Systems" ====

'''Comment:''' Clarify the relationship between the two terms and possible over-broad scope.

'''Response:''' The rule clarifies that "contractor information systems" are limited to those "that process, store, or transmit FCI or CUI during performance of the contract."

==== 22. CMMC Unique Identifiers ====

'''Comment:''' Respondents sought clarification on CMMC UIDs vs. CAGE codes, mandatory vs. optional UID submission, and prime vs. subcontractor UID reporting obligations.

'''Response:''' A CMMC UID is assigned per CMMC Assessment Scope as defined by the Organization Seeking Assessment (OSA) (see 32 CFR 170.19). SPRS/eMASS assigns the UID upon submission of assessment results. OSAs must obtain a CAGE code (via sam.gov) or NCAGE code (for non-U.S. businesses, via NSPA) and a PIEE account. Only prime contractors with a CMMC requirement must submit CMMC UIDs to the contracting officer (which may include subcontractors' UIDs); subcontractors themselves do not submit UIDs to the contracting officer. A new UID is generated whenever a new SPRS score is entered (e.g., at reassessment or 3-year renewal).

==== 23. Creation of Exception ====

'''Comment:''' Requests for exceptional-circumstance relief and small-business exemptions for second-tier suppliers.

'''Response:''' 32 CFR part 170 does not include an exemption for exceptional circumstances, and this DFARS rule cannot create one. DoD does not require flowdown to subcontractors that do not receive FCI or CUI.

==== 24. Period of Performance ====

'''Comment:''' Should contracting officers validate CMMC compliance before extending a period of performance?

'''Response:''' Yes — 32 CFR part 170 requires CMMC statuses to be maintained for the life of the contract, so contracting officers must validate compliance before extending performance periods or exercising options.

==== 25. Prime Contractor Protection From Subcontractor Noncompliance ====

'''Comment:''' Clarify that primes won't be rendered ineligible due to subcontractor noncompliance.

'''Response:''' The Government does not establish the prime/subcontractor relationship and does not indemnify the prime from its subcontractors, as it lacks privity of contract with subcontractors.

==== 26. Application of CMMC to FAR Part 16 Contract Types ====

'''Comment:''' Require CMMC Program Office/USD(A&S) approval before applying CMMC to FAR part 16 contract types during phase-in.

'''Response:''' 32 CFR part 170 does not include such an approval process, and this rule cannot create one.

==== 27. Acquiring Entities Without CMMC Certification ====

'''Comment:''' How are newly acquired entities or new sites added to an existing certification?

'''Response:''' Per DFARS 252.204–7021(c)(1), contractors must report changes to UIDs to the contracting officer. Adding new users to an existing system does not necessarily change the CMMC assessment scope (see 32 CFR 170.19).

==== 28. Applicability to Civilian Agencies ====

'''Comment:''' Does CMMC apply to CUI from non-DoD agencies?

'''Response:''' This rule amends the DFARS and applies only to DoD or DoD-funded acquisitions.

==== 29. Provision and Clause Clarifications ====

'''Comment:''' Questions on subcontractor UID updates and the "unless electronically posted" language.

'''Response:''' The clause was updated to require subcontractors to enter self-assessment results in SPRS and complete annual affirmations, which they may share via screenshot. "Unless electronically posted" language was removed. Paragraph (c)(1) is excluded from subcontractor flowdown because the Government lacks privity of contract with subcontractors, though primes are encouraged to flow down similar language voluntarily.

==== 30. Outside the Scope of the Rule ====

DoD received numerous comments outside the scope of this rule, including topics related to: the DFARS Case 2022–D017 timeline; CUI marking and definitions; the CMMC Program's underlying policy at 32 CFR part 170 (permissible changes, exemptions for MWR/NAF procurements, ISO/IEC 27001 relationship, phase-in timeline, spot checks, FedRAMP, waivers, eMASS training, and more); cost impacts; and various sector-specific applicability questions (medical devices, furniture manufacturers, common carriers, etc.).

'''Response (selected points):'''
* CMMC level selection is made by the program office/requiring activity per DoD policy and 32 CFR 170.5; contracting officers do not determine the level.
* All CUI categories require at least a self-assessment; DoD Organizational Index group CUI categories generally require a C3PAO assessment at minimum.
* MWR/NAF procurements requiring NIST SP 800–171 implementation are subject to the CMMC requirement.
* Waivers are established at 32 CFR 170.5 and are at the discretion of the program office/requiring activity, prior to contracting officer involvement.
* Contractors do not have access to CMMC eMASS (used only for certification assessments); all CMMC assessments are reflected in SPRS.
* Enclave scoping is determined by the contractor per 32 CFR 170.19.
* Reassessments are expected to be infrequent and DoD-conducted, per updates to 32 CFR part 170.
* Flowdown requirements are at 32 CFR 170.23.

=== C. Other Changes ===

* DFARS 204.7500 was updated to remove a web address and replace it with a reference to 32 CFR part 170.
* Clarified throughout that a higher CMMC level than required is also permissible.
* The term "CMMC status" was added throughout, clarifying that contracts may be awarded with a current Final Level 1 (Self), Conditional Level 2 (Self), Final Level 2 (Self), Conditional Level 2 (C3PAO), or Final Level 2 (C3PAO) CMMC status. A definition of "CMMC status" was added to DFARS subpart 204.75, clause 252.204–7021, and provision 252.204–7025.

== III. Applicability to Contracts at or Below the SAT, Commercial Products, and Commercial Services ==

The clause at DFARS 252.204–7021 is prescribed at DFARS 204.7504 for use:

* '''Until November 9, 2028''' (three years after the effective date): in solicitations and contracts, task orders, or delivery orders — including FAR part 12 commercial product/service acquisitions, except those solely for COTS items — if the program office or requiring activity determines the contractor is required to have a specific CMMC level (unless 32 CFR 170.5(d) requirements are met).
* '''On or after November 10, 2028''': in solicitations and contracts, task orders, or delivery orders — including FAR part 12 acquisitions, except those solely for COTS items — if the program office or requiring activity determines the contractor must use contractor information systems to process, store, or transmit FCI or CUI.

The provision at DFARS 252.204–7025 is prescribed at DFARS 204.7504(b) for use in solicitations that include the clause at DFARS 252.204–7021.

Consistent with DoD's analysis of section 1648 of the NDAA for FY 2020, DoD applies the statute (as implemented in these clause/provision) to contracts at or below the Simplified Acquisition Threshold (SAT), to commercial products (excluding COTS items), and to commercial services as defined at FAR 2.101.

== IV. Expected Impact of the Rule ==

=== A. Background ===

DoD is amending the DFARS to implement contractual requirements tied to the CMMC policy (32 CFR part 170, 89 FR 83092, October 15, 2024). New solicitation/contractual requirements include:

* Offeror/contractor requirement to post CMMC Level 1 or Level 2 self-assessment results to SPRS prior to award, option exercise, or period-of-performance extension, if not already posted.
* Contractor requirement to maintain the required CMMC status for the life of the contract.
* Contractor requirement for an affirming official to complete an annual affirmation of continuous compliance in SPRS for each applicable CMMC UID.
* Offeror/contractor requirement to identify contractor information systems used to process, store, or transmit FCI or CUI, by providing CMMC UIDs generated by SPRS.

=== B. Summary of Impact ===

The rule will be implemented over a phased, three-year period, after which it applies to all contracts where the contractor processes, stores, or transmits FCI or CUI on contractor information systems (except COTS-only contracts).

'''Estimated impacted entities (Year 4 and beyond):'''

{| class="wikitable"
|-
! Metric !! Value
|-
| Average unique entities awarded DoD contracts above micro-purchase threshold (FY2022–FY2024) || 32,756
|-
| Unique entities awarded using only commercial procedures || 18,370
|-
| Estimated COTS-only awardees (25% of 18,370) || 4,592
|-
| Unique entities after removing COTS-only awardees || 28,164
|-
| Assumed offerors per solicitation || 2
|-
| Total prime offerors (28,164 × 2) || 56,328
|-
| Assumed subcontractors per prime offer || 5
|-
| '''Total estimated impacted entities''' (primes + subcontractors) || '''337,968'''
|-
| Of which, small entities (68%) || 229,818
|}

'''Estimated time burden per contractor information system:'''

* Offerors/contractors: ~5 minutes to post CMMC self-assessment results in SPRS; ~5 minutes to complete the required affirmation; ~5 minutes to retrieve and submit CMMC UIDs.
* Government: ~5 minutes to validate CMMC level/currency prior to award, option exercise, or performance extension; ~5 minutes to validate affirmation currency; ~5 minutes to validate CMMC status/affirmation when UIDs change during performance.

'''Benefits:''' Verification of DIB contractors' implementation of system security requirements, protection of CUI/FCI and intellectual property, and reduced exposure to malicious cyber activity. The Council of Economic Advisers estimated malicious cyber activity cost the U.S. economy $57–109 billion in 2016 (a 10-year burden of an estimated $400–765 billion at a 7% discount rate, or $486–929 billion at a 3% discount rate). GAO cited Treasury reporting that ransomware-related incidents reached $886 million in 2021.

'''Estimated public and Government costs over a 10-year period:'''

{| class="wikitable"
|-
! Summary (3% discount rate) !! Public !! Government !! Total
|-
| Present Value || $329,097,922 || $15,812,069 || $344,909,991
|-
| Annualized Costs || $38,580,316 || $1,760,303 || $40,340,619
|}

{| class="wikitable"
|-
! Summary (7% discount rate) !! Public !! Government !! Total
|-
| Present Value || $254,756,766 || $11,533,649 || $266,290,415
|-
| Annualized Costs || $36,271,632 || $1,642,132 || $37,913,764
|}

== V. Executive Orders 12866 and 13563 ==

This is a significant regulatory action, subject to review under section 6(b) of E.O. 12866, Regulatory Planning and Review, as amended.

== VI. Executive Order 14192 ==

This rule is '''not''' subject to E.O. 14192, because it is issued with respect to a national security function of the United States. Implementation of CMMC Program requirements is urgently needed to strengthen protection of DoD information, protect critical defense technologies from exfiltration, and protect the DIB's intellectual property and the broader U.S. economy from malicious cyber actors.

== VII. Congressional Review Act ==

DoD will submit the rule to the U.S. Senate, House of Representatives, and Comptroller General as required by the Congressional Review Act (5 U.S.C. 801–808). The Office of Information and Regulatory Affairs has determined this rule is '''not''' a major rule as defined by 5 U.S.C. 804(2).

== VIII. Regulatory Flexibility Act ==

A final regulatory flexibility analysis was prepared under 5 U.S.C. 601 ''et seq.'' Key points:

* This rule responds to threats posed by malicious cyber activity targeting U.S. intellectual property and DoD CUI.
* Requirements apply to all offerors/contractors under a CMMC-requirement solicitation/contract: (1) post current CMMC status in SPRS; (2) maintain CMMC status for contract life; (3) provide CMMC UIDs to the contracting officer, with updates; (4) maintain a current affirmation of continuous compliance.
* These requirements do '''not''' apply to awards not involving FCI or CUI.
* No public comments were submitted in response to the initial regulatory flexibility analysis.

'''Estimated small entities impacted, phased rollout:'''

{| class="wikitable"
|-
! Year !! Estimated Small Entities
|-
| Year 1 || 1,104
|-
| Year 2 || 5,565
|-
| Year 3 || 18,554
|-
| Year 4+ || 229,818
|}

'''Anticipated mix of CMMC statuses starting Year 4:'''

{| class="wikitable"
|-
! CMMC Level !! Percentage !! Small Entities !! Large Entities !! Total Entities
|-
| Level 1 Self-assessment || 62% || 142,487 || 67,053 || 209,540
|-
| Level 2 Self-assessment || 2% || 4,596 || 2,163 || 6,759
|-
| Level 2 Certificate || 35% || 80,436 || 37,853 || 118,289
|-
| Level 3 Certificate || 1% || 2,298 || 1,082 || 3,380
|-
| '''Total''' || '''100%''' || '''229,818''' || '''108,150''' || '''337,968'''
|}

'''New reporting/recordkeeping requirements for small entities:'''

# Post current CMMC status (not covered by C3PAO/DIBCAC assessment) to SPRS for each applicable CMMC UID.
# Provide CMMC UIDs prior to award and upon any changes.
# Affirming official completes and maintains, annually (or upon compliance status change), the affirmation of continuous compliance in SPRS.

DoD identified no alternatives that would accomplish the statutory objectives while further reducing small-entity burden; the phased rollout and COTS exemption are intended to minimize economic impact.

== IX. Paperwork Reduction Act ==

This final rule's information collection requirements have been approved by OMB under the Paperwork Reduction Act (44 U.S.C. chapter 35), OMB Control Number '''0750–0008''', DFARS Part 204, Contractor Implementation of Cybersecurity Requirements.

== List of Subjects in 48 CFR Parts 204, 212, 217, and 252 ==

Government procurement.

''Signed:'' Kimberly R. Ziegler, Editor/Publisher, Defense Acquisition Regulations System.

The interim rule amending 48 CFR parts 204, 212, 217, and 252 (published at 85 FR 61505 on September 29, 2020) is adopted as final with the following changes.

'''Authority citation for parts 204, 212, 217, and 252:''' 41 U.S.C. 1303 and 48 CFR chapter 1.

== PART 204—Administrative and Information Matters ==

=== Subpart 204.75—Cybersecurity Maturity Model Certification ===

'''Contents:'''
* 204.7500 Scope of subpart.
* 204.7501 Definitions.
* 204.7502 Policy.
* 204.7503 Procedures.
* 204.7504 Solicitation provision and contract clause.

==== 204.7500 Scope of subpart ====

(a) This subpart prescribes policies and procedures for including the Cybersecurity Maturity Model Certification (CMMC) level requirements in DoD contracts. CMMC is a framework (see 32 CFR part 170) for assessing a contractor's information security protections.

(b) This subpart does not abrogate any other requirements regarding contractor physical, personnel, information, technical, or general administrative security operations governing the protection of unclassified information, nor does it affect requirements of the National Industrial Security Program.

(c) This subpart applies to unclassified contractor information systems.

==== 204.7501 Definitions ====

As used in this subpart—

'''Controlled unclassified information''' means information the Government creates or possesses, or information an entity creates or possesses for or on behalf of the Government, that a law, regulation, or Governmentwide policy requires or permits an agency to handle using safeguarding or dissemination controls (32 CFR 2002.4(h)).

'''Current''' means—

(1) With regard to Conditional Cybersecurity Maturity Model Certification (CMMC) Status—

:(i) Not older than 180 days for Conditional Level 2 (Self) assessments and Conditional Level 2 (certified third-party assessment organization (C3PAO)) assessments, with—
::(A) No changes in compliance with the requirements at 32 CFR part 170 since the Conditional CMMC Status date (see 32 CFR 170.16 and 170.17); and
::(B) A corresponding affirmation of continuous compliance by an affirming official (see 32 CFR 170.4); and

:(ii) Not older than 180 days for Conditional Level 3 (Defense Industrial Base Cybersecurity Assessment Center (DIBCAC)) assessments, with—
::(A) No changes in compliance with the requirements at 32 CFR part 170 since the Conditional CMMC Status date (see 32 CFR 170.18); and
::(B) A corresponding affirmation of continuous compliance by an affirming official;

(2) With regard to Final CMMC Status—

:(i) Not older than 1 year for Final Level 1 (Self), with—
::(A) No changes in compliance with the requirements at 32 CFR part 170 since the Final CMMC Status date (see 32 CFR 170.15); and
::(B) A corresponding affirmation of continuous compliance, not older than 1 year, by an affirming official;

:(ii) Not older than 3 years for Final Level 2 (Self) assessments and Final Level 2 (C3PAO) assessments, with—
::(A) No changes in compliance with the requirements at 32 CFR part 170 since the Final CMMC Status date (see 32 CFR 170.16 and 170.17); and
::(B) A corresponding affirmation of continuous compliance, not older than 1 year, by an affirming official; and

:(iii) Not older than 3 years for Final Level 3 (DIBCAC) assessments, with—
::(A) No changes in compliance with the requirements at 32 CFR part 170 since the Final CMMC Status date (see 32 CFR 170.18); and
::(B) A corresponding affirmation of continuous compliance, not older than 1 year, by an affirming official; and

(3) With regard to affirmation of continuous compliance (32 CFR 170.22), not older than 1 year with no changes in compliance with the requirements at 32 CFR part 170.

'''Cybersecurity Maturity Model Certification (CMMC) status''' means the result of meeting or exceeding the minimum required score for the corresponding assessment. The potential statuses are as follows:

# Final Level 1 (Self).
# Conditional Level 2 (Self).
# Final Level 2 (Self).
# Conditional Level 2 (C3PAO).
# Final Level 2 (C3PAO).
# Conditional Level 3 (DIBCAC).
# Final Level 3 (DIBCAC).

'''Cybersecurity Maturity Model Certification unique identifier (CMMC UID)''' means 10 alpha-numeric characters assigned to each CMMC assessment and reflected in the Supplier Performance Risk System (SPRS) for each contractor information system.

'''Federal contract information (FCI)''' means information, not intended for public release, that is provided by or generated for the Government under a contract to develop or deliver a product or service to the Government. It does not include information provided by the Government to the public, such as on public websites, or simple transactional information, such as information necessary to process payments.

==== 204.7502 Policy ====

'''(a) Award eligibility.'''

(1) The contracting officer shall include in the solicitation the required CMMC level, if provided by the program office or the requiring activity.

(2) Contracting officers shall not award a contract, task order, or delivery order to an offeror that does not have a current CMMC status at the CMMC level required by the solicitation.

(3) Contractors are required to achieve, at time of award, a CMMC status at the CMMC level specified in the solicitation, or higher, for all information systems used in the performance of the contract, task order, or delivery order that will process, store, or transmit FCI or CUI. Contractors are required to maintain a current CMMC status at the specified CMMC level or higher, if required by the contract, task order, or delivery order, throughout the life of the contract, task order, or delivery order.

'''(b) CMMC status.'''

(1) Contracting officers may award a contract, task order, delivery order, or modification to exercise an option or extend a period of performance, if the offeror's or contractor's CMMC status is—

:(i) Listed in the definition of "CMMC status"; and
:(ii) Equal to or higher than the CMMC level required by the solicitation or contract, task order, or delivery order.

(2) CMMC levels 2 and 3 can be in a conditional level for a period not to exceed 180 days from the CMMC status date (32 CFR 170.21), and award can occur with a conditional CMMC level. CMMC level 1 requires a final CMMC level for award.

==== 204.7503 Procedures ====

'''(a) CMMC level.''' The contracting officer shall include the CMMC level (see 32 CFR 170.19) required by the program office or requiring activity in the solicitation provision and contract clause prescribed at 204.7504.

'''(b) Award.''' Contracting officers shall check SPRS and not award a contract, task order, or delivery order to an offeror that does not have a current CMMC status posted in SPRS at the CMMC level (see 32 CFR 170.15 through 170.18) required by the solicitation, or higher, for each CMMC UID provided by the offeror. The CMMC UIDs are applicable to each of the contractor information systems that will process, store, or transmit FCI or CUI and that will be used in performance of the contract.

'''(c) Option exercise or period of performance extension.''' Contracting officers shall check SPRS and not exercise an option or extend the period of performance on a contract, task order, or delivery order, unless the contractor has a current CMMC status posted in SPRS at the CMMC level (see 32 CFR 170.15 through 170.18) required by the contract, task order, or delivery order, or higher, for each CMMC UID provided by the contractor. The contractor's CMMC UIDs are applicable to each of the contractor information systems that process, store, or transmit FCI or CUI and that are or will be used in performance of the contract.

'''(d) CMMC UIDs.''' If the contractor provides new CMMC UIDs during performance of the contract, task order, or delivery order, the contracting officer shall check in SPRS, using the CMMC UIDs assigned by SPRS, that the contractor has a current CMMC status at the required CMMC level, or higher, for each of the contractor information systems identified that will process, store, or transmit FCI or CUI during contract performance.

==== 204.7504 Solicitation provision and contract clause ====

(a) Unless the requirements at 32 CFR 170.5(d) are met, use the clause at 252.204–7021, ''Contractor Compliance with the Cybersecurity Maturity Model Certification Level Requirements'', as follows:

(1) '''Until November 9, 2028''', in solicitations and contracts, task orders, or delivery orders, including those using FAR part 12 procedures for the acquisition of commercial products and commercial services, except for those solely for the acquisition of commercially available off-the-shelf (COTS) items, if the program office or requiring activity determines that the contractor is required to have a specific CMMC level.

(2) '''On or after November 10, 2028''', in solicitations and contracts, task orders, or delivery orders, including those using FAR part 12 procedures for the acquisition of commercial products and commercial services, except for those solely for the acquisition of COTS items, if the program office or requiring activity determines that the contractor is required to use contractor information systems in the performance of the contract, task order, or delivery order to process, store, or transmit FCI or CUI.

(b) Use the provision at 252.204–7025, ''Notice of Cybersecurity Maturity Model Certification Level Requirements'', in solicitations that include the clause at 252.204–7021.

== PART 212—Acquisition of Commercial Products and Commercial Services ==

=== 212.301 Solicitation provisions and contract clauses for the acquisition of commercial products and commercial services ===

'''Amendment:'''
* In paragraph (f)(ii)(L), remove "204.7503 (a) and (b)" and add "204.7504(a)" in its place.
* Add paragraph (f)(ii)(P):

:(P) Use the provision at 252.204–7025, Notice of Cybersecurity Maturity Model Certification Level Requirements, as prescribed in 204.7504(b).

== PART 217—Special Contracting Methods ==

=== 217.207 Exercise of options ===

(c) In addition to the requirements at FAR 17.207(c), exercise an option only after—

(1) Determining that the contractor's record in the System for Award Management database is active and the contractor's unique entity identifier number, Commercial and Government Entity (CAGE) code, name, and physical address are accurately reflected in the contract document. (See PGI 217.207 for the requirement to perform cost or price analysis of spare parts prior to exercising any option for firm-fixed-price contracts containing spare parts.); and

(2) Working with the program office or requiring activity to verify in the Supplier Performance Risk System (https://piee.eb.mil) that—

:(i) The summary level score of a current NIST SP 800–171 DoD Assessment (i.e., not more than 3 years old, unless a lesser time is specified in the solicitation) for each covered contractor information system that is relevant to an offer, contract, task order, or delivery order are posted (see 204.7303); and

:(ii) If there is a requirement for the contractor to have a Cybersecurity Maturity Model Certification (CMMC) status at a specific CMMC level, the contractor has a current CMMC status at the CMMC level required by the contract, or higher, for each of the CMMC unique identifiers applicable to each of the contractor information systems that process, store, or transmit Federal contract information or controlled unclassified information (see 204.7503(c)).

== PART 252—Solicitation Provisions and Contract Clauses ==

=== 252.204–7021 Contractor Compliance With the Cybersecurity Maturity Model Certification Level Requirements ===

''As prescribed in 204.7504(a), use the following clause:''

'''CONTRACTOR COMPLIANCE WITH THE CYBERSECURITY MATURITY MODEL CERTIFICATION LEVEL REQUIREMENTS (NOV 2025)'''

'''(a) Definitions.''' As used in this clause—

'''Controlled unclassified information''' means information the Government creates or possesses, or information an entity creates or possesses for or on behalf of the Government, that a law, regulation, or Governmentwide policy requires or permits an agency to handle using safeguarding or dissemination controls (32 CFR 2002.4(h)).

'''Current''' means— ''(see definition under DFARS 204.7501 above, which is incorporated identically into this clause)''

'''Cybersecurity Maturity Model Certification (CMMC) status''' means the result of meeting or exceeding the minimum required score for the corresponding assessment. The potential statuses are as follows:

# Final Level 1 (Self).
# Conditional Level 2 (Self).
# Final Level 2 (Self).
# Conditional Level 2 (C3PAO).
# Final Level 2 (C3PAO).
# Conditional Level 3 (DIBCAC).
# Final Level 3 (DIBCAC).

'''Cybersecurity Maturity Model Certification unique identifier (CMMC UID)''' means 10 alpha-numeric characters assigned to each CMMC assessment and reflected in the Supplier Performance Risk System (SPRS) for each contractor information system.

'''Federal contract information (FCI)''' means information, not intended for public release, that is provided by or generated for the Government under a contract to develop or deliver a product or service to the Government. It does not include information provided by the Government to the public, such as on public websites, or simple transactional information, such as information necessary to process payments.

'''Plan of action and milestones''' means a document that identifies tasks to be accomplished. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks, and scheduled completion dates for the milestones, as defined in National Institute of Standards and Technology Special Publication 800–115 (32 CFR 170.21).

'''(b) Framework.''' The Cybersecurity Maturity Model Certification (CMMC) is a framework for assessing a contractor's compliance with applicable information security protections (see 32 CFR part 170).

'''(c) Duplication.''' The CMMC assessments will not duplicate efforts from any other comparable DoD assessment, except for rare circumstances when a reassessment may be necessary, for example, when there are indications of issues with cybersecurity and/or compliance with CMMC requirements.

'''(d) Requirements.''' The Contractor shall—

(1)(i) Have and maintain for the duration of the contract a current CMMC status at the following CMMC level, or higher: _____ [Contracting Officer insert: CMMC Level 1 (Self); CMMC Level 2 (Self); CMMC Level 2 (C3PAO); or CMMC Level 3 (DIBCAC)] for all information systems used in performance of the contract, task order, or delivery order that process, store, or transmit FCI or CUI; and

:(ii) Consult 32 CFR 170.23 related to the flowdown of the CMMC requirements, and flow down the correct CMMC level to subcontracts and other contractual instruments;

(2) Only process, store, or transmit FCI or CUI on contractor information systems that have a CMMC status at the CMMC level required in paragraph (d)(1) of this clause, or higher;

(3) Complete on an annual basis, and maintain as current, an affirmation, by the affirming official (see 32 CFR 170.4), of continuous compliance with the requirements associated with the CMMC level required in paragraph (d)(1) of this clause in the Supplier Performance Risk System (SPRS) (https://piee.eb.mil) for each CMMC UID applicable to each of the contractor information systems that process, store, or transmit FCI or CUI and that are used in performance of the contract;

(4) Ensure all subcontractors and suppliers complete prior to subcontract award, and maintain on an annual basis, an affirmation, by the affirming official (see 32 CFR 170.4), of continuous compliance with the requirements associated with the CMMC level required for the subcontract or other contractual instrument for each of the subcontractor information systems that process, store, or transmit FCI or CUI and that are used in performance of the subcontract; and

(5) If the Contractor has a CMMC Status of Conditional, successfully close out a valid plan of action and milestones (32 CFR 170.21) to achieve a CMMC Status of Final.

'''(e) Reporting.''' The Contractor shall—

(1) Submit to the Contracting Officer—

:(i) The CMMC UID(s) issued by SPRS for contractor information systems that will process, store, or transmit FCI or CUI during performance of the contract; and

:(ii) Any changes in the CMMC UIDs generated in SPRS throughout the life of the contract, task order, or delivery order, if applicable;

(2) Enter into SPRS the results of a current self-assessment for each CMMC UID, not covered by a C3PAO assessment or DIBCAC assessment, applicable to each of the contractor information systems that process, store, or transmit FCI or CUI and that are used in performance of the contract; and

(3) Complete in SPRS on an annual basis and maintain as current an affirmation of continuous compliance by the affirming official (see 32 CFR 170.4) for each self-assessment, C3PAO assessment, or DIBCAC assessment required under the contract in SPRS.

'''(f) Subcontracts.''' The Contractor shall—

(1) Insert the substance of this clause, including this paragraph (f) and excluding paragraph (e)(1), in subcontracts and other contractual instruments, including those for the acquisition of commercial products and commercial services, excluding commercially available off-the-shelf items, if the subcontract or other contractual instrument will contain a requirement to process, store, or transmit FCI or CUI; and

(2) Prior to awarding a subcontract or other contractual instrument, ensure that the subcontractor has a current CMMC certificate or current CMMC status at the CMMC level that is appropriate for the information that is being flowed down to the subcontractor based on the requirements at 32 CFR 170.23.

''(End of clause)''

=== 252.204–7025 Notice of Cybersecurity Maturity Model Certification Level Requirements ===

''As prescribed in 204.7504(b), use the following provision:''

'''NOTICE OF CYBERSECURITY MATURITY MODEL CERTIFICATION LEVEL REQUIREMENTS (NOV 2025)'''

'''(a) Definitions.''' As used in this provision, ''controlled unclassified information (CUI)'', ''current'', ''Cybersecurity Maturity Model Certification (CMMC) status'', ''Cybersecurity Maturity Model Certification unique identifier (CMMC UID)'', ''Federal contract information (FCI)'', and ''Plan of action and milestones'' have the meaning given in the Defense Federal Acquisition Regulation Supplement 252.204–7021, ''Contractor Compliance With the Cybersecurity Maturity Model Certification Level Requirements'', clause of this solicitation.

'''(b)(1) Cybersecurity Maturity Model Certification (CMMC) level.''' The CMMC level required by this solicitation is: _____ [Contracting Officer insert: CMMC Level 1 (Self); CMMC Level 2 (Self); CMMC Level 2 (C3PAO); or CMMC Level 3 (DIBCAC)]. This CMMC level, or higher (see 32 CFR part 170), is required prior to award for each contractor information system that will process, store, or transmit Federal contract information (FCI) or controlled unclassified information (CUI) during performance of the contract.

'''(2)''' The Offeror will not be eligible for award of a contract, task order, or delivery order resulting from this solicitation if the Offeror does not have, for each of the contractor information systems that will process, store, or transmit FCI or CUI and that will be used in performance of a contract resulting from this solicitation—

:(i) The current CMMC status entered in the Supplier Performance Risk System (SPRS) (https://piee.eb.mil) at the CMMC level required by paragraph (b)(1) of this provision; and

:(ii) A current affirmation of continuous compliance with the security requirements identified at 32 CFR part 170 in SPRS.

'''(c) Plan of action and milestones.''' If the Offeror has a CMMC Status of Conditional, the Offeror shall successfully close out a valid plan of action and milestones (32 CFR 170.21) to achieve a CMMC Status of Final.

'''(d) CMMC unique identifiers.''' The Offeror shall provide, in the proposal, the CMMC unique identifier(s) (CMMC UIDs) issued by SPRS for each contractor information system that will process, store, or transmit FCI or CUI during performance of a contract, task order, or delivery order resulting from this solicitation. The Offeror also shall update the list when new CMMC UIDs are generated in SPRS. The CMMC UIDs are provided in SPRS after the Offeror enters the results of self-assessment(s) for each such information system.

''(End of provision)''

----

'''[FR Doc. 2025–17359 Filed 9–9–25; 8:45 am]'''

'''BILLING CODE 6001–FR–P'''

[[Category:Federal Register]]
[[Category:DFARS]]
[[Category:Cybersecurity Maturity Model Certification]]
[[Category:Defense Acquisition Regulations]]

MediaWiki:Sidebar

2026-07-20T01:54:50Z

David:

Evidence Collection Approach

2026-07-20T01:49:51Z

David: /* SC.L2-3.13.12 – Collaborative Device Control */

CMMC assessments and certification require substantial evidence and documentation. The following tables outline general guidelines for collecting evidence to assess control requirements and objectives. While these guidelines provide a structured approach, they are not the only means of conducting an accurate assessment. Assessors should exercise professional judgment and may employ alternative methods appropriate to the specific organizational context and circumstances.

Evidence collection approaches are defined as:
* '''Documentation''': Tangible materials containing information over which an organization has authority, including all types of written records and their copies.
* '''Artifacts''': Tangible, reviewable records directly resulting from a practice or process being performed by a system or by personnel executing their role within that practice, control, or process.
* '''Physical Review''': Direct on-site observation and examination of evidence.
* '''Screen Share''': Real-time remote observation of a user demonstrating a task or process via shared computer screen, sometimes called "over-the-shoulder" review.

DISCLAIMER: Evidence requirements vary significantly across assessment types. '''The examples provided are illustrative only and should be tailored to meet the specific adequacy and sufficiency standards of your particular assessment context.'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmctoolkit.org contact us]. Thank you.

== Access Control (AC) ==
=== AC.L2-3.1.1 – Authorized Access Control [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.1_Details|'''AC.L2-3.1.1''']] Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems).
|-
| [a] authorized users are identified. || Document || Document defining account request, approval, provisioning.
|-
| [b] processes acting on behalf of authorized users are identified. || Document || Document defining account request, approval, provisioning.
|-
| [c] devices (and other systems) authorized to connect to the system are identified. || Document || Document defining account request, approval, provisioning.
|-
| [d] system access is limited to authorized users. || Screen Share || Screen share showing login requirements are enforced. Example of an unauthorized user denied (unauthorized username entered at login).
|-
| [e] system access is limited to processes acting on behalf of authorized users. || Screen Share || Screenshot showing that service accounts are assigned to authorized users only; no rogue accounts without an authorized user are active.
|-
| [f] system access is limited to authorized devices (including other systems). || Screen Share || Screen share showing that all devices running are authorized; no rogue devices on the network.
|}

=== AC.L2-3.1.2 – Transaction & Function Control [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.2_Details|'''AC.L2-3.1.2''']] Limit information system access to the types of transactions and functions that authorized users are permitted to execute.
|-
| [a] the types of transactions and functions that authorized users are permitted to execute are defined. || Document || SSP, AUP, or IAM document that defines what authorized users can execute.
|-
| [b] system access is limited to the defined types of transactions and functions for authorized users. || Screen Share || Screenshot of security roles in AD or IAM or other directory-based identity-related services tool that shows transactions are as defined in the SSP or IAM document; privileged and non-privileged accounts need to be defined and identified in the artifact; screenshot of a non-privileged user trying to execute a privileged function.
|}

=== AC.L2-3.1.3 – Control CUI Flow ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.3_Details|'''AC.L2-3.1.3''']] Control the flow of CUI in accordance with approved authorizations.
|-
| [a] information flow control policies are defined. || Document || SSP or other document describing the control of CUI on the network.
|-
| [b] methods and enforcement mechanisms for controlling the flow of CUI are defined. || Document || Document that defines the networking devices that are on the CUI network and answers what measures are in place to control the flow. List of firewalls, border and internal layer 3 devices, IDS/IPS, DLP, that process CUI.
|-
| [c] designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified. || Artifact || Network diagram, data flow diagram, external system connection diagrams, document describing the policies for CUI on the network; listing of VLANs and subnets where CUI is authorized; document must describe source and authorized destinations.
|-
| [d] authorizations for controlling the flow of CUI are defined. || Document || Document that defines how CUI is to be controlled, such as an InfoSec plan, and/or network management plan.
|-
| [e] approved authorizations for controlling the flow of CUI are enforced. || Screen Share || Screenshots of firewall rules, ACLs, etc.
|}

=== AC.L2-3.1.4 – Separation of Duties ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.4_Details|'''AC.L2-3.1.4''']] Separate the duties of individuals to reduce the risk of malevolent activity without collusion.
|-
| [a] the duties of individuals requiring separation are defined. || Document || Document, SSP, account management policy, defining separation of duties by person or role.
|-
| [b] responsibilities for duties that require separation are assigned to separate individuals. || Screen Share || Screenshot showing that separation of duties is enforced by showing admin accounts are assigned to different people based on role.
|-
| [c] access privileges that enable individuals to exercise the duties that require separation are granted to separate individuals. || Screen Share || Screen shot showing an example such as a security manager can not log into a network device and change ACLs, or network admins can not access security logs in the SIEM tool.
|}

=== AC.L2-3.1.5 – Least Privilege ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.5_Details|'''AC.L2-3.1.5''']] Employ the principle of least privilege, including for specific security functions and privileged accounts.
|-
| [a] privileged accounts are identified. || Document || "SSP or policy (documentation) identify what is considered a privileged account."
|-
| [b] access to privileged accounts is authorized in accordance with the principle of least privilege. || Artifact || An artifact that identifies the least amount of permissions associated with different types of privileged accounts are approved.
|-
| [c] security functions are identified. || Document || "SSP or policy (documentation) identifies what is considered a security account."
|-
| [d] access to security functions is authorized in accordance with the principle of least privilege. || Artifact || Artifact(s) that identify the least amount of permissions associated with different types of security accounts are approved.
|}

=== AC.L2-3.1.6 – Non-Privileged Account Use ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.6_Details|'''AC.L2-3.1.6''']] Use non-privileged accounts or roles when accessing nonsecurity functions.
|-
| [a] nonsecurity functions are identified. || Document || SSP or account management document, AUP, that defines non-security functions.
|-
| [b] users are required to use non-privileged accounts or roles when accessing nonsecurity functions. || Screen Share || Screenshot showing that a privileged user tried to use their admin account to access a non-security function, such as a browser or email (whatever is defined in their policy) and was blocked.
|}

=== AC.L2-3.1.7 – Privileged Functions ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.7_Details|'''AC.L2-3.1.7''']] Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.
|-
| [a] privileged functions are defined. || Document || SSP or policy (documentation) that defines privileged functions.
|-
| [b] non-privileged users are defined. || Document || SSP or policy (documentation) that defines non-privileged users.
|-
| [c] non-privileged users are prevented from executing privileged functions. || Screen Share || Screen share that shows that a non-privileged user is not allowed to complete a privileged function (installing software).
|-
| [d] the execution of privileged functions is captured in audit logs. || Screen Share || Screen share that shows logs being captured of the execution of privileged functions.
|}

=== AC.L2-3.1.8 – Unsuccessful Logon Attempts ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.8_Details|'''AC.L2-3.1.8''']] Limit unsuccessful logon attempts.
|-
| [a] the means of limiting unsuccessful logon attempts is defined. || Document || SSP or policy (documentation) showing unsuccessful logon attempts settings and or policy.
|-
| [b] the defined means of limiting unsuccessful logon attempts is implemented. || Artifact || Artifact showing GPO / Policy for limiting logon attempts.
|}

=== AC.L2-3.1.9 – Privacy & Security Notices ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.9_Details|'''AC.L2-3.1.9''']] Provide privacy and security notices consistent with applicable CUI rules.
|-
| [a] privacy and security notices required by CUI-specified rules are identified, consistent, and associated with the specific CUI category. || Document || SSP or policy (documentation) showing CUI-specified rules are identified, consistent, and associated with the specific CUI category.
|-
| [b] privacy and security notices are displayed. || Artifact || Artifact that shows a consent banner or screen that a user sees as they log in to the system.
|}

=== AC.L2-3.1.10 – Session Lock ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.10_Details|'''AC.L2-3.1.10''']] Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity.
|-
| [a] the period of inactivity after which the system initiates a session lock is defined. || Document || SSP or policy (documentation) that defines the period of inactivity and when a session lock is defined.
|-
| [b] access to the system and viewing of data is prevented by initiating a session lock after the defined period of inactivity. || Artifact || Artifact that shows the setting of session lock (GPO or system policy or similar solution addressing the controls supporting centralized management and configuration of operating systems, applications, and users' settings for the working environment of user accounts and computer accounts).
|-
| [c] previously visible information is concealed via a pattern-hiding display after the defined period of inactivity. || Document || Screenshot of GPO setting and configuration settings, or similar solution addressing the controls supporting centralized management and configuration of operating systems, applications, and users' settings for the working environment of user accounts and computer accounts.
|}

=== AC.L2-3.1.11 – Session Termination ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.11_Details|'''AC.L2-3.1.11''']] Terminate (automatically) a user session after a defined condition.
|-
| [a] conditions requiring a user session to terminate are defined. || Document || SSP or policy (documentation) that defines the conditions requiring a user session to be terminated.
|-
| [b] a user session is automatically terminated after any of the defined conditions. || Screen Share || Screen share showing GPO / VPN Settings that show when a session would be terminated (Idle time, max connection time).
|}

=== AC.L2-3.1.12 – Control Remote Access ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.12_Details|'''AC.L2-3.1.12''']] Monitor and control remote access sessions.
|-
| [a] remote access sessions are permitted. || Document || SSP or policy (documentation) that defines remote access sessions.
|-
| [b] the types of permitted remote access are identified. || Document || SSP or policy (documentation) that defines remote access is permitted.
|-
| [c] remote access sessions are controlled. || Screen Share || Screen share that shows how the remote access is controlled (access session, and or groups).
|-
| [d] remote access sessions are monitored. || Screen Share || Screen share that shows how remote sessions are monitored (logs).
|}

=== AC.L2-3.1.13 – Remote Access Confidentiality ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.13_Details|'''AC.L2-3.1.13''']] Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.
|-
| [a] cryptographic mechanisms to protect the confidentiality of remote access sessions are identified. || Document || SSP or policy (documentation) that discusses the CUI rules, consistent, and associated with the specific CUI category; FIPS Cert # of appliance or application.
|-
| [b] cryptographic mechanisms to protect the confidentiality of remote access sessions are implemented. || Screen Share || Screenshot of VPN concentration that shows encryption is on and enabled (point-to-point, etc.).
|}

=== AC.L2-3.1.14 – Remote Access Routing ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.14_Details|'''AC.L2-3.1.14''']] Route remote access via managed access control points.
|-
| [a] managed access control points are identified and implemented. || Screen Share || Screen share that shows access control points (groups and/or users).
|-
| [b] remote access is routed through managed network access control points. || Screen Share || Screen share that shows access control points and how they are managed.
|}

=== AC.L2-3.1.15 – Privileged Remote Access ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.15_Details|'''AC.L2-3.1.15''']] Authorize remote execution of privileged commands and remote access to security-relevant information.
|-
| [a] privileged commands authorized for remote execution are identified. || Document || SSP or policy (documentation) that defines what is authorized to be executed remotely and how that is handled.
|-
| [b] security-relevant information authorized to be accessed remotely is identified. || Document || SSP or policy (documentation) that defines what can be accessed remotely and what procedures are implemented to allow this (RDP, jump box).
|-
| [c] the execution of the identified privileged commands via remote access is authorized. || Artifact || Screen share that shows who has access to perform privileged commands a remotely (access groups for privileged accounts).
|-
| [d] access to the identified security-relevant information via remote access is authorized. || Artifact || Screen share that shows the routing of remote access and how it is monitored and how many locations (Firewall, VPN Concentrator).
|}

=== AC.L2-3.1.16 – Wireless Access Authorization ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.16_Details|'''AC.L2-3.1.16''']] Authorize wireless access prior to allowing such connections.
|-
| [a] wireless access points are identified. || Document || SSP, network administration document.
|-
| [b] wireless access is authorized prior to allowing such connections. || Screen Share || Authorization profile(s) in Wireless Access Controller or Identity Manager (i.e. Cisco ISE).
|}

=== AC.L2-3.1.17 – Wireless Access Protection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.17_Details|'''AC.L2-3.1.17''']] Protect wireless access using authentication and encryption.
|-
| [a] wireless access to the system is protected using authentication. || Screen Share || Security page (or similar) of a Wireless Access Controller.
|-
| [b] wireless access to the system is protected using encryption. || Screen Share || Security page (or similar) of a Wireless Access Controller.
|}

=== AC.L2-3.1.18 – Mobile Device Connection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.18_Details|'''AC.L2-3.1.18''']] Control connection of mobile devices.
|-
| [a] mobile devices that process, store, or transmit CUI are identified. || Document || SSP, Mobile Device Policy.
|-
| [b] mobile device connections are authorized. || Artifact || Authorization profile(s) in Wireless Access Controller or Identity Manager (i.e. Cisco ISE).
|-
| [c] mobile device connections are monitored and logged. || Screen Share || Mobile device logs within the MDM, log intake (sources) configuration (within SIEM) showing MDM is feeding logs to the SIEM.
|}

=== AC.L2-3.1.19 – Encrypt CUI on Mobile ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.19_Details|'''AC.L2-3.1.19''']] Encrypt CUI on mobile devices and mobile computing platforms.
|-
| [a] mobile devices and mobile computing platforms that process, store, or transmit CUI are identified. || Document || SSP, Mobile Device Policy.
|-
| [b] encryption is employed to protect CUI on identified mobile devices and mobile computing platforms. || Screen Share || Security policy page in MDM showing how encryption are enforced on mobile device. If no MDM or MDM doesn't enforce encryption, then validate if the devices used are on the list of devices with native FIPS approved validation.
|}

=== AC.L2-3.1.20 – External Connections [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.20_Details|'''AC.L2-3.1.20''']] Verify and control/limit connections to and use of external information systems.
|-
| [a] connections to external systems are identified. || Document || SSP, Systems Interconnection Agreements, SLA.
|-
| [b] the use of external systems is identified. || Document || SSP, Systems Interconnection Agreements, SLA.
|-
| [c] connections to external systems are verified. || Artifact || SLA for external systems, memorandum for interconnection, information to prove that any cloud solution is at FedRAMP impact level of moderate or higher (i.e. license information, screenshot of AWS cloud dashboard, purchase order document).
|-
| [d] the use of external systems is verified. || Artifact || SLA for external systems, memorandum for interconnection, information to prove that any cloud solution is at FedRAMP impact level of moderate or higher (i.e. license information, screenshot of AWS cloud dashboard, purchase order document).
|-
| [e] connections to external systems are controlled/limited. || Screen Share || Firewall ruleset for controlling access to cloud service or external system.
|-
| [f] the use of external systems is controlled/limited. || Screen Share || Firewall ruleset for controlling access to cloud service or external system.
|}

=== AC.L2-3.1.21 – Portable Storage Use ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.21_Details|'''AC.L2-3.1.21''']] Limit use of portable storage devices on external systems.
|-
| [a] the use of portable storage devices containing CUI on external systems is identified and documented. || Document || SSP, Removable Media Policy, Acceptable Use Policy (with emphasis on portable media use).
|-
| [b] limits on the use of portable storage devices containing CUI on external systems are defined. || Document || SSP, Removable Media Policy, Acceptable Use Policy (with emphasis on portable media use).
|-
| [c] the use of portable storage devices containing CUI on external systems is limited as defined. || Document || SSP, Removable Media Policy, Acceptable Use Policy (with emphasis on portable media use).
|}

=== AC.L2-3.1.22 – Control Public Information [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.22_Details|'''AC.L2-3.1.22''']] Control information posted or processed on publicly accessible information systems.
|-
| [a] individuals authorized to post or process information on publicly accessible systems are identified. || Document || SSP, Website Governance Plan, Information Release Document.
|-
| [b] procedures to ensure CUI is not posted or processed on publicly accessible systems are identified. || Document || SSP, Website Governance Plan, Information Release Document.
|-
| [c] a review process is in place prior to posting of any content to publicly accessible systems. || Artifact || "Information release approval process, i.e. chain of email communication from originator, approver, and final decision (may or may not include individual authorized to post);
SharePoint/electronic or paper form/ ticket system showing information flow between requestor and approver (may or may not include individual authorized to post)."
|-
| [d] content on publicly accessible systems is reviewed to ensure that it does not include CUI. || Artifact || Incident response process, web design/update/modification SOP etc.
|-
| [e] mechanisms are in place to remove and address improper posting of CUI. || Artifact || Incident response process, web design/update/modification SOP etc.
|}

== Awareness and Training (AT) ==
=== AT.L2-3.2.1 – Role-Based Risk Awareness ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AT.L2-3.2.1_Details|'''AT.L2-3.2.1''']] Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems.
|-
| [a] security risks associated with organizational activities involving CUI are identified. || Document || Policy of Security Awareness Training; Security Awareness Training Briefing.
|-
| [b] policies, standards, and procedures related to the security of the system are identified. || Document || Acceptable Use Policy, Policy/Procedures/Instruction related to the security of the system.
|-
| [c] managers, systems administrators, and users of the system are made aware of the security risks associated with their activities. || Artifact || Security Training Brief, training records.
|-
| [d] managers, systems administrators, and users of the system are made aware of the applicable policies, standards, and procedures related to the security of the system. || Artifact || Policies, standards and procedures for employees within training (completed training report).
|}

=== AT.L2-3.2.2 – Role-Based Training ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AT.L2-3.2.2_Details|'''AT.L2-3.2.2''']] Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities.|-
|-
| [a] information security-related duties, roles, and responsibilities are defined. || Document || Policy/Procedures/Instruction, Job Role Matrix, Position Descriptions, User Roles.
|-
| [b] information security-related duties, roles, and responsibilities are assigned to designated personnel. || Artifact || Screenshot of breakout of different roles/permissions assigned to individuals (i.e. ActiveDirectory); Privilege Access Agreement.
|-
| [c] personnel are adequately trained to carry out their assigned information security-related duties, roles, and responsibilities. || Artifact || Screenshot of tool and/or training specifying security specific roles, duties and responsibilities; Screenshot of required certifications (i.e. Sec+, CISSP).
|}

=== AT.L2-3.2.3 – Insider Threat Awareness ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AT.L2-3.2.3_Details|'''AT.L2-3.2.3''']] Provide security awareness training on recognizing and reporting potential indicators of insider threat.
|-
| [a] potential indicators associated with insider threats are identified. || Document || Insidert Threat Policy/Procedures/Instruction; Insider Threat Training/Briefing.
|-
| [b] security awareness training on recognizing and reporting potential indicators of insider threat is provided to managers and employees. || Artifact || Screenshot of training records showing completion of Insider Threat training, emails showing completion of Insider Threat training, Screenshot of certificate showing completion with individual's name.
|}

== Audit and Accountability (AU) ==
=== AU.L2-3.3.1 – System Auditing ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.1_Details|'''AU.L2-3.3.1''']] Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.
|-
| [a] audit logs needed (i.e., event types to be logged) to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity are specified. || Document || SSP, policy, or auditing and logging process that defines specific types of events to be logged.
|-
| [b] the content of audit records needed to support monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity is defined. || Document || SSP, policy, or auditing and logging process that defines specific content of audit records/files.
|-
| [c] audit records are created (generated). || Screen Share || Screen share of tool that shows logs are generated for all systems.
|-
| [d] audit records, once created, contain the defined content. || Screen Share || Screen share of tool that shows logs contain defined content as defined in SSP, policy, or procedures.
|-
| [e] retention requirements for audit records are defined. || Document || SSP, Polocy, or Auditing and logging process that describes how long records are kept.
|-
| [f] audit records are retained as defined. || Screen Share || Screen share of tool that shows records and audit content retained at a minimum as defined.
|}

=== AU.L2-3.3.2 – User Accountability ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.2_Details|'''AU.L2-3.3.2''']] Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions.
|-
| [a] the content of the audit records needed to support the ability to uniquely trace users to their actions is defined. || Document || SSP, policy, or process that defines actions traced back to individuals.
|-
| [b] audit records, once created, contain the defined content. || Screen Share || Screen share of tool that shows audit records traced to specific users/roles.
|}

=== AU.L2-3.3.3 – Event Review ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.3_Details|'''AU.L2-3.3.3''']] Review and update logged events.
|-
| [a] a process for determining when to review logged events is defined. || Document || SSP, policy, or documented process that shows frequency of when to review types of logged events.
|-
| [b] event types being logged are reviewed in accordance with the defined review process. || Artifact || Evidence through a documented method such as meeting minutes, CAB minutes, etc. of log sources and log events being logged at the defined frequency.
|-
| [c] event types being logged are updated based on the review. || Artifact || Evidence of implementation based on the results of the review of logged events/sources through a ticket, meeting minutes, or screen share of the tool that shows changes implemented (finetuning).
|}

=== AU.L2-3.3.4 – Audit Failure Alerting ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.4_Details|'''AU.L2-3.3.4''']] Alert in the event of an audit logging process failure.
|-
| [a] personnel or roles to be alerted in the event of an audit logging process failure are identified. || Document || SSP, policy, or procedure that shows who needs to be notified in case of an audit failure.
|-
| [b] types of audit logging process failures for which alert will be generated are defined. || Document || SSP, policy, or procedure that shows what types of failure will generate notifications.
|-
| [c] identified personnel or roles are alerted in the event of an audit logging process failure. || Artifact || Artifact such as email or ticket that shows the identified personnel were alerted of any audit/logging process failure as defined.
|}

=== AU.L2-3.3.5 – Audit Correlation ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.5_Details|'''AU.L2-3.3.5''']] Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.
|-
| [a] audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity are defined. || Document || SSP, policy, or procedure covering audit logging, monitoring, and reporting.
|-
| [b] defined audit record review, analysis, and reporting processes are correlated. || Artifact || Artifact showing an audit event and the resultant corrective action or actions to the event; this can be a Help Desk ticket, meeting notes, or a change control board items showing the event and any corrective action taken.
|}

=== AU.L2-3.3.6 – Reduction & Reporting ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.6_Details|'''AU.L2-3.3.6''']] Provide audit record reduction and report generation to support on-demand analysis and reporting.
|-
| [a] an audit record reduction capability that supports on-demand analysis is provided. || Screen Share || Screen share of the logging environment where an event can be selected and traced back to a specific device, or dashboard showing realtime event analysis.
|-
| [b] a report generation capability that supports on-demand reporting is provided. || Screen Share || Screen share showing the generation of an on demand report.
|}

=== AU.L2-3.3.7 – Authoritative Time Source ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.7_Details|'''AU.L2-3.3.7''']] Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.
|-
| [a] internal system clocks are used to generate time stamps for audit records. || Screen Share || Screen share showing the NTP settings of a windows, Unix, Linux device; a screen share showing the NTP settings of network appliances.
|-
| [b] an authoritative source with which to compare and synchronize internal system clocks is specified. || Document || SSP or policy indicating that devices need to be synched to a local authoritative time device that is synched with an authoritative time service.
|-
| [c] internal system clocks used to generate time stamps for audit records are compared to and synchronized with the specified authoritative time source. || Screen Share || Screen share showing device logging appliance time is point to the appropriate authoritative time server.
|}

=== AU.L2-3.3.8 – Audit Protection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.8_Details|'''AU.L2-3.3.8''']] Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
|-
| [a] audit information is protected from unauthorized access. || Screen Share || Screen share showing operating system permissions on the audit folders being restricted to appropriate users.
|-
| [b] audit information is protected from unauthorized modification. || Screen Share || Screen share showing operating system permissions on the audit folders being restricted to appropriate users.
|-
| [c] audit information is protected from unauthorized deletion. || Screen Share || Screen share showing operating system permissions on the audit folders being restricted to appropriate users.
|-
| [d] audit logging tools are protected from unauthorized access. || Screen Share || Artifact showing access permissions in the SIEM tool.
|-
| [e] audit logging tools are protected from unauthorized modification. || Screen Share || Artifact showing update permissions in the SIEM tool.
|-
| [f] audit logging tools are protected from unauthorized deletion. || Screen Share || Artifact showing delete permissions in the SIEM tool.
|}

=== AU.L2-3.3.9 – Audit Management ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.9_Details|'''AU.L2-3.3.9''']] Limit management of audit logging functionality to a subset of privileged users.
|-
| [a] a subset of privileged users granted access to manage audit logging functionality is defined. || Document || SSP or policy indicating which users or groups have access to audit logs.
|-
| [b] management of audit logging functionality is limited to the defined subset of privileged users. || Screen Share || Artifact showing SIEM or OS folder permissions (this should be limited to the assigned users or groups); artifact showing an ACL setting in SIEM tool in regards to logs.
|}

== Configuration Management (CM) ==
=== CM.L2-3.4.1 – System Baselining ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.1_Details|'''CM.L2-3.4.1''']] Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.
|-
| [a] a baseline configuration is established. || Document || Documentation showing or explaining standard imaging process (how standard images are deployed and where they are stored).
|-
| [b] the baseline configuration includes hardware, software, firmware, and documentation. || Artifact || Screenshot of repository of where images are maintained and information relating to hardware, software, and firmware.
|-
| [c] the baseline configuration is maintained (reviewed and updated) throughout the system development life cycle. || Artifact || Screenshot/evidence displaying management of baseline configurations (how often they are being managed as stated).
|-
| [d] a system inventory is established. || Document || Screenshot/evidence displaying inventory listing of approved products for use.
|-
| [e] the system inventory includes hardware, software, firmware, and documentation. || Artifact || Screeenshot/evidence displaying inventory listing of approved products and versions permitted for use.
|-
| [f] the inventory is maintained (reviewed and updated) throughout the system development life cycle. || Artifact || Screeenshot/evidence displaying management of baseline configurations (How often and are they being managed as stated.
|}

=== CM.L2-3.4.2 – Security Configuration Enforcement ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.2_Details|'''CM.L2-3.4.2''']] Establish and enforce security configuration settings for information technology products employed in organizational systems.
|-
| [a] security configuration settings for information technology products employed in the system are established and included in the baseline configuration. || Document || Documentation explaining methodology used by organization to create secure baselines (STIGs, benchmarks).
|-
| [b] security configuration settings for information technology products employed in the system are enforced. || Artifact || Evidence of tool/s used to enforce security configurations to ensure images used are free from modification unless authorized.
|}

=== CM.L2-3.4.3 – System Change Management ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.3_Details|'''CM.L2-3.4.3''']] Track, review, approve or disapprove, and log changes to organizational systems.
|-
| [a] changes to the system are tracked. || Artifact || Evidence of IT Service Management tool / process used to track system changes.
|-
| [b] changes to the system are reviewed. || Artifact || Evidence of IT Service Management tool / process used to review system changes.
|-
| [c] changes to the system are approved or disapproved. || Artifact || Evidence of IT Service Management tool / process used to approve/disapprove system changes.
|-
| [d] changes to the system are logged. || Artifact || Evidence of IT Service Management tool / process used to log system changes.
|}

=== CM.L2-3.4.4 – Security Impact Analysis ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.4_Details|'''CM.L2-3.4.4''']] Analyze the security impact of changes prior to implementation.
|-
| [a] the security impact of changes to the system is analyzed prior to implementation. || Artifact || Document explaining that security impact analysis of proposed changes to a system is conducted prior to implementation.
|}

=== CM.L2-3.4.5 – Access Restrictions for Change ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.5_Details|'''CM.L2-3.4.5''']] Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.
|-
| [a] physical access restrictions associated with changes to the system are defined. || Document || Document explaining the process of how physical access restrictions are defined for an individuals ability to make system changes.
|-
| [b] physical access restrictions associated with changes to the system are documented. || Document || Document explaining the process of how physical access restrictions are defined for an individuals ability to make system changes are documented; access request process.
|-
| [c] physical access restrictions associated with changes to the system are approved. || Artifact || Evidence of process of how physical access to systems are granted (i.e. physical access request sample).
|-
| [d] physical access restrictions associated with changes to the system are enforced. || Physical Review || Evidence of process of how physical access to systems are enforced (physical access system).
|-
| [e] logical access restrictions associated with changes to the system are defined. || Document || Document explaining the process of how logical access restrictions are defined for an individual's ability to make system changes.
|-
| [f] logical access restrictions associated with changes to the system are documented. || Document || Document explaining the process of how logical access restrictions are defined for an individual's ability to make system changes are documented.
|-
| [g] logical access restrictions associated with changes to the system are approved. || Artifact || Evidence of process of how logical access to systems are granted.
|-
| [h] logical access restrictions associated with changes to the system are enforced. || Artifact || Evidence of process of how logical access to systems are enforced.
|}

=== CM.L2-3.4.6 – Least Functionality ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.6_Details|'''CM.L2-3.4.6''']] Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.
|-
| [a] essential system capabilities are defined based on the principle of least functionality. || Document || Documentation explaining how systems are configured to utilize the principle of least functionality for designated users.
|-
| [b] the system is configured to provide only the defined essential capabilities. || Screen Share || Evidence displaying how systems are configured to utilize the principle of least functionality for designated users; disabled service settings, accepted standards for hardening (CIS benchmarks, etc.).
|}

=== CM.L2-3.4.7 – Nonessential Functionality ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.7_Details|'''CM.L2-3.4.7''']] Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.
|-
| [a] essential programs are defined. || Document || Documented essential programs specified; build documents; software center; SSP.
|-
| [b] the use of nonessential programs is defined. || Document || Documented listing of nonessential programs (whatever is NOT specified in [a]); AUP/User Agreement may identify nonessential use/programs.
|-
| [c] the use of nonessential programs is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict nonessential programs displays restrictions as defined (McAfee ePO settings, Carbon Black rules, etc.).
|-
| [d] essential functions are defined. || Document || Documented essential functions are specified.
|-
| [e] the use of nonessential functions is defined. || Document || Documented nonessential functions are specified.
|-
| [f] the use of nonessential functions is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict essential/nonessential functions displays restrictions as defined.
|-
| [g] essential ports are defined. || Document || Documented essential ports are specified.
|-
| [h] the use of nonessential ports is defined. || Document || Documented nonessential ports functions are specified.
|-
| [i] the use of nonessential ports is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict essential/nonessential ports displays restrictions as defined (FW rules; McAfee; GPO, etc.).
|-
| [j] essential protocols are defined. || Document || Documented essential protocols are specified.
|-
| [k] the use of nonessential protocols is defined. || Document || Documented nonessential protocols functions are specified.
|-
| [l] the use of nonessential protocols is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict essential/nonessential protocols displays restrictions as defined (FW rules; GPO, etc.).
|-
| [m] essential services are defined. || Document || Documented essential services specified.
|-
| [n] the use of nonessential services is defined. || Document || Documented nonessential services functions are specified.
|-
| [o] the use of nonessential services is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict essential/nonessential services displays restrictions as defined.
|}

=== CM.L2-3.4.8 – Application Execution Policy ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.8_Details|'''CM.L2-3.4.8''']] Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.
|-
| [a] a policy specifying whether whitelisting or blacklisting is to be implemented is specified. || Document || Documentation explaining whitelisting or blacklisting process.
|-
| [b] the software allowed to execute under whitelisting or denied use under blacklisting is specified. || Document || Documentation explaining whitelisting or blacklisting process for software.
|-
| [c] whitelisting to allow the execution of authorized software or blacklisting to prevent the use of unauthorized software is implemented as specified. || Screen Share || Tool used for whitelisting or blacklisting for software shows capability of restricting/authorizing software (Carbon Black dashboard, "SW Store", web proxies, DNS Blackhole, etc.).
|}

=== CM.L2-3.4.9 – User-Installed Software ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.9_Details|'''CM.L2-3.4.9''']] Control and monitor user-installed software.
|-
| [a] a policy for controlling the installation of software by users is established. || Document || Documented software authorization process or methodology for approval.
|-
| [b] installation of software by users is controlled based on the established policy. || Screen Share || Evidence that approval/restriction in installation of software by authorized personnel is implemented as specified (AUP, GPO, etc.).
|-
| [c] installation of software by users is monitored. || Screen Share || Evidence that installation of software by authorized personnel is monitored (SCCM groups, SW Center, etc.).
|}

== Identification and Authentication (IA) ==
=== IA.L2-3.5.1 – Identification [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.1_Details|'''IA.L2-3.5.1''']] Identify information system users, processes acting on behalf of users, or devices.
|-
| [a] system users are identified. || Document || Based on what is defined in their documentation (SSP, AUP, Policy, SOP), request to see a sample of non-privileged/privileged users in AD OU group (overlaps with 3.1.1 and 3.1.5).
|-
| [b] processes acting on behalf of users are identified. || Document || Based on what is defined in their documentation (SSP, AUP, Policy, SOP), request to see a sample of service accounts in AD OU group (overlaps with 3.1.1 and 3.1.5).
|-
| [c] devices accessing the system are identified. || Document || Based on what is defined in their documentation (SSP, AUP, Policy, SOP), request to see a sample of domain-joined workstation & servers in AD OU group (overlaps with 3.1.1 and 3.1.5). For network devices, request screen share/artifact to show how they are identified on the enterprise network.
|}

=== IA.L2-3.5.2 – Authentication [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.2_Details|'''IA.L2-3.5.2''']] Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems.
|-
| [a] the identity of each user is authenticated or verified as a prerequisite to system access. || Screen Share || If the user logs in with non-privileged account during other demoes and then a privileged account, then this should be satisfied. If screen share is unavailable, request logs to show successful and unsuccessful login by privileged and non-privilged users.
|-
| [b] the identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access. || Screen Share || Request a log that shows successful/unsuccessful service account trying to log on to company's asset.
|-
| [c] the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access. || Screen Share || Request a log that shows domain-joined workstation/server authenticating to AD (focus on the MAC/IP address/hostname).
|}

=== IA.L2-3.5.3 – Multifactor Authentication ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.3_Details|'''IA.L2-3.5.3''']] Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
|-
| [a] privileged accounts are identified. || Document || Based on what is defined in their documentation, request to see a sample of privileged users in AD OU group. Overlaps with 3.1.5. Screenshot/screen share to show implementation is enforced.
|-
| [b] multifactor authentication is implemented for local access to privileged accounts. || Screen Share || SSP, AUP, Policy, SOP that defines that MFA is needed for privileged local access.
|-
| [c] multifactor authentication is implemented for network access to privileged accounts. || Screen Share || Within the MFA implementation mechanism, show that privileged users are forced to use MFA; Screenshot/Screen share to show implementation is enforced.
|-
| [d] multifactor authentication is implemented for network access to non-privileged accounts. || Screen Share || Within the MFA implementation mechanism, show that non-privileged users are forced to use MFA; Screenshot/Screen share to show implementation is enforced.
|}

=== IA.L2-3.5.4 – Replay-Resistant Authentication ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.4_Details|'''IA.L2-3.5.4''']] Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.
|-
| [a] replay-resistant authentication mechanisms are implemented for network account access to privileged and non-privileged accounts. || Screen Share || Show the GPO setting that enforces Kerberos within AD. If MFA is used, show the implementation to enforce replay resistant techniques. For non-windows, show the technical solution to enforce replay resistant attacks.
|}

=== IA.L2-3.5.5 – Identifier Reuse ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.5_Details|'''IA.L2-3.5.5''']] Prevent reuse of identifiers for a defined period.
|-
| [a] a period within which identifiers cannot be reused is defined. || Document || SSP, policies, or SOP that defines identifier reuse.
|-
| [b] reuse of identifiers is prevented within the defined period. || Artifact || Show the GPO setting/technical solution that enforces what is defined in policy/documentation (this can be automated or manual process; screen share/artifacts can be presented to satisfy this requirement.
|}

=== IA.L2-3.5.6 – Identifier Handling ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.6_Details|'''IA.L2-3.5.6''']] Disable identifiers after a defined period of inactivity.
|-
| [a] a period of inactivity after which an identifier is disabled is defined. || Document || SSP, policy that defines the period of inactivity after which an identifier is disabled.
|-
| [b] identifiers are disabled after the defined period of inactivity. || Artifact || Screen share AD or similar tool supporting directory-based identity-related services for disabled accounts (can be done by hand or script).
|}

=== IA.L2-3.5.7 – Password Complexity ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.7_Details|'''IA.L2-3.5.7''']] Enforce a minimum password complexity and change of characters when new passwords are created.
|-
| [a] password complexity requirements are defined. || Document || SSP, policy that defines password complexity requirements.
|-
| [b] password change of character requirements are defined. || Document || SSP, policy that defines change of character requirements are defined.
|-
| [c] minimum password complexity requirements as defined are enforced when new passwords are created. || Screen Share || Screen share of AD or similar directory-based identity-related service tool to show complexity requirements.
|-
| [d] minimum password change of character requirements as defined are enforced when new passwords are created. || Screen Share || Screen share of Group Policy configuration or similar tool providing centralized management and configuration of operating systems, applications, and users' settings to show that characters must be changed.
|}

=== IA.L2-3.5.8 – Password Reuse ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.8_Details|'''IA.L2-3.5.8''']] Prohibit password reuse for a specified number of generations.
|-
| [a] the number of generations during which a password cannot be reused is specified. || Document || SSP, policy that specifies the number of generations during which a password cannot be reused is specified.
|-
| [b] reuse of passwords is prohibited during the specified number of generations. || Screen Share || Screen share Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration to show reuse of passwords is prohibited.
|}

=== IA.L2-3.5.9 – Temporary Passwords ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.9_Details|'''IA.L2-3.5.9''']] Allow temporary password use for system logons with an immediate change to a permanent password.
|-
| [a] an immediate change to a permanent password is required when a temporary password is used for system logon. || Screen Share || Screen share of Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration to show "change password at first logon."
|}

=== IA.L2-3.5.10 – Cryptographically-Protected Passwords ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.1_Details|'''IA.L2-3.5.1''']] Store and transmit only cryptographically-protected passwords.
|-
| [a] passwords are cryptographically protected in storage. || Screen Share || Screen share Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration that Kerberos, or a similar network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner, is enabled.
|-
| [b] passwords are cryptographically protected in transit. || Screen Share || Screen share Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration that Kerberos, or a similar network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner, is enabled.
|}

=== IA.L2-3.5.11 – Obscure Feedback ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.10_Details|'''IA.L2-3.5.10''']] Obscure feedback of authentication information.
|-
| [a] authentication information is obscured during the authentication process. || Screen Share || Screen share of Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration to show that passwords are obscured.
|}

== Incident Response (IR) ==
=== IR.L2-3.6.1 – Incident Handling ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IR.L2-3.6.1_Details|'''IR.L2-3.6.1''']] Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.
|-
| [a] an operational incident-handling capability is established. || Document || Incident Response SOP/Plan.
|-
| [b] the operational incident-handling capability includes preparation. || Document || Incident Response SOP/Plan, prior incident report, training, COOP plan.
|-
| [c] the operational incident-handling capability includes detection. || Document || Incident Response SOP/Plan; definition of tools used to detect; artifacts showing tools used; prior incident report.
|-
| [d] the operational incident-handling capability includes analysis. || Document || Incident Response SOP/Plan; Definition of tools used to analyze potential incidents; artifacts showing tools used for analysis; prior incident report.
|-
| [e] the operational incident-handling capability includes containment. || Document || Incident Response SOP/Plan; isolation/quarantine process; user training.
|-
| [f] the operational incident-handling capability includes recovery. || Document || Incident Response SOP/Plan; COOP Plan; prior incident reports, re-baselining impacted devices.
|-
| [g] the operational incident-handling capability includes user response. || Document || Incident Response SOP/Plan; user awareness training; Help Desk process.

|}

=== IR.L2-3.6.2 – Incident Reporting ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IR.L2-3.6.2_Details|'''IR.L2-3.6.2''']] Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.
|-
| [a] incidents are tracked. || Artifact || Incident Response SOP/Plan; ITSM artifact; technical implementation for incident tracking.
|-
| [b] incidents are documented. || Artifact || Incident Response SOP/Plan; ITSM artifact; technical implementation for incident tracking.
|-
| [c] authorities to whom incidents are to be reported are identified. || Document || Incident Response SOP/Plan.
|-
| [d] organizational officials to whom incidents are to be reported are identified. || Document || Incident Response SOP/Plan.
|-
| [e] identified authorities are notified of incidents. || Screen Share || Prior incident report; DIBNET login; prior email notifications.
|-
| [f] identified organizational officials are notified of incidents. || Artifact || Prior incident report; prior email notifications; tabletop exercises.
|}

=== IR.L2-3.6.3 – Incident Response Testing ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IR.L2-3.6.3_Details|'''IR.L2-3.6.3''']] Test the organizational incident response capability.
|-
| [a] the incident response capability is tested. || Artifact || Incident response table top/scheduled or unscheduled test or penetration test.
|}

== Maintenance (MA) ==
=== MA.L2-3.7.1 – Perform Maintenance ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.1_Details|'''MA.L2-3.7.1''']] Perform maintenance on organizational systems.
|-
| [a] system maintenance is performed. || Artifact || Establish typical maintenance activities (HVAC, UPS, power distribution, generators, copier maintenance) that are performed; maintenance agreements or contracts detailing these types of activities are acceptable; interview responses should be considered. This requirement should not be confused with 3.14.1 - report, remediate, and correct system flaws in a timely manner (patch management).
|}

=== MA.L2-3.7.2 – System Maintenance Control ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.2_Details|'''MA.L2-3.7.2''']] Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance.
|-
| [a] tools used to conduct system maintenance are controlled. || Artifact || Tools may largely depend on the assessed environment; discussion examples include network diagnostic and monitoring tools (including hardware and software); artifacts could demonstrate secured locations/areas for these tools (photos) or checkout sheets/rosters (documents) depicting responsible personnel and the dates/times of checkout.
|-
| [b] techniques used to conduct system maintenance are controlled. || Artifact || Processes for scheduling, performing, documenting, reviewing, approving, and monitoring maintenance and repairs for the information system.
|-
| [c] mechanisms used to conduct system maintenance are controlled. || Artifact || Processes for scheduling, performing, documenting, reviewing, approving, and monitoring maintenance and repairs for the information system.
|-
| [d] personnel used to conduct system maintenance are controlled. || Physical Review || Screenshot of who is authorized to conduct maintenance; maintenance personnel training program.
|}

=== MA.L2-3.7.3 – Equipment Sanitization ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.3_Details|'''MA.L2-3.7.3''']] Ensure equipment removed for off-site maintenance is sanitized of any CUI.
|-
| [a] equipment to be removed from organizational spaces for off-site maintenance is sanitized of any CUI. || Artifact || Document or artifact; record if equipment sanitized; categories of sanitization/destruction defined; sanitization procedural document.
|}

=== MA.L2-3.7.4 – Media Inspection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.4_Details|'''MA.L2-3.7.4''']] Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems.
|-
| [a] media containing diagnostic and test programs are checked for malicious code before being used in organizational systems that process, store, or transmit CUI. || Artifact || Screenshot of diagnostic/test program being used (such as Symantec and McAfee on access scans…).
|}

=== MA.L2-3.7.5 – Nonlocal Maintenance ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.5_Details|'''MA.L2-3.7.5''']] Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete.
|-
| [a] multifactor authentication is used to establish nonlocal maintenance sessions via external network connections. || Screen Share || Describe MFA used to remote from external service to organizational systems for maintenance and screenshot of MFA (3.5.3)(points associated with admin).
|-
| [b] nonlocal maintenance sessions established via external network connections are terminated when nonlocal maintenance is complete. || Screen Share || Screenshot VPN session timeout.
|}

=== MA.L2-3.7.6 – Maintenance Personnel ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.6_Details|'''MA.L2-3.7.6''']] Supervise the maintenance activities of maintenance personnel without required access authorization.
|-
| [a] maintenance personnel without required access authorization are supervised during maintenance activities. || Document || System maintenance policy; list of authorized personnel; maintenance records or, contracts/SLAs; WebEx.
|}

== Media Protection (MP) ==
=== MP.L2-3.8.1 – Media Protection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.1_Details|'''MP.L2-3.8.1''']] Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital.
|-
| [a] paper media containing CUI is physically controlled. || Document || Policy showing CUI paper media is controlled; artifact showing who has access; artifacts/records of inventories conducted; media check out procedures (i.e. file cabinets, encryption, password protection).
|-
| [b] digital media containing CUI is physically controlled. || Document || Policy showing CUI digital media is controlled; artifact showing who has access; artifacts/records of inventories conducted; media check out procedures (i.e. file cabinets, external drives, USBs, encryption, password protection).
|-
| [c] paper media containing CUI is securely stored. || Physical Review || Check out/sign out sheets; possible photo of storage container/video walk through of storage area; badge reader logs or access lists for keys for secured areas; interview response considered (i.e. file cabinets, encryption, password protection).
|-
| [d] digital media containing CUI is securely stored. || Physical Review || Check out/sign out sheets; possible photo of storage container/video walk through of storage area; badge reader logs or access lists for keys for secured areas; interview response considered (i.e. file cabinets, external drives, USBs, encryption, password protection).
|}

=== MP.L2-3.8.2 – Media Access ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.2_Details|'''MP.L2-3.8.2''']] Limit access to CUI on system media to authorized users.
|-
| [a] access to CUI on system media is limited to authorized users. || Artifact || Document describing how CUI is limited AND artifact showing principle of least access is implemented.
|}

=== MP.L2-3.8.3 – Media Disposal [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.3_Details|'''MP.L2-3.8.3''']] Sanitize or destroy information system media containing Federal Contract Information before disposal or release for reuse.
|-
| [a] system media containing CUI is sanitized or destroyed before disposal. || Document || Policy or artifact of media destruction logs; certificates of destruction; SLAs or contracts.
|-
| [b] system media containing CUI is sanitized before it is released for reuse. || Document || Policy or artifact describing method to sanitize, software used (i.e. DoD Wipe, ShredIT and Iron Mountain; Blancco; GDisk, DBAN).
|}

=== MP.L2-3.8.4 – Media Markings ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.4_Details|'''MP.L2-3.8.4''']] Mark media with necessary CUI markings and distribution limitations.
|-
| [a] media containing CUI is marked with applicable CUI markings. || Physical Review || Document or artifact showing CUI markings (i.e. labeling standards ).
|-
| [b] media containing CUI is marked with distribution limitations. || Physical Review || Document or artifact showing distro limitations (i.e. labeling standards ).
|}

=== MP.L2-3.8.5 – Media Accountability ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.5_Details|'''MP.L2-3.8.5''']] Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas.
|-
| [a] access to media containing CUI is controlled. || Document || Policy, artifact of audit logs showing tracking, Access Control Lists, records of transport activities (i.e. USB drives, CDs, chain of custody.
|-
| [b] accountability for media containing CUI is maintained during transport outside of controlled areas. || Artifact || Artifact of audit logs showing tracking, Access Control Lists, records of transport activities (i.e. USB drives, CDs; chain of custody.
|}

=== MP.L2-3.8.6 – Portable Storage Encryption ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.6_Details|'''MP.L2-3.8.6''']] Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards.
|-
| [a] the confidentiality of CUI stored on digital media is protected during transport using cryptographic mechanisms or alternative physical safeguards. || Artifact || Artifact showing crypto mechanisms used to protect (are they FIPS 140-2 [13.11]); artifact showing what alternative physical safeguards are in place (i.e. encryption; BitLocker; McAfee ).
|}

=== MP.L2-3.8.7 – Removable Media ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.7_Details|'''MP.L2-3.8.7''']] Control the use of removable media on system components.
|-
| [a] the use of removable media on system components is controlled. || Artifact || Policy showing if removable media is allowed; writable removable media is restricted; tracking artifacts; what tools are used (i.e. Carbon Black, Crowd Strike, GPO, Zoho Desktop Central); procedure/process describing what happens if it is lost; what mechanisms are in place to control/restrict removable media (i.e. Active Directory Groups and Group Policy artifact showing restriction).
|}

=== MP.L2-3.8.8 – Shared Media ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.8_Details|'''MP.L2-3.8.8''']] Prohibit the use of portable storage devices when such devices have no identifiable owner.ASSESSMENT OBJECTIVES'''
|-
| [a] the use of portable storage devices is prohibited when such devices have no identifiable owner. || Artifact || Policy and/or artifact showing company stance on portable storage devices if there is no owner (are personal USB devices allowed or are they company-issued; artifact showing alerts if device is connected to network (i.e. external HDD, Carbon Black, Crowd Strike, GPO, Zoho Desktop Central.
|}

=== MP.L2-3.8.9 – Protect Backups ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.9_Details|'''MP.L2-3.8.9''']] Protect the confidentiality of backup CUI at storage locations.
|-
| [a] the confidentiality of backup CUI is protected at storage locations. || Artifact || Policy on system backups; artifact showing media labeling; artifact showing encyption (is it FIPS 140-2 [13.11]); Access Control List artifact (i.e. backup tapes, Tivoli Storage Manager).
|}

== Personnel Security (PS) ==
=== PS.L2-3.9.1 – Screen Individuals ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PS.L2-3.9.1_Details|'''PS.L2-3.9.1''']] Screen individuals prior to authorizing access to organizational systems containing CUI.
|-
| [a] individuals are screened prior to authorizing access to organizational systems containing CUI. || Artifact || Screenshot of records of screened personnel/background checks.
|}

=== PS.L2-3.9.2 – Personnel Actions ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PS.L2-3.9.2_Details|'''PS.L2-3.9.2''']] Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers.
|-
| [a] a policy and/or process for terminating system access and any credentials coincident with personnel actions is established. || Document || Personnel security policy/procedures/instruction; Access control policy/procedure/instruction.
|-
| [b] system access and credentials are terminated consistent with personnel actions such as termination or transfer. || Artifact || Screenshot of records of personnel transfer and termination actions.
|-
| [c] the system is protected during and after personnel transfer actions. || Artifact || Completed outprocessing checklist.
|}

== Physical Protection (PE) ==
=== PE.L2-3.10.1 – Limit Physical Access [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.1_Details|'''PE.L2-3.10.1''']] Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals.
|-
| [a] authorized individuals allowed physical access are identified. || Artifact || Authorized personnel (names) access list.
|-
| [b] physical access to organizational systems is limited to authorized individuals. || Physical Review || Badge reader logs, audit logs, and/or card swipe test.
|-
| [c] physical access to equipment is limited to authorized individuals. || Physical Review || Badge reader logs, audit logs, and/or card swipe test.
|-
| [d] physical access to operating environments is limited to authorized. || Physical Review || Badge reader logs, audit logs, and/or card swipe test.
|}

=== PE.L2-3.10.2 – Monitor Facility ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.2_Details|'''PE.L2-3.10.2''']] Protect and monitor the physical facility and support infrastructure for organizational systems.
|-
| [a] the physical facility where organizational systems reside is protected. || Physical Review || Physical security measures and barriers into the physical facility (cameras/locks/gates/guards, etc.).
|-
| [b] the support infrastructure for organizational systems is protected. || Physical Review || Physical barriers to entries into computer spaces, server rooms, etc.
|-
| [c] the physical facility where organizational systems reside is monitored. || Physical Review || Audit logs/how the physical facility is being monitored (cameras/access system/guards, etc.).
|-
| [d] the support infrastructure for organizational systems is monitored. || Physical Review || Audit logs/how the physical facility is being monitored (cameras/access system/guards, etc.).
|}

=== PE.L2-3.10.3 – Escort Visitors [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.3_Details|'''PE.L2-3.10.3''']] Escort visitors and monitor visitor activity.
|-
| [a] visitors are escorted. || Physical Review || Policy/procedures/instruction on methodology for handling non-authorized personnel (entry to exit).
|-
| [b] visitor activity is monitored. || Physical Review || Policy/procedures/instructio on methodology for handling non-authorized personnel (entry to exit).
|}

=== PE.L2-3.10.4 – Physical Access Logs [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.4_Details|'''PE.L2-3.10.4''']] Maintain audit logs of physical access.
|-
| [a] audit logs of physical access are maintained. || Artifact || Log or report from badging system.
|}

=== PE.L2-3.10.5 – Manage Physical Access [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.5_Details|'''PE.L2-3.10.5''']] Control and manage physical access devices.
|-
| [a] physical access devices are identified. || Document || Physical access control systems description, guard force contract/policy, key locks, logical systems specifications, etc.
|-
| [b] physical access devices are controlled. || Physical Review || Inventory records of physical access control devices (e.g. keys, locks, card readers, locks, etc.).
|-
| [c] physical access devices are managed. || Physical Review || List of security safeguards controlling access to the facility (e.g. cameras, monitoring by guards, isolation of IT systems equiment and or system components).
|}

=== PE.L2-3.10.6 – Alternative Work Sites ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.6_Details|'''PE.L2-3.10.6''']] Enforce safeguarding measures for CUI at alternate work sites.
|-
| [a] safeguarding measures for CUI are defined for alternate work sites. || Document || Telework agreement, Acceptable Use Policy and SOP for alternate work locations; user security training validation which includes physical/logical/technical protections of system at alternate work sites.
|-
| [b] safeguarding measures for CUI are enforced for alternate work sites. || Artifact || Monitoring/audit log of user activity and logical/physical/technical mechanisms in place to preclude unauthorized activity (telework agreement , AUP?).
|}

== Risk Assessment (RA) ==
=== RA.L2-3.11.1 – Risk Assessments ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_RA.L2-3.11.1_Details|'''RA.L2-3.11.1''']] Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI.
|-
| [a] the frequency to assess risk to organizational operations, organizational assets, and individuals is defined. || Document || Risk assessment policy.
|-
| [b] risk to organizational operations, organizational assets, and individuals resulting from the operation of an organizational system that processes, stores, or transmits CUI is assessed with the defined frequency. || Artifact || Copy of last risk assessment done within defined frequency.
|}

=== RA.L2-3.11.2 – Vulnerability Scan ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_RA.L2-3.11.2_Details|'''RA.L2-3.11.2''']] Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
|-
| [a] the frequency to scan for vulnerabilities in organizational systems and applications is defined. || Document || Policy/procedures/instruction addressing vulnerability scanning records.
|-
| [b] vulnerability scans are performed on organizational systems with the defined frequency. || Screen Share || System configuration settings of vulnerability scanning scheduling and vulnerability scan results of systems within defined frequency.
|-
| [c] vulnerability scans are performed on applications with the defined frequency. || Screen Share || System configuration settings of vulnerability scanning scheduling and vulnerability scan results of applications within defined frequency.
|-
| [d] vulnerability scans are performed on organizational systems when new vulnerabilities are identified. || Screen Share || View signatures in scanning tool/ad hoc scan performed as a result.
|-
| [e] vulnerability scans are performed on applications when new vulnerabilities are identified. || Screen Share || View signatures in scanning tool/ad hoc scan performed as a result.
|}

=== RA.L2-3.11.3 – Vulnerability Remediation ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_RA.L2-3.11.3_Details|'''RA.L2-3.11.3''']] Remediate vulnerabilities in accordance with risk assessments.
|-
| [a] vulnerabilities are identified. || Artifact || Scan results showing vulnerabilities identified.
|-
| [b] vulnerabilities are remediated in accordance with risk assessments. || Artifact || Screenshot/document of scan results of remediated vulnerabilities in accordance to risk assessments.
|}

== Security Assessment (CA) ==
=== CA.L2-3.12.1 – Security Control Assessment ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CA.L2-3.12.1_Details|'''CA.L2-3.12.1''']] Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.
|-
| [a] the frequency of security control assessments is defined. || Document || SSP.
|-
| [b] security controls are assessed with the defined frequency to determine if the controls are effective in their application. || Artifact || Copy of last security control assessment done within defined frequency.
|}

=== CA.L2-3.12.2 – Operational Plan of Action ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CA.L2-3.12.2_Details|'''CA.L2-3.12.2''']] Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.
|-
| [a] deficiencies and vulnerabilities to be addressed by the plan of action are identified. || Artifact || Plan of Action (POA).
|-
| [b] a plan of action is developed to correct identified deficiencies and reduce or eliminate identified vulnerabilities. || Artifact || Plan of Action (POA).
|-
| [c] the plan of action is implemented to correct identified deficiencies and reduce or eliminate identified vulnerabilities. || Artifact || Plan of Action (POA)/previously completed POAs.
|}

=== CA.L2-3.12.3 – Security Control Monitoring ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CA.L2-3.12.3_Details|'''CA.L2-3.12.3''']] Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.
|-
| [a] security controls are monitored on an ongoing basis to ensure the continued effectiveness of those controls. || Artifact || Collection of risk assessment results, internal or third-party audits/security assessments and/or continuous monitoring reports/alerts (SIEM tool, etc.).
|}

=== CA.L2-3.12.4 – System Security Plan ====
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CA.L2-3.12.4_Details|'''CA.L2-3.12.4''']] Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.
|-
| [a] a system security plan is developed. || Document || SSP.
|-
| [b] the system boundary is described and documented in the system security plan. || Document || SSP and any supporting documentation.
|-
| [c] the system environment of operation is described and documented in the system security plan. || Document || SSP and any supporting documentation.
|-
| [d] the security requirements identified and approved by the designated authority as non-applicable are identified. || Document || SSP and required adjudication from DoD CIO.
|-
| [e] the method of security requirement implementation is described and documented in the system security plan. || Document || SSP and any supporting documentation.
|-
| [f] the relationship with or connection to other systems is described and documented in the system security plan. || Document || SSP and any supporting documentation.
|-
| [g] the frequency to update the system security plan is defined. || Document || SSP.
|-
| [h] system security plan is updated with the defined frequency. || Document || SSP/any previous versions.
|}

== System and Communications Protection (SC) ==
=== SC.L2-3.13.1 – Boundary Protection [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.1_Details|'''SC.L2-3.13.1''']] Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems.
|-
| [a] the external system boundary is defined. || Document || SSP, network diagrams, CUI flow, cloud provider FedRAMP Moderate.
|-
| [b] key internal system boundaries are defined. || Document || SSP, network diagrams, CUI flow.
|-
| [c] communications are monitored at the external system boundary. || Screen Share || SSP, logging server, boundary device configurations, monitoring policy.
|-
| [d] communications are monitored at key internal boundaries. || Screen Share || SSP, logging server, boundary device configurations, monitoring policy.
|-
| [e] communications are controlled at the external system boundary. || Screen Share || SSP, boundary device configurations, ACL, subnets, DMZ.
|-
| [f] communications are controlled at key internal boundaries. || Screen Share || SSP, boundary device configurations, ACL, subnets.
|-
| [g] communications are protected at the external system boundary. || Screen Share || Configurations for IPS/IDS, email gateway, VLAN, proxy, firewall, malware protection, DNS, TSL.
|-
| [h] communications are protected at key internal boundaries. || Screen Share || Configurations for IPS/IDS, VLAN, firewall, malware protection, SSL.
|}

=== SC.L2-3.13.2 – Security Engineering ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.2_Details|'''SC.L2-3.13.2''']] Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.
|-
| [a] architectural designs that promote effective information security are identified. || Document || SSP, config management policy, network diagram, CCB minutes, enterprise architecture process.
|-
| [b] software development techniques that promote effective information security are identified. || Document || SSP, config management policy, SDLC, CCB minutes.
|-
| [c] systems engineering principles that promote effective information security are identified. || Document || SSP, config management policy, CCB minutes, security architecture engineering.
|-
| [d] identified architectural designs that promote effective information security are employed. || Artifact || CCB minutes, Network diagrams and configurations, Project Plans.
|-
| [e] identified software development techniques that promote effective information security are employed. || Artifact || CCB minutes, SDLC, code scanner results, code management tracking.
|-
| [f] identified systems engineering principles that promote effective information security are employed. || Artifact || CCB minutes, configuration management, ITSM, patch management, lifecycle replacement processes.
|}

=== SC.L2-3.13.3 – Role Separation ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.3_Details|'''SC.L2-3.13.3''']] Separate user functionality from system management functionality.
|-
| [a] user functionality is identified. || Document || SSP, AUP.
|-
| [b] system management functionality is identified. || Document || SSP, Privileged Account Agreement.
|-
| [c] user functionality is separated from system management functionality. || Screen Share || Active Directory, Jump Boxes, GPO, VM, RDP.
|}

=== SC.L2-3.13.4 – Shared Resource Control ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.4_Details|'''SC.L2-3.13.4''']] Prevent unauthorized and unintended information transfer via shared system resources.
|-
| [a] unauthorized and unintended information transfer via shared system resources is prevented. || Screen Share || SSP, OS configurations, Linux containers, system/media reuse policies, certificate management policies, media destruction policies, printer configs, VDI configuration.
|}

=== SC.L2-3.13.5 – Public-Access System Separation [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.5_Details|'''SC.L2-3.13.5''']] Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
|-
| [a] publicly accessible system components are identified. || Document || SSP, network diagram, DMZ inventory/roles.
|-
| [b] subnetworks for publicly accessible system components are physically or logically separated from internal networks. || Artifact || Network diagram, IPAM, VLAN, DHCP, DMZ.
|}

=== SC.L2-3.13.6 – Network Communication by Exception ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.6_Details|'''SC.L2-3.13.6''']] Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).
|-
| [a] network communications traffic is denied by default. || Screen Share || Host and network firewall rules, SIEM logs, hit counts.
|-
| [b] network communications traffic is allowed by exception. || Screen Share || Host and network firewall rules, SIEM logs, hit counts.
|}

=== SC.L2-3.13.7 – Split Tunneling ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.7_Details|'''SC.L2-3.13.7''']] Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling).
|-
| [a] remote devices are prevented from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks (i.e., split tunneling). || Screen Share || VPN appliance/server configuration, endpoint VPN software configuration.
|}

=== SC.L2-3.13.8 – Data in Transit ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.8_Details|'''SC.L2-3.13.8''']] Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.
|-
| [a] cryptographic mechanisms intended to prevent unauthorized disclosure of CUI are identified. || Document || SSP, PKI policies, configuration processes, config management, email attachment encryption policy, removable media policy, data at rest policy.
|-
| [b] alternative physical safeguards intended to prevent unauthorized disclosure of CUI are identified. || Document || SSP, physical security policy.
|-
| [c] either cryptographic mechanisms or alternative physical safeguards are implemented to prevent unauthorized disclosure of CUI during transmission. || Artifact || TLS settings, SSL settings, VPN/Wireless Access Points/Mobile Devices cryptographic settings, ODBC connector settings, SAN configuration, IPSec/MPLS, backup configuration, physical security.
|}

=== SC.L2-3.13.9 – Connections Termination ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.9_Details|'''SC.L2-3.13.9''']] Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity.
|-
| [a] a period of inactivity to terminate network connections associated with communications sessions is defined. || Document || SSP, network communications policy.
|-
| [b] network connections associated with communications sessions are terminated at the end of the sessions. || Screen Share || VPN appliance/server logs, VPN configurations, web server configurations, firewall connection settings.
|-
| [c] network connections associated with communications sessions are terminated after the defined period of inactivity. || Screen Share || VPN appliance/server logs, VPN configurations, web server configurations, frewall connection settings.
|}

=== SC.L2-3.13.10 – Key Management ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.10_Details|'''SC.L2-3.13.10''']] Establish and manage cryptographic keys for cryptography employed in organizational systems.
|-
| [a] cryptographic keys are established whenever cryptography is employed. || Artifact || SSP, PKI/certificate management policy, configuration management.
|-
| [b] cryptographic keys are managed whenever cryptography is employed. || Artifact || SSP, PKI/certificate management policy, configuration management, access control policy.
|}

=== SC.L2-3.13.11 – CUI Encryption ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.11_Details|'''SC.L2-3.13.11''']] Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.
|-
| [a] FIPS-validated cryptography is employed to protect the confidentiality of CUI. || Screen Share || VPN, wireless, mobile devices, client certificates, server certificates, disk encryption, Outlook plugin, external mail, backup media, ePO server, removable storage, SAN, file compression; look for FIPS mode enabled on appliances.
|}

=== SC.L2-3.13.12 – Collaborative Device Control ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.12_Details|'''SC.L2-3.13.12''']] Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device.
|-
| [a] collaborative computing devices are identified. || Document || SSP, network diagrams.
|-
| [b] collaborative computing devices provide indication to users of devices in use. || Physical Review || Physical inspection of device.
|-
| [c] remote activation of collaborative computing devices is prohibited. || Artifact || Collaboration device configuration/console.
|}

=== SC.L2-3.13.13 – Mobile Code ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.13_Details|'''SC.L2-3.13.13''']] Control and monitor the use of mobile code.
|-
| [a] use of mobile code is controlled. || Screen Share || GPO settings, malware protection, software agent configurations, software development policies, code scanners, MDM configuration, firewall/secure web gateway/proxy config.
|-
| [b] use of mobile code is monitored. || Screen Share || SIEM/console monitoring.
|}

=== SC.L2-3.13.14 – Voice over Internet Protocol ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.14_Details|'''SC.L2-3.13.14''']] Control and monitor the use of Voice over Internet Protocol (VoIP) technologies.
|-
| [a] use of Voice over Internet Protocol (VoIP) technologies is controlled. || Artifact || VLAN, ACL, firewall config, VoIP gateway/condenser configuration.
|-
| [b] use of Voice over Internet Protocol (VoIP) technologies is monitored. || Artifact || SIEM/VoIP console monitoring, session border controller.
|}

=== SC.L2-3.13.15 – Communications Authenticity ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.15_Details|'''SC.L2-3.13.15''']] Protect the authenticity of communications sessions.
|-
| [a] the authenticity of communications sessions is protected. || Screen Share || SSL, TLS, SMB3, SFTP, IPSec, SSH, Kerberos configs, MPLS, Network Access Control.
|}

=== SC.L2-3.13.16 – Data at Rest ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.16_Details|'''SC.L2-3.13.16''']] Protect the confidentiality of CUI at rest.
|-
| [a] the confidentiality of CUI at rest is protected. || Artifact || Full disk encryption, removable media encryption, SAN encryption, digital backups, mobile device encryption, third party offsite backup storage, cloud virtualization encryption, physical media storage policies.
|}

== System and Information Integrity (SI) ==
=== SI.L2-3.14.1 – Flaw Remediation [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.1_Details|'''SI.L2-3.14.1''']] Identify, report, and correct information and information system flaws in a timely manner.
|-
| [a] the time within which to identify system flaws is specified. || Document || SSP, patch management policy.
|-
| [b] system flaws are identified within the specified time frame. || Screen Share || Vulnerability management scanner output and scan policy configuration.
|-
| [c] the time within which to report system flaws is specified. || Document || SSP, patch management policy.
|-
| [d] system flaws are reported within the specified time frame. || Screen Share || ITSM/trouble tickets, vulnerability management scanner output.
|-
| [e] the time within which to correct system flaws is specified. || Document || SSP, patch management policy.
|-
| [f] system flaws are corrected within the specified time frame. || Screen Share || Vulnerability management scanner output and scan policy configuration.
|}

=== SI.L2-3.14.2 – Malicious Code ProTection [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.2_Details|'''SI.L2-3.14.2''']] Provide protection from malicious code at appropriate locations within organizational information systems.
|-
| [a] designated locations for malicious code protection are identified. || Document || SSP, system protection policy, network diagrams, security architecture documents.
|-
| [b] protection from malicious code at designated locations is provided. || Screen Share || Endpoint security settings, email/web proxy gateways, firewall, IPS sensor, MDM configuration, Network Access Control.
|}

=== SI.L2-3.14.3 – Security Alerts & Advisories ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.3_Details|'''SI.L2-3.14.3''']] Monitor system security alerts and advisories and take action in response.
|-
| [a] response actions to system security alerts and advisories are identified. || Document || SSP, vulnerability management policy, Incident Response Plan.
|-
| [b] system security alerts and advisories are monitored. || Artifact || Threat intelligence subscriptions, email advisories.
|-
| [c] actions in response to system security alerts and advisories are taken. || Artifact || ITSM/trouble tickets, user notifications, updates to firewall/IPS, etc.
|}

=== SI.L2-3.14.4 – Update Malicious Code Protection [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.4_Details|'''SI.L2-3.14.4''']] Update malicious code protection mechanisms when new releases are available.
|-
| [a] malicious code protection mechanisms are updated when new releases are available. || Screen Share || Antivirus console dashboard, firewall AV, Email gateway signatures,proxy, IPS updates.
|}

=== SI.L2-3.14.5 – System & File Scanning [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.5_Details|'''SI.L2-3.14.5''']] Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed.
|-
| [a] the frequency for malicious code scans is defined. || Document || SSP, vulnerability management policy.
|-
| [b] malicious code scans are performed with the defined frequency. || Screen Share || Consoles for AV (endpoints, servers, and file shares), firewall, email gateway, proxy, IPS, MDM configurations.
|-
| [c] real-time malicious code scans of files from external sources as files are downloaded, opened, or executed are performed. || Screen Share || Consoles for AV (endpoints, servers, and file shares), firewall, email gateway, proxy, IPS, MDM configurations.
|}

=== SI.L2-3.14.6 – Monitor Communications for Attacks ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.6_Details|'''SI.L2-3.14.6''']] Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.
|-
| [a] the system is monitored to detect attacks and indicators of potential attacks. || Screen Share || Firewall, IPS, endpoint protection, SIEM alerts and reports.
|-
| [b] inbound communications traffic is monitored to detect attacks and indicators of potential attacks. || Screen Share || Firewall, IPS, endpoint protection, SIEM alerts and reports.
|-
| [c] outbound communications traffic is monitored to detect attacks and indicators of potential attacks. || Screen Share || Firewall, IPS, endpoint protection, SIEM alerts and reports.
|}

=== SI.L2-3.14.7 – Identify Unauthorized Use ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.7_Details|'''SI.L2-3.14.7''']] Identify unauthorized use of organizational systems.
|-
| [a] authorized use of the system is defined. || Document || AUP, SSP.
|-
| [b] unauthorized use of the system is identified. || Artifact || SIEM logs, endpoint protection console, IPS, Firewall.
|}

Evidence Collection Approach

2026-07-20T01:49:19Z

David: /* SC.L2-3.13.9 – Connections Termination */

CMMC assessments and certification require substantial evidence and documentation. The following tables outline general guidelines for collecting evidence to assess control requirements and objectives. While these guidelines provide a structured approach, they are not the only means of conducting an accurate assessment. Assessors should exercise professional judgment and may employ alternative methods appropriate to the specific organizational context and circumstances.

Evidence collection approaches are defined as:
* '''Documentation''': Tangible materials containing information over which an organization has authority, including all types of written records and their copies.
* '''Artifacts''': Tangible, reviewable records directly resulting from a practice or process being performed by a system or by personnel executing their role within that practice, control, or process.
* '''Physical Review''': Direct on-site observation and examination of evidence.
* '''Screen Share''': Real-time remote observation of a user demonstrating a task or process via shared computer screen, sometimes called "over-the-shoulder" review.

DISCLAIMER: Evidence requirements vary significantly across assessment types. '''The examples provided are illustrative only and should be tailored to meet the specific adequacy and sufficiency standards of your particular assessment context.'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmctoolkit.org contact us]. Thank you.

== Access Control (AC) ==
=== AC.L2-3.1.1 – Authorized Access Control [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.1_Details|'''AC.L2-3.1.1''']] Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems).
|-
| [a] authorized users are identified. || Document || Document defining account request, approval, provisioning.
|-
| [b] processes acting on behalf of authorized users are identified. || Document || Document defining account request, approval, provisioning.
|-
| [c] devices (and other systems) authorized to connect to the system are identified. || Document || Document defining account request, approval, provisioning.
|-
| [d] system access is limited to authorized users. || Screen Share || Screen share showing login requirements are enforced. Example of an unauthorized user denied (unauthorized username entered at login).
|-
| [e] system access is limited to processes acting on behalf of authorized users. || Screen Share || Screenshot showing that service accounts are assigned to authorized users only; no rogue accounts without an authorized user are active.
|-
| [f] system access is limited to authorized devices (including other systems). || Screen Share || Screen share showing that all devices running are authorized; no rogue devices on the network.
|}

=== AC.L2-3.1.2 – Transaction & Function Control [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.2_Details|'''AC.L2-3.1.2''']] Limit information system access to the types of transactions and functions that authorized users are permitted to execute.
|-
| [a] the types of transactions and functions that authorized users are permitted to execute are defined. || Document || SSP, AUP, or IAM document that defines what authorized users can execute.
|-
| [b] system access is limited to the defined types of transactions and functions for authorized users. || Screen Share || Screenshot of security roles in AD or IAM or other directory-based identity-related services tool that shows transactions are as defined in the SSP or IAM document; privileged and non-privileged accounts need to be defined and identified in the artifact; screenshot of a non-privileged user trying to execute a privileged function.
|}

=== AC.L2-3.1.3 – Control CUI Flow ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.3_Details|'''AC.L2-3.1.3''']] Control the flow of CUI in accordance with approved authorizations.
|-
| [a] information flow control policies are defined. || Document || SSP or other document describing the control of CUI on the network.
|-
| [b] methods and enforcement mechanisms for controlling the flow of CUI are defined. || Document || Document that defines the networking devices that are on the CUI network and answers what measures are in place to control the flow. List of firewalls, border and internal layer 3 devices, IDS/IPS, DLP, that process CUI.
|-
| [c] designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified. || Artifact || Network diagram, data flow diagram, external system connection diagrams, document describing the policies for CUI on the network; listing of VLANs and subnets where CUI is authorized; document must describe source and authorized destinations.
|-
| [d] authorizations for controlling the flow of CUI are defined. || Document || Document that defines how CUI is to be controlled, such as an InfoSec plan, and/or network management plan.
|-
| [e] approved authorizations for controlling the flow of CUI are enforced. || Screen Share || Screenshots of firewall rules, ACLs, etc.
|}

=== AC.L2-3.1.4 – Separation of Duties ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.4_Details|'''AC.L2-3.1.4''']] Separate the duties of individuals to reduce the risk of malevolent activity without collusion.
|-
| [a] the duties of individuals requiring separation are defined. || Document || Document, SSP, account management policy, defining separation of duties by person or role.
|-
| [b] responsibilities for duties that require separation are assigned to separate individuals. || Screen Share || Screenshot showing that separation of duties is enforced by showing admin accounts are assigned to different people based on role.
|-
| [c] access privileges that enable individuals to exercise the duties that require separation are granted to separate individuals. || Screen Share || Screen shot showing an example such as a security manager can not log into a network device and change ACLs, or network admins can not access security logs in the SIEM tool.
|}

=== AC.L2-3.1.5 – Least Privilege ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.5_Details|'''AC.L2-3.1.5''']] Employ the principle of least privilege, including for specific security functions and privileged accounts.
|-
| [a] privileged accounts are identified. || Document || "SSP or policy (documentation) identify what is considered a privileged account."
|-
| [b] access to privileged accounts is authorized in accordance with the principle of least privilege. || Artifact || An artifact that identifies the least amount of permissions associated with different types of privileged accounts are approved.
|-
| [c] security functions are identified. || Document || "SSP or policy (documentation) identifies what is considered a security account."
|-
| [d] access to security functions is authorized in accordance with the principle of least privilege. || Artifact || Artifact(s) that identify the least amount of permissions associated with different types of security accounts are approved.
|}

=== AC.L2-3.1.6 – Non-Privileged Account Use ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.6_Details|'''AC.L2-3.1.6''']] Use non-privileged accounts or roles when accessing nonsecurity functions.
|-
| [a] nonsecurity functions are identified. || Document || SSP or account management document, AUP, that defines non-security functions.
|-
| [b] users are required to use non-privileged accounts or roles when accessing nonsecurity functions. || Screen Share || Screenshot showing that a privileged user tried to use their admin account to access a non-security function, such as a browser or email (whatever is defined in their policy) and was blocked.
|}

=== AC.L2-3.1.7 – Privileged Functions ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.7_Details|'''AC.L2-3.1.7''']] Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.
|-
| [a] privileged functions are defined. || Document || SSP or policy (documentation) that defines privileged functions.
|-
| [b] non-privileged users are defined. || Document || SSP or policy (documentation) that defines non-privileged users.
|-
| [c] non-privileged users are prevented from executing privileged functions. || Screen Share || Screen share that shows that a non-privileged user is not allowed to complete a privileged function (installing software).
|-
| [d] the execution of privileged functions is captured in audit logs. || Screen Share || Screen share that shows logs being captured of the execution of privileged functions.
|}

=== AC.L2-3.1.8 – Unsuccessful Logon Attempts ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.8_Details|'''AC.L2-3.1.8''']] Limit unsuccessful logon attempts.
|-
| [a] the means of limiting unsuccessful logon attempts is defined. || Document || SSP or policy (documentation) showing unsuccessful logon attempts settings and or policy.
|-
| [b] the defined means of limiting unsuccessful logon attempts is implemented. || Artifact || Artifact showing GPO / Policy for limiting logon attempts.
|}

=== AC.L2-3.1.9 – Privacy & Security Notices ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.9_Details|'''AC.L2-3.1.9''']] Provide privacy and security notices consistent with applicable CUI rules.
|-
| [a] privacy and security notices required by CUI-specified rules are identified, consistent, and associated with the specific CUI category. || Document || SSP or policy (documentation) showing CUI-specified rules are identified, consistent, and associated with the specific CUI category.
|-
| [b] privacy and security notices are displayed. || Artifact || Artifact that shows a consent banner or screen that a user sees as they log in to the system.
|}

=== AC.L2-3.1.10 – Session Lock ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.10_Details|'''AC.L2-3.1.10''']] Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity.
|-
| [a] the period of inactivity after which the system initiates a session lock is defined. || Document || SSP or policy (documentation) that defines the period of inactivity and when a session lock is defined.
|-
| [b] access to the system and viewing of data is prevented by initiating a session lock after the defined period of inactivity. || Artifact || Artifact that shows the setting of session lock (GPO or system policy or similar solution addressing the controls supporting centralized management and configuration of operating systems, applications, and users' settings for the working environment of user accounts and computer accounts).
|-
| [c] previously visible information is concealed via a pattern-hiding display after the defined period of inactivity. || Document || Screenshot of GPO setting and configuration settings, or similar solution addressing the controls supporting centralized management and configuration of operating systems, applications, and users' settings for the working environment of user accounts and computer accounts.
|}

=== AC.L2-3.1.11 – Session Termination ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.11_Details|'''AC.L2-3.1.11''']] Terminate (automatically) a user session after a defined condition.
|-
| [a] conditions requiring a user session to terminate are defined. || Document || SSP or policy (documentation) that defines the conditions requiring a user session to be terminated.
|-
| [b] a user session is automatically terminated after any of the defined conditions. || Screen Share || Screen share showing GPO / VPN Settings that show when a session would be terminated (Idle time, max connection time).
|}

=== AC.L2-3.1.12 – Control Remote Access ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.12_Details|'''AC.L2-3.1.12''']] Monitor and control remote access sessions.
|-
| [a] remote access sessions are permitted. || Document || SSP or policy (documentation) that defines remote access sessions.
|-
| [b] the types of permitted remote access are identified. || Document || SSP or policy (documentation) that defines remote access is permitted.
|-
| [c] remote access sessions are controlled. || Screen Share || Screen share that shows how the remote access is controlled (access session, and or groups).
|-
| [d] remote access sessions are monitored. || Screen Share || Screen share that shows how remote sessions are monitored (logs).
|}

=== AC.L2-3.1.13 – Remote Access Confidentiality ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.13_Details|'''AC.L2-3.1.13''']] Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.
|-
| [a] cryptographic mechanisms to protect the confidentiality of remote access sessions are identified. || Document || SSP or policy (documentation) that discusses the CUI rules, consistent, and associated with the specific CUI category; FIPS Cert # of appliance or application.
|-
| [b] cryptographic mechanisms to protect the confidentiality of remote access sessions are implemented. || Screen Share || Screenshot of VPN concentration that shows encryption is on and enabled (point-to-point, etc.).
|}

=== AC.L2-3.1.14 – Remote Access Routing ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.14_Details|'''AC.L2-3.1.14''']] Route remote access via managed access control points.
|-
| [a] managed access control points are identified and implemented. || Screen Share || Screen share that shows access control points (groups and/or users).
|-
| [b] remote access is routed through managed network access control points. || Screen Share || Screen share that shows access control points and how they are managed.
|}

=== AC.L2-3.1.15 – Privileged Remote Access ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.15_Details|'''AC.L2-3.1.15''']] Authorize remote execution of privileged commands and remote access to security-relevant information.
|-
| [a] privileged commands authorized for remote execution are identified. || Document || SSP or policy (documentation) that defines what is authorized to be executed remotely and how that is handled.
|-
| [b] security-relevant information authorized to be accessed remotely is identified. || Document || SSP or policy (documentation) that defines what can be accessed remotely and what procedures are implemented to allow this (RDP, jump box).
|-
| [c] the execution of the identified privileged commands via remote access is authorized. || Artifact || Screen share that shows who has access to perform privileged commands a remotely (access groups for privileged accounts).
|-
| [d] access to the identified security-relevant information via remote access is authorized. || Artifact || Screen share that shows the routing of remote access and how it is monitored and how many locations (Firewall, VPN Concentrator).
|}

=== AC.L2-3.1.16 – Wireless Access Authorization ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.16_Details|'''AC.L2-3.1.16''']] Authorize wireless access prior to allowing such connections.
|-
| [a] wireless access points are identified. || Document || SSP, network administration document.
|-
| [b] wireless access is authorized prior to allowing such connections. || Screen Share || Authorization profile(s) in Wireless Access Controller or Identity Manager (i.e. Cisco ISE).
|}

=== AC.L2-3.1.17 – Wireless Access Protection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.17_Details|'''AC.L2-3.1.17''']] Protect wireless access using authentication and encryption.
|-
| [a] wireless access to the system is protected using authentication. || Screen Share || Security page (or similar) of a Wireless Access Controller.
|-
| [b] wireless access to the system is protected using encryption. || Screen Share || Security page (or similar) of a Wireless Access Controller.
|}

=== AC.L2-3.1.18 – Mobile Device Connection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.18_Details|'''AC.L2-3.1.18''']] Control connection of mobile devices.
|-
| [a] mobile devices that process, store, or transmit CUI are identified. || Document || SSP, Mobile Device Policy.
|-
| [b] mobile device connections are authorized. || Artifact || Authorization profile(s) in Wireless Access Controller or Identity Manager (i.e. Cisco ISE).
|-
| [c] mobile device connections are monitored and logged. || Screen Share || Mobile device logs within the MDM, log intake (sources) configuration (within SIEM) showing MDM is feeding logs to the SIEM.
|}

=== AC.L2-3.1.19 – Encrypt CUI on Mobile ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.19_Details|'''AC.L2-3.1.19''']] Encrypt CUI on mobile devices and mobile computing platforms.
|-
| [a] mobile devices and mobile computing platforms that process, store, or transmit CUI are identified. || Document || SSP, Mobile Device Policy.
|-
| [b] encryption is employed to protect CUI on identified mobile devices and mobile computing platforms. || Screen Share || Security policy page in MDM showing how encryption are enforced on mobile device. If no MDM or MDM doesn't enforce encryption, then validate if the devices used are on the list of devices with native FIPS approved validation.
|}

=== AC.L2-3.1.20 – External Connections [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.20_Details|'''AC.L2-3.1.20''']] Verify and control/limit connections to and use of external information systems.
|-
| [a] connections to external systems are identified. || Document || SSP, Systems Interconnection Agreements, SLA.
|-
| [b] the use of external systems is identified. || Document || SSP, Systems Interconnection Agreements, SLA.
|-
| [c] connections to external systems are verified. || Artifact || SLA for external systems, memorandum for interconnection, information to prove that any cloud solution is at FedRAMP impact level of moderate or higher (i.e. license information, screenshot of AWS cloud dashboard, purchase order document).
|-
| [d] the use of external systems is verified. || Artifact || SLA for external systems, memorandum for interconnection, information to prove that any cloud solution is at FedRAMP impact level of moderate or higher (i.e. license information, screenshot of AWS cloud dashboard, purchase order document).
|-
| [e] connections to external systems are controlled/limited. || Screen Share || Firewall ruleset for controlling access to cloud service or external system.
|-
| [f] the use of external systems is controlled/limited. || Screen Share || Firewall ruleset for controlling access to cloud service or external system.
|}

=== AC.L2-3.1.21 – Portable Storage Use ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.21_Details|'''AC.L2-3.1.21''']] Limit use of portable storage devices on external systems.
|-
| [a] the use of portable storage devices containing CUI on external systems is identified and documented. || Document || SSP, Removable Media Policy, Acceptable Use Policy (with emphasis on portable media use).
|-
| [b] limits on the use of portable storage devices containing CUI on external systems are defined. || Document || SSP, Removable Media Policy, Acceptable Use Policy (with emphasis on portable media use).
|-
| [c] the use of portable storage devices containing CUI on external systems is limited as defined. || Document || SSP, Removable Media Policy, Acceptable Use Policy (with emphasis on portable media use).
|}

=== AC.L2-3.1.22 – Control Public Information [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.22_Details|'''AC.L2-3.1.22''']] Control information posted or processed on publicly accessible information systems.
|-
| [a] individuals authorized to post or process information on publicly accessible systems are identified. || Document || SSP, Website Governance Plan, Information Release Document.
|-
| [b] procedures to ensure CUI is not posted or processed on publicly accessible systems are identified. || Document || SSP, Website Governance Plan, Information Release Document.
|-
| [c] a review process is in place prior to posting of any content to publicly accessible systems. || Artifact || "Information release approval process, i.e. chain of email communication from originator, approver, and final decision (may or may not include individual authorized to post);
SharePoint/electronic or paper form/ ticket system showing information flow between requestor and approver (may or may not include individual authorized to post)."
|-
| [d] content on publicly accessible systems is reviewed to ensure that it does not include CUI. || Artifact || Incident response process, web design/update/modification SOP etc.
|-
| [e] mechanisms are in place to remove and address improper posting of CUI. || Artifact || Incident response process, web design/update/modification SOP etc.
|}

== Awareness and Training (AT) ==
=== AT.L2-3.2.1 – Role-Based Risk Awareness ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AT.L2-3.2.1_Details|'''AT.L2-3.2.1''']] Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems.
|-
| [a] security risks associated with organizational activities involving CUI are identified. || Document || Policy of Security Awareness Training; Security Awareness Training Briefing.
|-
| [b] policies, standards, and procedures related to the security of the system are identified. || Document || Acceptable Use Policy, Policy/Procedures/Instruction related to the security of the system.
|-
| [c] managers, systems administrators, and users of the system are made aware of the security risks associated with their activities. || Artifact || Security Training Brief, training records.
|-
| [d] managers, systems administrators, and users of the system are made aware of the applicable policies, standards, and procedures related to the security of the system. || Artifact || Policies, standards and procedures for employees within training (completed training report).
|}

=== AT.L2-3.2.2 – Role-Based Training ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AT.L2-3.2.2_Details|'''AT.L2-3.2.2''']] Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities.|-
|-
| [a] information security-related duties, roles, and responsibilities are defined. || Document || Policy/Procedures/Instruction, Job Role Matrix, Position Descriptions, User Roles.
|-
| [b] information security-related duties, roles, and responsibilities are assigned to designated personnel. || Artifact || Screenshot of breakout of different roles/permissions assigned to individuals (i.e. ActiveDirectory); Privilege Access Agreement.
|-
| [c] personnel are adequately trained to carry out their assigned information security-related duties, roles, and responsibilities. || Artifact || Screenshot of tool and/or training specifying security specific roles, duties and responsibilities; Screenshot of required certifications (i.e. Sec+, CISSP).
|}

=== AT.L2-3.2.3 – Insider Threat Awareness ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AT.L2-3.2.3_Details|'''AT.L2-3.2.3''']] Provide security awareness training on recognizing and reporting potential indicators of insider threat.
|-
| [a] potential indicators associated with insider threats are identified. || Document || Insidert Threat Policy/Procedures/Instruction; Insider Threat Training/Briefing.
|-
| [b] security awareness training on recognizing and reporting potential indicators of insider threat is provided to managers and employees. || Artifact || Screenshot of training records showing completion of Insider Threat training, emails showing completion of Insider Threat training, Screenshot of certificate showing completion with individual's name.
|}

== Audit and Accountability (AU) ==
=== AU.L2-3.3.1 – System Auditing ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.1_Details|'''AU.L2-3.3.1''']] Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.
|-
| [a] audit logs needed (i.e., event types to be logged) to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity are specified. || Document || SSP, policy, or auditing and logging process that defines specific types of events to be logged.
|-
| [b] the content of audit records needed to support monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity is defined. || Document || SSP, policy, or auditing and logging process that defines specific content of audit records/files.
|-
| [c] audit records are created (generated). || Screen Share || Screen share of tool that shows logs are generated for all systems.
|-
| [d] audit records, once created, contain the defined content. || Screen Share || Screen share of tool that shows logs contain defined content as defined in SSP, policy, or procedures.
|-
| [e] retention requirements for audit records are defined. || Document || SSP, Polocy, or Auditing and logging process that describes how long records are kept.
|-
| [f] audit records are retained as defined. || Screen Share || Screen share of tool that shows records and audit content retained at a minimum as defined.
|}

=== AU.L2-3.3.2 – User Accountability ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.2_Details|'''AU.L2-3.3.2''']] Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions.
|-
| [a] the content of the audit records needed to support the ability to uniquely trace users to their actions is defined. || Document || SSP, policy, or process that defines actions traced back to individuals.
|-
| [b] audit records, once created, contain the defined content. || Screen Share || Screen share of tool that shows audit records traced to specific users/roles.
|}

=== AU.L2-3.3.3 – Event Review ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.3_Details|'''AU.L2-3.3.3''']] Review and update logged events.
|-
| [a] a process for determining when to review logged events is defined. || Document || SSP, policy, or documented process that shows frequency of when to review types of logged events.
|-
| [b] event types being logged are reviewed in accordance with the defined review process. || Artifact || Evidence through a documented method such as meeting minutes, CAB minutes, etc. of log sources and log events being logged at the defined frequency.
|-
| [c] event types being logged are updated based on the review. || Artifact || Evidence of implementation based on the results of the review of logged events/sources through a ticket, meeting minutes, or screen share of the tool that shows changes implemented (finetuning).
|}

=== AU.L2-3.3.4 – Audit Failure Alerting ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.4_Details|'''AU.L2-3.3.4''']] Alert in the event of an audit logging process failure.
|-
| [a] personnel or roles to be alerted in the event of an audit logging process failure are identified. || Document || SSP, policy, or procedure that shows who needs to be notified in case of an audit failure.
|-
| [b] types of audit logging process failures for which alert will be generated are defined. || Document || SSP, policy, or procedure that shows what types of failure will generate notifications.
|-
| [c] identified personnel or roles are alerted in the event of an audit logging process failure. || Artifact || Artifact such as email or ticket that shows the identified personnel were alerted of any audit/logging process failure as defined.
|}

=== AU.L2-3.3.5 – Audit Correlation ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.5_Details|'''AU.L2-3.3.5''']] Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.
|-
| [a] audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity are defined. || Document || SSP, policy, or procedure covering audit logging, monitoring, and reporting.
|-
| [b] defined audit record review, analysis, and reporting processes are correlated. || Artifact || Artifact showing an audit event and the resultant corrective action or actions to the event; this can be a Help Desk ticket, meeting notes, or a change control board items showing the event and any corrective action taken.
|}

=== AU.L2-3.3.6 – Reduction & Reporting ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.6_Details|'''AU.L2-3.3.6''']] Provide audit record reduction and report generation to support on-demand analysis and reporting.
|-
| [a] an audit record reduction capability that supports on-demand analysis is provided. || Screen Share || Screen share of the logging environment where an event can be selected and traced back to a specific device, or dashboard showing realtime event analysis.
|-
| [b] a report generation capability that supports on-demand reporting is provided. || Screen Share || Screen share showing the generation of an on demand report.
|}

=== AU.L2-3.3.7 – Authoritative Time Source ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.7_Details|'''AU.L2-3.3.7''']] Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.
|-
| [a] internal system clocks are used to generate time stamps for audit records. || Screen Share || Screen share showing the NTP settings of a windows, Unix, Linux device; a screen share showing the NTP settings of network appliances.
|-
| [b] an authoritative source with which to compare and synchronize internal system clocks is specified. || Document || SSP or policy indicating that devices need to be synched to a local authoritative time device that is synched with an authoritative time service.
|-
| [c] internal system clocks used to generate time stamps for audit records are compared to and synchronized with the specified authoritative time source. || Screen Share || Screen share showing device logging appliance time is point to the appropriate authoritative time server.
|}

=== AU.L2-3.3.8 – Audit Protection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.8_Details|'''AU.L2-3.3.8''']] Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
|-
| [a] audit information is protected from unauthorized access. || Screen Share || Screen share showing operating system permissions on the audit folders being restricted to appropriate users.
|-
| [b] audit information is protected from unauthorized modification. || Screen Share || Screen share showing operating system permissions on the audit folders being restricted to appropriate users.
|-
| [c] audit information is protected from unauthorized deletion. || Screen Share || Screen share showing operating system permissions on the audit folders being restricted to appropriate users.
|-
| [d] audit logging tools are protected from unauthorized access. || Screen Share || Artifact showing access permissions in the SIEM tool.
|-
| [e] audit logging tools are protected from unauthorized modification. || Screen Share || Artifact showing update permissions in the SIEM tool.
|-
| [f] audit logging tools are protected from unauthorized deletion. || Screen Share || Artifact showing delete permissions in the SIEM tool.
|}

=== AU.L2-3.3.9 – Audit Management ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.9_Details|'''AU.L2-3.3.9''']] Limit management of audit logging functionality to a subset of privileged users.
|-
| [a] a subset of privileged users granted access to manage audit logging functionality is defined. || Document || SSP or policy indicating which users or groups have access to audit logs.
|-
| [b] management of audit logging functionality is limited to the defined subset of privileged users. || Screen Share || Artifact showing SIEM or OS folder permissions (this should be limited to the assigned users or groups); artifact showing an ACL setting in SIEM tool in regards to logs.
|}

== Configuration Management (CM) ==
=== CM.L2-3.4.1 – System Baselining ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.1_Details|'''CM.L2-3.4.1''']] Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.
|-
| [a] a baseline configuration is established. || Document || Documentation showing or explaining standard imaging process (how standard images are deployed and where they are stored).
|-
| [b] the baseline configuration includes hardware, software, firmware, and documentation. || Artifact || Screenshot of repository of where images are maintained and information relating to hardware, software, and firmware.
|-
| [c] the baseline configuration is maintained (reviewed and updated) throughout the system development life cycle. || Artifact || Screenshot/evidence displaying management of baseline configurations (how often they are being managed as stated).
|-
| [d] a system inventory is established. || Document || Screenshot/evidence displaying inventory listing of approved products for use.
|-
| [e] the system inventory includes hardware, software, firmware, and documentation. || Artifact || Screeenshot/evidence displaying inventory listing of approved products and versions permitted for use.
|-
| [f] the inventory is maintained (reviewed and updated) throughout the system development life cycle. || Artifact || Screeenshot/evidence displaying management of baseline configurations (How often and are they being managed as stated.
|}

=== CM.L2-3.4.2 – Security Configuration Enforcement ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.2_Details|'''CM.L2-3.4.2''']] Establish and enforce security configuration settings for information technology products employed in organizational systems.
|-
| [a] security configuration settings for information technology products employed in the system are established and included in the baseline configuration. || Document || Documentation explaining methodology used by organization to create secure baselines (STIGs, benchmarks).
|-
| [b] security configuration settings for information technology products employed in the system are enforced. || Artifact || Evidence of tool/s used to enforce security configurations to ensure images used are free from modification unless authorized.
|}

=== CM.L2-3.4.3 – System Change Management ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.3_Details|'''CM.L2-3.4.3''']] Track, review, approve or disapprove, and log changes to organizational systems.
|-
| [a] changes to the system are tracked. || Artifact || Evidence of IT Service Management tool / process used to track system changes.
|-
| [b] changes to the system are reviewed. || Artifact || Evidence of IT Service Management tool / process used to review system changes.
|-
| [c] changes to the system are approved or disapproved. || Artifact || Evidence of IT Service Management tool / process used to approve/disapprove system changes.
|-
| [d] changes to the system are logged. || Artifact || Evidence of IT Service Management tool / process used to log system changes.
|}

=== CM.L2-3.4.4 – Security Impact Analysis ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.4_Details|'''CM.L2-3.4.4''']] Analyze the security impact of changes prior to implementation.
|-
| [a] the security impact of changes to the system is analyzed prior to implementation. || Artifact || Document explaining that security impact analysis of proposed changes to a system is conducted prior to implementation.
|}

=== CM.L2-3.4.5 – Access Restrictions for Change ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.5_Details|'''CM.L2-3.4.5''']] Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.
|-
| [a] physical access restrictions associated with changes to the system are defined. || Document || Document explaining the process of how physical access restrictions are defined for an individuals ability to make system changes.
|-
| [b] physical access restrictions associated with changes to the system are documented. || Document || Document explaining the process of how physical access restrictions are defined for an individuals ability to make system changes are documented; access request process.
|-
| [c] physical access restrictions associated with changes to the system are approved. || Artifact || Evidence of process of how physical access to systems are granted (i.e. physical access request sample).
|-
| [d] physical access restrictions associated with changes to the system are enforced. || Physical Review || Evidence of process of how physical access to systems are enforced (physical access system).
|-
| [e] logical access restrictions associated with changes to the system are defined. || Document || Document explaining the process of how logical access restrictions are defined for an individual's ability to make system changes.
|-
| [f] logical access restrictions associated with changes to the system are documented. || Document || Document explaining the process of how logical access restrictions are defined for an individual's ability to make system changes are documented.
|-
| [g] logical access restrictions associated with changes to the system are approved. || Artifact || Evidence of process of how logical access to systems are granted.
|-
| [h] logical access restrictions associated with changes to the system are enforced. || Artifact || Evidence of process of how logical access to systems are enforced.
|}

=== CM.L2-3.4.6 – Least Functionality ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.6_Details|'''CM.L2-3.4.6''']] Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.
|-
| [a] essential system capabilities are defined based on the principle of least functionality. || Document || Documentation explaining how systems are configured to utilize the principle of least functionality for designated users.
|-
| [b] the system is configured to provide only the defined essential capabilities. || Screen Share || Evidence displaying how systems are configured to utilize the principle of least functionality for designated users; disabled service settings, accepted standards for hardening (CIS benchmarks, etc.).
|}

=== CM.L2-3.4.7 – Nonessential Functionality ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.7_Details|'''CM.L2-3.4.7''']] Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.
|-
| [a] essential programs are defined. || Document || Documented essential programs specified; build documents; software center; SSP.
|-
| [b] the use of nonessential programs is defined. || Document || Documented listing of nonessential programs (whatever is NOT specified in [a]); AUP/User Agreement may identify nonessential use/programs.
|-
| [c] the use of nonessential programs is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict nonessential programs displays restrictions as defined (McAfee ePO settings, Carbon Black rules, etc.).
|-
| [d] essential functions are defined. || Document || Documented essential functions are specified.
|-
| [e] the use of nonessential functions is defined. || Document || Documented nonessential functions are specified.
|-
| [f] the use of nonessential functions is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict essential/nonessential functions displays restrictions as defined.
|-
| [g] essential ports are defined. || Document || Documented essential ports are specified.
|-
| [h] the use of nonessential ports is defined. || Document || Documented nonessential ports functions are specified.
|-
| [i] the use of nonessential ports is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict essential/nonessential ports displays restrictions as defined (FW rules; McAfee; GPO, etc.).
|-
| [j] essential protocols are defined. || Document || Documented essential protocols are specified.
|-
| [k] the use of nonessential protocols is defined. || Document || Documented nonessential protocols functions are specified.
|-
| [l] the use of nonessential protocols is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict essential/nonessential protocols displays restrictions as defined (FW rules; GPO, etc.).
|-
| [m] essential services are defined. || Document || Documented essential services specified.
|-
| [n] the use of nonessential services is defined. || Document || Documented nonessential services functions are specified.
|-
| [o] the use of nonessential services is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict essential/nonessential services displays restrictions as defined.
|}

=== CM.L2-3.4.8 – Application Execution Policy ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.8_Details|'''CM.L2-3.4.8''']] Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.
|-
| [a] a policy specifying whether whitelisting or blacklisting is to be implemented is specified. || Document || Documentation explaining whitelisting or blacklisting process.
|-
| [b] the software allowed to execute under whitelisting or denied use under blacklisting is specified. || Document || Documentation explaining whitelisting or blacklisting process for software.
|-
| [c] whitelisting to allow the execution of authorized software or blacklisting to prevent the use of unauthorized software is implemented as specified. || Screen Share || Tool used for whitelisting or blacklisting for software shows capability of restricting/authorizing software (Carbon Black dashboard, "SW Store", web proxies, DNS Blackhole, etc.).
|}

=== CM.L2-3.4.9 – User-Installed Software ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.9_Details|'''CM.L2-3.4.9''']] Control and monitor user-installed software.
|-
| [a] a policy for controlling the installation of software by users is established. || Document || Documented software authorization process or methodology for approval.
|-
| [b] installation of software by users is controlled based on the established policy. || Screen Share || Evidence that approval/restriction in installation of software by authorized personnel is implemented as specified (AUP, GPO, etc.).
|-
| [c] installation of software by users is monitored. || Screen Share || Evidence that installation of software by authorized personnel is monitored (SCCM groups, SW Center, etc.).
|}

== Identification and Authentication (IA) ==
=== IA.L2-3.5.1 – Identification [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.1_Details|'''IA.L2-3.5.1''']] Identify information system users, processes acting on behalf of users, or devices.
|-
| [a] system users are identified. || Document || Based on what is defined in their documentation (SSP, AUP, Policy, SOP), request to see a sample of non-privileged/privileged users in AD OU group (overlaps with 3.1.1 and 3.1.5).
|-
| [b] processes acting on behalf of users are identified. || Document || Based on what is defined in their documentation (SSP, AUP, Policy, SOP), request to see a sample of service accounts in AD OU group (overlaps with 3.1.1 and 3.1.5).
|-
| [c] devices accessing the system are identified. || Document || Based on what is defined in their documentation (SSP, AUP, Policy, SOP), request to see a sample of domain-joined workstation & servers in AD OU group (overlaps with 3.1.1 and 3.1.5). For network devices, request screen share/artifact to show how they are identified on the enterprise network.
|}

=== IA.L2-3.5.2 – Authentication [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.2_Details|'''IA.L2-3.5.2''']] Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems.
|-
| [a] the identity of each user is authenticated or verified as a prerequisite to system access. || Screen Share || If the user logs in with non-privileged account during other demoes and then a privileged account, then this should be satisfied. If screen share is unavailable, request logs to show successful and unsuccessful login by privileged and non-privilged users.
|-
| [b] the identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access. || Screen Share || Request a log that shows successful/unsuccessful service account trying to log on to company's asset.
|-
| [c] the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access. || Screen Share || Request a log that shows domain-joined workstation/server authenticating to AD (focus on the MAC/IP address/hostname).
|}

=== IA.L2-3.5.3 – Multifactor Authentication ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.3_Details|'''IA.L2-3.5.3''']] Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
|-
| [a] privileged accounts are identified. || Document || Based on what is defined in their documentation, request to see a sample of privileged users in AD OU group. Overlaps with 3.1.5. Screenshot/screen share to show implementation is enforced.
|-
| [b] multifactor authentication is implemented for local access to privileged accounts. || Screen Share || SSP, AUP, Policy, SOP that defines that MFA is needed for privileged local access.
|-
| [c] multifactor authentication is implemented for network access to privileged accounts. || Screen Share || Within the MFA implementation mechanism, show that privileged users are forced to use MFA; Screenshot/Screen share to show implementation is enforced.
|-
| [d] multifactor authentication is implemented for network access to non-privileged accounts. || Screen Share || Within the MFA implementation mechanism, show that non-privileged users are forced to use MFA; Screenshot/Screen share to show implementation is enforced.
|}

=== IA.L2-3.5.4 – Replay-Resistant Authentication ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.4_Details|'''IA.L2-3.5.4''']] Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.
|-
| [a] replay-resistant authentication mechanisms are implemented for network account access to privileged and non-privileged accounts. || Screen Share || Show the GPO setting that enforces Kerberos within AD. If MFA is used, show the implementation to enforce replay resistant techniques. For non-windows, show the technical solution to enforce replay resistant attacks.
|}

=== IA.L2-3.5.5 – Identifier Reuse ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.5_Details|'''IA.L2-3.5.5''']] Prevent reuse of identifiers for a defined period.
|-
| [a] a period within which identifiers cannot be reused is defined. || Document || SSP, policies, or SOP that defines identifier reuse.
|-
| [b] reuse of identifiers is prevented within the defined period. || Artifact || Show the GPO setting/technical solution that enforces what is defined in policy/documentation (this can be automated or manual process; screen share/artifacts can be presented to satisfy this requirement.
|}

=== IA.L2-3.5.6 – Identifier Handling ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.6_Details|'''IA.L2-3.5.6''']] Disable identifiers after a defined period of inactivity.
|-
| [a] a period of inactivity after which an identifier is disabled is defined. || Document || SSP, policy that defines the period of inactivity after which an identifier is disabled.
|-
| [b] identifiers are disabled after the defined period of inactivity. || Artifact || Screen share AD or similar tool supporting directory-based identity-related services for disabled accounts (can be done by hand or script).
|}

=== IA.L2-3.5.7 – Password Complexity ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.7_Details|'''IA.L2-3.5.7''']] Enforce a minimum password complexity and change of characters when new passwords are created.
|-
| [a] password complexity requirements are defined. || Document || SSP, policy that defines password complexity requirements.
|-
| [b] password change of character requirements are defined. || Document || SSP, policy that defines change of character requirements are defined.
|-
| [c] minimum password complexity requirements as defined are enforced when new passwords are created. || Screen Share || Screen share of AD or similar directory-based identity-related service tool to show complexity requirements.
|-
| [d] minimum password change of character requirements as defined are enforced when new passwords are created. || Screen Share || Screen share of Group Policy configuration or similar tool providing centralized management and configuration of operating systems, applications, and users' settings to show that characters must be changed.
|}

=== IA.L2-3.5.8 – Password Reuse ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.8_Details|'''IA.L2-3.5.8''']] Prohibit password reuse for a specified number of generations.
|-
| [a] the number of generations during which a password cannot be reused is specified. || Document || SSP, policy that specifies the number of generations during which a password cannot be reused is specified.
|-
| [b] reuse of passwords is prohibited during the specified number of generations. || Screen Share || Screen share Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration to show reuse of passwords is prohibited.
|}

=== IA.L2-3.5.9 – Temporary Passwords ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.9_Details|'''IA.L2-3.5.9''']] Allow temporary password use for system logons with an immediate change to a permanent password.
|-
| [a] an immediate change to a permanent password is required when a temporary password is used for system logon. || Screen Share || Screen share of Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration to show "change password at first logon."
|}

=== IA.L2-3.5.10 – Cryptographically-Protected Passwords ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.1_Details|'''IA.L2-3.5.1''']] Store and transmit only cryptographically-protected passwords.
|-
| [a] passwords are cryptographically protected in storage. || Screen Share || Screen share Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration that Kerberos, or a similar network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner, is enabled.
|-
| [b] passwords are cryptographically protected in transit. || Screen Share || Screen share Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration that Kerberos, or a similar network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner, is enabled.
|}

=== IA.L2-3.5.11 – Obscure Feedback ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.10_Details|'''IA.L2-3.5.10''']] Obscure feedback of authentication information.
|-
| [a] authentication information is obscured during the authentication process. || Screen Share || Screen share of Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration to show that passwords are obscured.
|}

== Incident Response (IR) ==
=== IR.L2-3.6.1 – Incident Handling ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IR.L2-3.6.1_Details|'''IR.L2-3.6.1''']] Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.
|-
| [a] an operational incident-handling capability is established. || Document || Incident Response SOP/Plan.
|-
| [b] the operational incident-handling capability includes preparation. || Document || Incident Response SOP/Plan, prior incident report, training, COOP plan.
|-
| [c] the operational incident-handling capability includes detection. || Document || Incident Response SOP/Plan; definition of tools used to detect; artifacts showing tools used; prior incident report.
|-
| [d] the operational incident-handling capability includes analysis. || Document || Incident Response SOP/Plan; Definition of tools used to analyze potential incidents; artifacts showing tools used for analysis; prior incident report.
|-
| [e] the operational incident-handling capability includes containment. || Document || Incident Response SOP/Plan; isolation/quarantine process; user training.
|-
| [f] the operational incident-handling capability includes recovery. || Document || Incident Response SOP/Plan; COOP Plan; prior incident reports, re-baselining impacted devices.
|-
| [g] the operational incident-handling capability includes user response. || Document || Incident Response SOP/Plan; user awareness training; Help Desk process.

|}

=== IR.L2-3.6.2 – Incident Reporting ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IR.L2-3.6.2_Details|'''IR.L2-3.6.2''']] Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.
|-
| [a] incidents are tracked. || Artifact || Incident Response SOP/Plan; ITSM artifact; technical implementation for incident tracking.
|-
| [b] incidents are documented. || Artifact || Incident Response SOP/Plan; ITSM artifact; technical implementation for incident tracking.
|-
| [c] authorities to whom incidents are to be reported are identified. || Document || Incident Response SOP/Plan.
|-
| [d] organizational officials to whom incidents are to be reported are identified. || Document || Incident Response SOP/Plan.
|-
| [e] identified authorities are notified of incidents. || Screen Share || Prior incident report; DIBNET login; prior email notifications.
|-
| [f] identified organizational officials are notified of incidents. || Artifact || Prior incident report; prior email notifications; tabletop exercises.
|}

=== IR.L2-3.6.3 – Incident Response Testing ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IR.L2-3.6.3_Details|'''IR.L2-3.6.3''']] Test the organizational incident response capability.
|-
| [a] the incident response capability is tested. || Artifact || Incident response table top/scheduled or unscheduled test or penetration test.
|}

== Maintenance (MA) ==
=== MA.L2-3.7.1 – Perform Maintenance ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.1_Details|'''MA.L2-3.7.1''']] Perform maintenance on organizational systems.
|-
| [a] system maintenance is performed. || Artifact || Establish typical maintenance activities (HVAC, UPS, power distribution, generators, copier maintenance) that are performed; maintenance agreements or contracts detailing these types of activities are acceptable; interview responses should be considered. This requirement should not be confused with 3.14.1 - report, remediate, and correct system flaws in a timely manner (patch management).
|}

=== MA.L2-3.7.2 – System Maintenance Control ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.2_Details|'''MA.L2-3.7.2''']] Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance.
|-
| [a] tools used to conduct system maintenance are controlled. || Artifact || Tools may largely depend on the assessed environment; discussion examples include network diagnostic and monitoring tools (including hardware and software); artifacts could demonstrate secured locations/areas for these tools (photos) or checkout sheets/rosters (documents) depicting responsible personnel and the dates/times of checkout.
|-
| [b] techniques used to conduct system maintenance are controlled. || Artifact || Processes for scheduling, performing, documenting, reviewing, approving, and monitoring maintenance and repairs for the information system.
|-
| [c] mechanisms used to conduct system maintenance are controlled. || Artifact || Processes for scheduling, performing, documenting, reviewing, approving, and monitoring maintenance and repairs for the information system.
|-
| [d] personnel used to conduct system maintenance are controlled. || Physical Review || Screenshot of who is authorized to conduct maintenance; maintenance personnel training program.
|}

=== MA.L2-3.7.3 – Equipment Sanitization ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.3_Details|'''MA.L2-3.7.3''']] Ensure equipment removed for off-site maintenance is sanitized of any CUI.
|-
| [a] equipment to be removed from organizational spaces for off-site maintenance is sanitized of any CUI. || Artifact || Document or artifact; record if equipment sanitized; categories of sanitization/destruction defined; sanitization procedural document.
|}

=== MA.L2-3.7.4 – Media Inspection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.4_Details|'''MA.L2-3.7.4''']] Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems.
|-
| [a] media containing diagnostic and test programs are checked for malicious code before being used in organizational systems that process, store, or transmit CUI. || Artifact || Screenshot of diagnostic/test program being used (such as Symantec and McAfee on access scans…).
|}

=== MA.L2-3.7.5 – Nonlocal Maintenance ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.5_Details|'''MA.L2-3.7.5''']] Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete.
|-
| [a] multifactor authentication is used to establish nonlocal maintenance sessions via external network connections. || Screen Share || Describe MFA used to remote from external service to organizational systems for maintenance and screenshot of MFA (3.5.3)(points associated with admin).
|-
| [b] nonlocal maintenance sessions established via external network connections are terminated when nonlocal maintenance is complete. || Screen Share || Screenshot VPN session timeout.
|}

=== MA.L2-3.7.6 – Maintenance Personnel ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.6_Details|'''MA.L2-3.7.6''']] Supervise the maintenance activities of maintenance personnel without required access authorization.
|-
| [a] maintenance personnel without required access authorization are supervised during maintenance activities. || Document || System maintenance policy; list of authorized personnel; maintenance records or, contracts/SLAs; WebEx.
|}

== Media Protection (MP) ==
=== MP.L2-3.8.1 – Media Protection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.1_Details|'''MP.L2-3.8.1''']] Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital.
|-
| [a] paper media containing CUI is physically controlled. || Document || Policy showing CUI paper media is controlled; artifact showing who has access; artifacts/records of inventories conducted; media check out procedures (i.e. file cabinets, encryption, password protection).
|-
| [b] digital media containing CUI is physically controlled. || Document || Policy showing CUI digital media is controlled; artifact showing who has access; artifacts/records of inventories conducted; media check out procedures (i.e. file cabinets, external drives, USBs, encryption, password protection).
|-
| [c] paper media containing CUI is securely stored. || Physical Review || Check out/sign out sheets; possible photo of storage container/video walk through of storage area; badge reader logs or access lists for keys for secured areas; interview response considered (i.e. file cabinets, encryption, password protection).
|-
| [d] digital media containing CUI is securely stored. || Physical Review || Check out/sign out sheets; possible photo of storage container/video walk through of storage area; badge reader logs or access lists for keys for secured areas; interview response considered (i.e. file cabinets, external drives, USBs, encryption, password protection).
|}

=== MP.L2-3.8.2 – Media Access ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.2_Details|'''MP.L2-3.8.2''']] Limit access to CUI on system media to authorized users.
|-
| [a] access to CUI on system media is limited to authorized users. || Artifact || Document describing how CUI is limited AND artifact showing principle of least access is implemented.
|}

=== MP.L2-3.8.3 – Media Disposal [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.3_Details|'''MP.L2-3.8.3''']] Sanitize or destroy information system media containing Federal Contract Information before disposal or release for reuse.
|-
| [a] system media containing CUI is sanitized or destroyed before disposal. || Document || Policy or artifact of media destruction logs; certificates of destruction; SLAs or contracts.
|-
| [b] system media containing CUI is sanitized before it is released for reuse. || Document || Policy or artifact describing method to sanitize, software used (i.e. DoD Wipe, ShredIT and Iron Mountain; Blancco; GDisk, DBAN).
|}

=== MP.L2-3.8.4 – Media Markings ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.4_Details|'''MP.L2-3.8.4''']] Mark media with necessary CUI markings and distribution limitations.
|-
| [a] media containing CUI is marked with applicable CUI markings. || Physical Review || Document or artifact showing CUI markings (i.e. labeling standards ).
|-
| [b] media containing CUI is marked with distribution limitations. || Physical Review || Document or artifact showing distro limitations (i.e. labeling standards ).
|}

=== MP.L2-3.8.5 – Media Accountability ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.5_Details|'''MP.L2-3.8.5''']] Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas.
|-
| [a] access to media containing CUI is controlled. || Document || Policy, artifact of audit logs showing tracking, Access Control Lists, records of transport activities (i.e. USB drives, CDs, chain of custody.
|-
| [b] accountability for media containing CUI is maintained during transport outside of controlled areas. || Artifact || Artifact of audit logs showing tracking, Access Control Lists, records of transport activities (i.e. USB drives, CDs; chain of custody.
|}

=== MP.L2-3.8.6 – Portable Storage Encryption ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.6_Details|'''MP.L2-3.8.6''']] Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards.
|-
| [a] the confidentiality of CUI stored on digital media is protected during transport using cryptographic mechanisms or alternative physical safeguards. || Artifact || Artifact showing crypto mechanisms used to protect (are they FIPS 140-2 [13.11]); artifact showing what alternative physical safeguards are in place (i.e. encryption; BitLocker; McAfee ).
|}

=== MP.L2-3.8.7 – Removable Media ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.7_Details|'''MP.L2-3.8.7''']] Control the use of removable media on system components.
|-
| [a] the use of removable media on system components is controlled. || Artifact || Policy showing if removable media is allowed; writable removable media is restricted; tracking artifacts; what tools are used (i.e. Carbon Black, Crowd Strike, GPO, Zoho Desktop Central); procedure/process describing what happens if it is lost; what mechanisms are in place to control/restrict removable media (i.e. Active Directory Groups and Group Policy artifact showing restriction).
|}

=== MP.L2-3.8.8 – Shared Media ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.8_Details|'''MP.L2-3.8.8''']] Prohibit the use of portable storage devices when such devices have no identifiable owner.ASSESSMENT OBJECTIVES'''
|-
| [a] the use of portable storage devices is prohibited when such devices have no identifiable owner. || Artifact || Policy and/or artifact showing company stance on portable storage devices if there is no owner (are personal USB devices allowed or are they company-issued; artifact showing alerts if device is connected to network (i.e. external HDD, Carbon Black, Crowd Strike, GPO, Zoho Desktop Central.
|}

=== MP.L2-3.8.9 – Protect Backups ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.9_Details|'''MP.L2-3.8.9''']] Protect the confidentiality of backup CUI at storage locations.
|-
| [a] the confidentiality of backup CUI is protected at storage locations. || Artifact || Policy on system backups; artifact showing media labeling; artifact showing encyption (is it FIPS 140-2 [13.11]); Access Control List artifact (i.e. backup tapes, Tivoli Storage Manager).
|}

== Personnel Security (PS) ==
=== PS.L2-3.9.1 – Screen Individuals ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PS.L2-3.9.1_Details|'''PS.L2-3.9.1''']] Screen individuals prior to authorizing access to organizational systems containing CUI.
|-
| [a] individuals are screened prior to authorizing access to organizational systems containing CUI. || Artifact || Screenshot of records of screened personnel/background checks.
|}

=== PS.L2-3.9.2 – Personnel Actions ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PS.L2-3.9.2_Details|'''PS.L2-3.9.2''']] Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers.
|-
| [a] a policy and/or process for terminating system access and any credentials coincident with personnel actions is established. || Document || Personnel security policy/procedures/instruction; Access control policy/procedure/instruction.
|-
| [b] system access and credentials are terminated consistent with personnel actions such as termination or transfer. || Artifact || Screenshot of records of personnel transfer and termination actions.
|-
| [c] the system is protected during and after personnel transfer actions. || Artifact || Completed outprocessing checklist.
|}

== Physical Protection (PE) ==
=== PE.L2-3.10.1 – Limit Physical Access [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.1_Details|'''PE.L2-3.10.1''']] Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals.
|-
| [a] authorized individuals allowed physical access are identified. || Artifact || Authorized personnel (names) access list.
|-
| [b] physical access to organizational systems is limited to authorized individuals. || Physical Review || Badge reader logs, audit logs, and/or card swipe test.
|-
| [c] physical access to equipment is limited to authorized individuals. || Physical Review || Badge reader logs, audit logs, and/or card swipe test.
|-
| [d] physical access to operating environments is limited to authorized. || Physical Review || Badge reader logs, audit logs, and/or card swipe test.
|}

=== PE.L2-3.10.2 – Monitor Facility ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.2_Details|'''PE.L2-3.10.2''']] Protect and monitor the physical facility and support infrastructure for organizational systems.
|-
| [a] the physical facility where organizational systems reside is protected. || Physical Review || Physical security measures and barriers into the physical facility (cameras/locks/gates/guards, etc.).
|-
| [b] the support infrastructure for organizational systems is protected. || Physical Review || Physical barriers to entries into computer spaces, server rooms, etc.
|-
| [c] the physical facility where organizational systems reside is monitored. || Physical Review || Audit logs/how the physical facility is being monitored (cameras/access system/guards, etc.).
|-
| [d] the support infrastructure for organizational systems is monitored. || Physical Review || Audit logs/how the physical facility is being monitored (cameras/access system/guards, etc.).
|}

=== PE.L2-3.10.3 – Escort Visitors [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.3_Details|'''PE.L2-3.10.3''']] Escort visitors and monitor visitor activity.
|-
| [a] visitors are escorted. || Physical Review || Policy/procedures/instruction on methodology for handling non-authorized personnel (entry to exit).
|-
| [b] visitor activity is monitored. || Physical Review || Policy/procedures/instructio on methodology for handling non-authorized personnel (entry to exit).
|}

=== PE.L2-3.10.4 – Physical Access Logs [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.4_Details|'''PE.L2-3.10.4''']] Maintain audit logs of physical access.
|-
| [a] audit logs of physical access are maintained. || Artifact || Log or report from badging system.
|}

=== PE.L2-3.10.5 – Manage Physical Access [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.5_Details|'''PE.L2-3.10.5''']] Control and manage physical access devices.
|-
| [a] physical access devices are identified. || Document || Physical access control systems description, guard force contract/policy, key locks, logical systems specifications, etc.
|-
| [b] physical access devices are controlled. || Physical Review || Inventory records of physical access control devices (e.g. keys, locks, card readers, locks, etc.).
|-
| [c] physical access devices are managed. || Physical Review || List of security safeguards controlling access to the facility (e.g. cameras, monitoring by guards, isolation of IT systems equiment and or system components).
|}

=== PE.L2-3.10.6 – Alternative Work Sites ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.6_Details|'''PE.L2-3.10.6''']] Enforce safeguarding measures for CUI at alternate work sites.
|-
| [a] safeguarding measures for CUI are defined for alternate work sites. || Document || Telework agreement, Acceptable Use Policy and SOP for alternate work locations; user security training validation which includes physical/logical/technical protections of system at alternate work sites.
|-
| [b] safeguarding measures for CUI are enforced for alternate work sites. || Artifact || Monitoring/audit log of user activity and logical/physical/technical mechanisms in place to preclude unauthorized activity (telework agreement , AUP?).
|}

== Risk Assessment (RA) ==
=== RA.L2-3.11.1 – Risk Assessments ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_RA.L2-3.11.1_Details|'''RA.L2-3.11.1''']] Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI.
|-
| [a] the frequency to assess risk to organizational operations, organizational assets, and individuals is defined. || Document || Risk assessment policy.
|-
| [b] risk to organizational operations, organizational assets, and individuals resulting from the operation of an organizational system that processes, stores, or transmits CUI is assessed with the defined frequency. || Artifact || Copy of last risk assessment done within defined frequency.
|}

=== RA.L2-3.11.2 – Vulnerability Scan ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_RA.L2-3.11.2_Details|'''RA.L2-3.11.2''']] Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
|-
| [a] the frequency to scan for vulnerabilities in organizational systems and applications is defined. || Document || Policy/procedures/instruction addressing vulnerability scanning records.
|-
| [b] vulnerability scans are performed on organizational systems with the defined frequency. || Screen Share || System configuration settings of vulnerability scanning scheduling and vulnerability scan results of systems within defined frequency.
|-
| [c] vulnerability scans are performed on applications with the defined frequency. || Screen Share || System configuration settings of vulnerability scanning scheduling and vulnerability scan results of applications within defined frequency.
|-
| [d] vulnerability scans are performed on organizational systems when new vulnerabilities are identified. || Screen Share || View signatures in scanning tool/ad hoc scan performed as a result.
|-
| [e] vulnerability scans are performed on applications when new vulnerabilities are identified. || Screen Share || View signatures in scanning tool/ad hoc scan performed as a result.
|}

=== RA.L2-3.11.3 – Vulnerability Remediation ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_RA.L2-3.11.3_Details|'''RA.L2-3.11.3''']] Remediate vulnerabilities in accordance with risk assessments.
|-
| [a] vulnerabilities are identified. || Artifact || Scan results showing vulnerabilities identified.
|-
| [b] vulnerabilities are remediated in accordance with risk assessments. || Artifact || Screenshot/document of scan results of remediated vulnerabilities in accordance to risk assessments.
|}

== Security Assessment (CA) ==
=== CA.L2-3.12.1 – Security Control Assessment ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CA.L2-3.12.1_Details|'''CA.L2-3.12.1''']] Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.
|-
| [a] the frequency of security control assessments is defined. || Document || SSP.
|-
| [b] security controls are assessed with the defined frequency to determine if the controls are effective in their application. || Artifact || Copy of last security control assessment done within defined frequency.
|}

=== CA.L2-3.12.2 – Operational Plan of Action ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CA.L2-3.12.2_Details|'''CA.L2-3.12.2''']] Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.
|-
| [a] deficiencies and vulnerabilities to be addressed by the plan of action are identified. || Artifact || Plan of Action (POA).
|-
| [b] a plan of action is developed to correct identified deficiencies and reduce or eliminate identified vulnerabilities. || Artifact || Plan of Action (POA).
|-
| [c] the plan of action is implemented to correct identified deficiencies and reduce or eliminate identified vulnerabilities. || Artifact || Plan of Action (POA)/previously completed POAs.
|}

=== CA.L2-3.12.3 – Security Control Monitoring ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CA.L2-3.12.3_Details|'''CA.L2-3.12.3''']] Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.
|-
| [a] security controls are monitored on an ongoing basis to ensure the continued effectiveness of those controls. || Artifact || Collection of risk assessment results, internal or third-party audits/security assessments and/or continuous monitoring reports/alerts (SIEM tool, etc.).
|}

=== CA.L2-3.12.4 – System Security Plan ====
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CA.L2-3.12.4_Details|'''CA.L2-3.12.4''']] Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.
|-
| [a] a system security plan is developed. || Document || SSP.
|-
| [b] the system boundary is described and documented in the system security plan. || Document || SSP and any supporting documentation.
|-
| [c] the system environment of operation is described and documented in the system security plan. || Document || SSP and any supporting documentation.
|-
| [d] the security requirements identified and approved by the designated authority as non-applicable are identified. || Document || SSP and required adjudication from DoD CIO.
|-
| [e] the method of security requirement implementation is described and documented in the system security plan. || Document || SSP and any supporting documentation.
|-
| [f] the relationship with or connection to other systems is described and documented in the system security plan. || Document || SSP and any supporting documentation.
|-
| [g] the frequency to update the system security plan is defined. || Document || SSP.
|-
| [h] system security plan is updated with the defined frequency. || Document || SSP/any previous versions.
|}

== System and Communications Protection (SC) ==
=== SC.L2-3.13.1 – Boundary Protection [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.1_Details|'''SC.L2-3.13.1''']] Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems.
|-
| [a] the external system boundary is defined. || Document || SSP, network diagrams, CUI flow, cloud provider FedRAMP Moderate.
|-
| [b] key internal system boundaries are defined. || Document || SSP, network diagrams, CUI flow.
|-
| [c] communications are monitored at the external system boundary. || Screen Share || SSP, logging server, boundary device configurations, monitoring policy.
|-
| [d] communications are monitored at key internal boundaries. || Screen Share || SSP, logging server, boundary device configurations, monitoring policy.
|-
| [e] communications are controlled at the external system boundary. || Screen Share || SSP, boundary device configurations, ACL, subnets, DMZ.
|-
| [f] communications are controlled at key internal boundaries. || Screen Share || SSP, boundary device configurations, ACL, subnets.
|-
| [g] communications are protected at the external system boundary. || Screen Share || Configurations for IPS/IDS, email gateway, VLAN, proxy, firewall, malware protection, DNS, TSL.
|-
| [h] communications are protected at key internal boundaries. || Screen Share || Configurations for IPS/IDS, VLAN, firewall, malware protection, SSL.
|}

=== SC.L2-3.13.2 – Security Engineering ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.2_Details|'''SC.L2-3.13.2''']] Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.
|-
| [a] architectural designs that promote effective information security are identified. || Document || SSP, config management policy, network diagram, CCB minutes, enterprise architecture process.
|-
| [b] software development techniques that promote effective information security are identified. || Document || SSP, config management policy, SDLC, CCB minutes.
|-
| [c] systems engineering principles that promote effective information security are identified. || Document || SSP, config management policy, CCB minutes, security architecture engineering.
|-
| [d] identified architectural designs that promote effective information security are employed. || Artifact || CCB minutes, Network diagrams and configurations, Project Plans.
|-
| [e] identified software development techniques that promote effective information security are employed. || Artifact || CCB minutes, SDLC, code scanner results, code management tracking.
|-
| [f] identified systems engineering principles that promote effective information security are employed. || Artifact || CCB minutes, configuration management, ITSM, patch management, lifecycle replacement processes.
|}

=== SC.L2-3.13.3 – Role Separation ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.3_Details|'''SC.L2-3.13.3''']] Separate user functionality from system management functionality.
|-
| [a] user functionality is identified. || Document || SSP, AUP.
|-
| [b] system management functionality is identified. || Document || SSP, Privileged Account Agreement.
|-
| [c] user functionality is separated from system management functionality. || Screen Share || Active Directory, Jump Boxes, GPO, VM, RDP.
|}

=== SC.L2-3.13.4 – Shared Resource Control ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.4_Details|'''SC.L2-3.13.4''']] Prevent unauthorized and unintended information transfer via shared system resources.
|-
| [a] unauthorized and unintended information transfer via shared system resources is prevented. || Screen Share || SSP, OS configurations, Linux containers, system/media reuse policies, certificate management policies, media destruction policies, printer configs, VDI configuration.
|}

=== SC.L2-3.13.5 – Public-Access System Separation [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.5_Details|'''SC.L2-3.13.5''']] Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
|-
| [a] publicly accessible system components are identified. || Document || SSP, network diagram, DMZ inventory/roles.
|-
| [b] subnetworks for publicly accessible system components are physically or logically separated from internal networks. || Artifact || Network diagram, IPAM, VLAN, DHCP, DMZ.
|}

=== SC.L2-3.13.6 – Network Communication by Exception ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.6_Details|'''SC.L2-3.13.6''']] Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).
|-
| [a] network communications traffic is denied by default. || Screen Share || Host and network firewall rules, SIEM logs, hit counts.
|-
| [b] network communications traffic is allowed by exception. || Screen Share || Host and network firewall rules, SIEM logs, hit counts.
|}

=== SC.L2-3.13.7 – Split Tunneling ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.7_Details|'''SC.L2-3.13.7''']] Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling).
|-
| [a] remote devices are prevented from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks (i.e., split tunneling). || Screen Share || VPN appliance/server configuration, endpoint VPN software configuration.
|}

=== SC.L2-3.13.8 – Data in Transit ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.8_Details|'''SC.L2-3.13.8''']] Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.
|-
| [a] cryptographic mechanisms intended to prevent unauthorized disclosure of CUI are identified. || Document || SSP, PKI policies, configuration processes, config management, email attachment encryption policy, removable media policy, data at rest policy.
|-
| [b] alternative physical safeguards intended to prevent unauthorized disclosure of CUI are identified. || Document || SSP, physical security policy.
|-
| [c] either cryptographic mechanisms or alternative physical safeguards are implemented to prevent unauthorized disclosure of CUI during transmission. || Artifact || TLS settings, SSL settings, VPN/Wireless Access Points/Mobile Devices cryptographic settings, ODBC connector settings, SAN configuration, IPSec/MPLS, backup configuration, physical security.
|}

=== SC.L2-3.13.9 – Connections Termination ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.9_Details|'''SC.L2-3.13.9''']] Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity.
|-
| [a] a period of inactivity to terminate network connections associated with communications sessions is defined. || Document || SSP, network communications policy.
|-
| [b] network connections associated with communications sessions are terminated at the end of the sessions. || Screen Share || VPN appliance/server logs, VPN configurations, web server configurations, firewall connection settings.
|-
| [c] network connections associated with communications sessions are terminated after the defined period of inactivity. || Screen Share || VPN appliance/server logs, VPN configurations, web server configurations, frewall connection settings.
|}

=== SC.L2-3.13.10 – Key Management ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.10_Details|'''SC.L2-3.13.10''']] Establish and manage cryptographic keys for cryptography employed in organizational systems.
|-
| [a] cryptographic keys are established whenever cryptography is employed. || Artifact || SSP, PKI/certificate management policy, configuration management.
|-
| [b] cryptographic keys are managed whenever cryptography is employed. || Artifact || SSP, PKI/certificate management policy, configuration management, access control policy.
|}

=== SC.L2-3.13.11 – CUI Encryption ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.11_Details|'''SC.L2-3.13.11''']] Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.
|-
| [a] FIPS-validated cryptography is employed to protect the confidentiality of CUI. || Screen Share || VPN, wireless, mobile devices, client certificates, server certificates, disk encryption, Outlook plugin, external mail, backup media, ePO server, removable storage, SAN, file compression; look for FIPS mode enabled on appliances.
|}

=== SC.L2-3.13.12 – Collaborative Device Control ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.12_Details|'''SC.L2-3.13.12''']] Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device.
|-
| [a] collaborative computing devices are identified. || Document || SSP, network diagrams.
|-
| [b] collaborative computing devices provide indication to users of devices in use. || Physical Review || Physical inspection of device.
|-
| [c] remote activation of collaborative computing devices is prohibited. || Screen Share || Collaboration device configuration/console.
|}

=== SC.L2-3.13.13 – Mobile Code ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.13_Details|'''SC.L2-3.13.13''']] Control and monitor the use of mobile code.
|-
| [a] use of mobile code is controlled. || Screen Share || GPO settings, malware protection, software agent configurations, software development policies, code scanners, MDM configuration, firewall/secure web gateway/proxy config.
|-
| [b] use of mobile code is monitored. || Screen Share || SIEM/console monitoring.
|}

=== SC.L2-3.13.14 – Voice over Internet Protocol ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.14_Details|'''SC.L2-3.13.14''']] Control and monitor the use of Voice over Internet Protocol (VoIP) technologies.
|-
| [a] use of Voice over Internet Protocol (VoIP) technologies is controlled. || Artifact || VLAN, ACL, firewall config, VoIP gateway/condenser configuration.
|-
| [b] use of Voice over Internet Protocol (VoIP) technologies is monitored. || Artifact || SIEM/VoIP console monitoring, session border controller.
|}

=== SC.L2-3.13.15 – Communications Authenticity ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.15_Details|'''SC.L2-3.13.15''']] Protect the authenticity of communications sessions.
|-
| [a] the authenticity of communications sessions is protected. || Screen Share || SSL, TLS, SMB3, SFTP, IPSec, SSH, Kerberos configs, MPLS, Network Access Control.
|}

=== SC.L2-3.13.16 – Data at Rest ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.16_Details|'''SC.L2-3.13.16''']] Protect the confidentiality of CUI at rest.
|-
| [a] the confidentiality of CUI at rest is protected. || Artifact || Full disk encryption, removable media encryption, SAN encryption, digital backups, mobile device encryption, third party offsite backup storage, cloud virtualization encryption, physical media storage policies.
|}

== System and Information Integrity (SI) ==
=== SI.L2-3.14.1 – Flaw Remediation [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.1_Details|'''SI.L2-3.14.1''']] Identify, report, and correct information and information system flaws in a timely manner.
|-
| [a] the time within which to identify system flaws is specified. || Document || SSP, patch management policy.
|-
| [b] system flaws are identified within the specified time frame. || Screen Share || Vulnerability management scanner output and scan policy configuration.
|-
| [c] the time within which to report system flaws is specified. || Document || SSP, patch management policy.
|-
| [d] system flaws are reported within the specified time frame. || Screen Share || ITSM/trouble tickets, vulnerability management scanner output.
|-
| [e] the time within which to correct system flaws is specified. || Document || SSP, patch management policy.
|-
| [f] system flaws are corrected within the specified time frame. || Screen Share || Vulnerability management scanner output and scan policy configuration.
|}

=== SI.L2-3.14.2 – Malicious Code ProTection [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.2_Details|'''SI.L2-3.14.2''']] Provide protection from malicious code at appropriate locations within organizational information systems.
|-
| [a] designated locations for malicious code protection are identified. || Document || SSP, system protection policy, network diagrams, security architecture documents.
|-
| [b] protection from malicious code at designated locations is provided. || Screen Share || Endpoint security settings, email/web proxy gateways, firewall, IPS sensor, MDM configuration, Network Access Control.
|}

=== SI.L2-3.14.3 – Security Alerts & Advisories ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.3_Details|'''SI.L2-3.14.3''']] Monitor system security alerts and advisories and take action in response.
|-
| [a] response actions to system security alerts and advisories are identified. || Document || SSP, vulnerability management policy, Incident Response Plan.
|-
| [b] system security alerts and advisories are monitored. || Artifact || Threat intelligence subscriptions, email advisories.
|-
| [c] actions in response to system security alerts and advisories are taken. || Artifact || ITSM/trouble tickets, user notifications, updates to firewall/IPS, etc.
|}

=== SI.L2-3.14.4 – Update Malicious Code Protection [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.4_Details|'''SI.L2-3.14.4''']] Update malicious code protection mechanisms when new releases are available.
|-
| [a] malicious code protection mechanisms are updated when new releases are available. || Screen Share || Antivirus console dashboard, firewall AV, Email gateway signatures,proxy, IPS updates.
|}

=== SI.L2-3.14.5 – System & File Scanning [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.5_Details|'''SI.L2-3.14.5''']] Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed.
|-
| [a] the frequency for malicious code scans is defined. || Document || SSP, vulnerability management policy.
|-
| [b] malicious code scans are performed with the defined frequency. || Screen Share || Consoles for AV (endpoints, servers, and file shares), firewall, email gateway, proxy, IPS, MDM configurations.
|-
| [c] real-time malicious code scans of files from external sources as files are downloaded, opened, or executed are performed. || Screen Share || Consoles for AV (endpoints, servers, and file shares), firewall, email gateway, proxy, IPS, MDM configurations.
|}

=== SI.L2-3.14.6 – Monitor Communications for Attacks ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.6_Details|'''SI.L2-3.14.6''']] Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.
|-
| [a] the system is monitored to detect attacks and indicators of potential attacks. || Screen Share || Firewall, IPS, endpoint protection, SIEM alerts and reports.
|-
| [b] inbound communications traffic is monitored to detect attacks and indicators of potential attacks. || Screen Share || Firewall, IPS, endpoint protection, SIEM alerts and reports.
|-
| [c] outbound communications traffic is monitored to detect attacks and indicators of potential attacks. || Screen Share || Firewall, IPS, endpoint protection, SIEM alerts and reports.
|}

=== SI.L2-3.14.7 – Identify Unauthorized Use ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.7_Details|'''SI.L2-3.14.7''']] Identify unauthorized use of organizational systems.
|-
| [a] authorized use of the system is defined. || Document || AUP, SSP.
|-
| [b] unauthorized use of the system is identified. || Artifact || SIEM logs, endpoint protection console, IPS, Firewall.
|}

Evidence Collection Approach

2026-07-20T01:49:09Z

David: /* SC.L2-3.13.8 – Data in Transit */

CMMC assessments and certification require substantial evidence and documentation. The following tables outline general guidelines for collecting evidence to assess control requirements and objectives. While these guidelines provide a structured approach, they are not the only means of conducting an accurate assessment. Assessors should exercise professional judgment and may employ alternative methods appropriate to the specific organizational context and circumstances.

Evidence collection approaches are defined as:
* '''Documentation''': Tangible materials containing information over which an organization has authority, including all types of written records and their copies.
* '''Artifacts''': Tangible, reviewable records directly resulting from a practice or process being performed by a system or by personnel executing their role within that practice, control, or process.
* '''Physical Review''': Direct on-site observation and examination of evidence.
* '''Screen Share''': Real-time remote observation of a user demonstrating a task or process via shared computer screen, sometimes called "over-the-shoulder" review.

DISCLAIMER: Evidence requirements vary significantly across assessment types. '''The examples provided are illustrative only and should be tailored to meet the specific adequacy and sufficiency standards of your particular assessment context.'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmctoolkit.org contact us]. Thank you.

== Access Control (AC) ==
=== AC.L2-3.1.1 – Authorized Access Control [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.1_Details|'''AC.L2-3.1.1''']] Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems).
|-
| [a] authorized users are identified. || Document || Document defining account request, approval, provisioning.
|-
| [b] processes acting on behalf of authorized users are identified. || Document || Document defining account request, approval, provisioning.
|-
| [c] devices (and other systems) authorized to connect to the system are identified. || Document || Document defining account request, approval, provisioning.
|-
| [d] system access is limited to authorized users. || Screen Share || Screen share showing login requirements are enforced. Example of an unauthorized user denied (unauthorized username entered at login).
|-
| [e] system access is limited to processes acting on behalf of authorized users. || Screen Share || Screenshot showing that service accounts are assigned to authorized users only; no rogue accounts without an authorized user are active.
|-
| [f] system access is limited to authorized devices (including other systems). || Screen Share || Screen share showing that all devices running are authorized; no rogue devices on the network.
|}

=== AC.L2-3.1.2 – Transaction & Function Control [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.2_Details|'''AC.L2-3.1.2''']] Limit information system access to the types of transactions and functions that authorized users are permitted to execute.
|-
| [a] the types of transactions and functions that authorized users are permitted to execute are defined. || Document || SSP, AUP, or IAM document that defines what authorized users can execute.
|-
| [b] system access is limited to the defined types of transactions and functions for authorized users. || Screen Share || Screenshot of security roles in AD or IAM or other directory-based identity-related services tool that shows transactions are as defined in the SSP or IAM document; privileged and non-privileged accounts need to be defined and identified in the artifact; screenshot of a non-privileged user trying to execute a privileged function.
|}

=== AC.L2-3.1.3 – Control CUI Flow ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.3_Details|'''AC.L2-3.1.3''']] Control the flow of CUI in accordance with approved authorizations.
|-
| [a] information flow control policies are defined. || Document || SSP or other document describing the control of CUI on the network.
|-
| [b] methods and enforcement mechanisms for controlling the flow of CUI are defined. || Document || Document that defines the networking devices that are on the CUI network and answers what measures are in place to control the flow. List of firewalls, border and internal layer 3 devices, IDS/IPS, DLP, that process CUI.
|-
| [c] designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified. || Artifact || Network diagram, data flow diagram, external system connection diagrams, document describing the policies for CUI on the network; listing of VLANs and subnets where CUI is authorized; document must describe source and authorized destinations.
|-
| [d] authorizations for controlling the flow of CUI are defined. || Document || Document that defines how CUI is to be controlled, such as an InfoSec plan, and/or network management plan.
|-
| [e] approved authorizations for controlling the flow of CUI are enforced. || Screen Share || Screenshots of firewall rules, ACLs, etc.
|}

=== AC.L2-3.1.4 – Separation of Duties ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.4_Details|'''AC.L2-3.1.4''']] Separate the duties of individuals to reduce the risk of malevolent activity without collusion.
|-
| [a] the duties of individuals requiring separation are defined. || Document || Document, SSP, account management policy, defining separation of duties by person or role.
|-
| [b] responsibilities for duties that require separation are assigned to separate individuals. || Screen Share || Screenshot showing that separation of duties is enforced by showing admin accounts are assigned to different people based on role.
|-
| [c] access privileges that enable individuals to exercise the duties that require separation are granted to separate individuals. || Screen Share || Screen shot showing an example such as a security manager can not log into a network device and change ACLs, or network admins can not access security logs in the SIEM tool.
|}

=== AC.L2-3.1.5 – Least Privilege ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.5_Details|'''AC.L2-3.1.5''']] Employ the principle of least privilege, including for specific security functions and privileged accounts.
|-
| [a] privileged accounts are identified. || Document || "SSP or policy (documentation) identify what is considered a privileged account."
|-
| [b] access to privileged accounts is authorized in accordance with the principle of least privilege. || Artifact || An artifact that identifies the least amount of permissions associated with different types of privileged accounts are approved.
|-
| [c] security functions are identified. || Document || "SSP or policy (documentation) identifies what is considered a security account."
|-
| [d] access to security functions is authorized in accordance with the principle of least privilege. || Artifact || Artifact(s) that identify the least amount of permissions associated with different types of security accounts are approved.
|}

=== AC.L2-3.1.6 – Non-Privileged Account Use ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.6_Details|'''AC.L2-3.1.6''']] Use non-privileged accounts or roles when accessing nonsecurity functions.
|-
| [a] nonsecurity functions are identified. || Document || SSP or account management document, AUP, that defines non-security functions.
|-
| [b] users are required to use non-privileged accounts or roles when accessing nonsecurity functions. || Screen Share || Screenshot showing that a privileged user tried to use their admin account to access a non-security function, such as a browser or email (whatever is defined in their policy) and was blocked.
|}

=== AC.L2-3.1.7 – Privileged Functions ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.7_Details|'''AC.L2-3.1.7''']] Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.
|-
| [a] privileged functions are defined. || Document || SSP or policy (documentation) that defines privileged functions.
|-
| [b] non-privileged users are defined. || Document || SSP or policy (documentation) that defines non-privileged users.
|-
| [c] non-privileged users are prevented from executing privileged functions. || Screen Share || Screen share that shows that a non-privileged user is not allowed to complete a privileged function (installing software).
|-
| [d] the execution of privileged functions is captured in audit logs. || Screen Share || Screen share that shows logs being captured of the execution of privileged functions.
|}

=== AC.L2-3.1.8 – Unsuccessful Logon Attempts ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.8_Details|'''AC.L2-3.1.8''']] Limit unsuccessful logon attempts.
|-
| [a] the means of limiting unsuccessful logon attempts is defined. || Document || SSP or policy (documentation) showing unsuccessful logon attempts settings and or policy.
|-
| [b] the defined means of limiting unsuccessful logon attempts is implemented. || Artifact || Artifact showing GPO / Policy for limiting logon attempts.
|}

=== AC.L2-3.1.9 – Privacy & Security Notices ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.9_Details|'''AC.L2-3.1.9''']] Provide privacy and security notices consistent with applicable CUI rules.
|-
| [a] privacy and security notices required by CUI-specified rules are identified, consistent, and associated with the specific CUI category. || Document || SSP or policy (documentation) showing CUI-specified rules are identified, consistent, and associated with the specific CUI category.
|-
| [b] privacy and security notices are displayed. || Artifact || Artifact that shows a consent banner or screen that a user sees as they log in to the system.
|}

=== AC.L2-3.1.10 – Session Lock ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.10_Details|'''AC.L2-3.1.10''']] Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity.
|-
| [a] the period of inactivity after which the system initiates a session lock is defined. || Document || SSP or policy (documentation) that defines the period of inactivity and when a session lock is defined.
|-
| [b] access to the system and viewing of data is prevented by initiating a session lock after the defined period of inactivity. || Artifact || Artifact that shows the setting of session lock (GPO or system policy or similar solution addressing the controls supporting centralized management and configuration of operating systems, applications, and users' settings for the working environment of user accounts and computer accounts).
|-
| [c] previously visible information is concealed via a pattern-hiding display after the defined period of inactivity. || Document || Screenshot of GPO setting and configuration settings, or similar solution addressing the controls supporting centralized management and configuration of operating systems, applications, and users' settings for the working environment of user accounts and computer accounts.
|}

=== AC.L2-3.1.11 – Session Termination ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.11_Details|'''AC.L2-3.1.11''']] Terminate (automatically) a user session after a defined condition.
|-
| [a] conditions requiring a user session to terminate are defined. || Document || SSP or policy (documentation) that defines the conditions requiring a user session to be terminated.
|-
| [b] a user session is automatically terminated after any of the defined conditions. || Screen Share || Screen share showing GPO / VPN Settings that show when a session would be terminated (Idle time, max connection time).
|}

=== AC.L2-3.1.12 – Control Remote Access ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.12_Details|'''AC.L2-3.1.12''']] Monitor and control remote access sessions.
|-
| [a] remote access sessions are permitted. || Document || SSP or policy (documentation) that defines remote access sessions.
|-
| [b] the types of permitted remote access are identified. || Document || SSP or policy (documentation) that defines remote access is permitted.
|-
| [c] remote access sessions are controlled. || Screen Share || Screen share that shows how the remote access is controlled (access session, and or groups).
|-
| [d] remote access sessions are monitored. || Screen Share || Screen share that shows how remote sessions are monitored (logs).
|}

=== AC.L2-3.1.13 – Remote Access Confidentiality ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.13_Details|'''AC.L2-3.1.13''']] Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.
|-
| [a] cryptographic mechanisms to protect the confidentiality of remote access sessions are identified. || Document || SSP or policy (documentation) that discusses the CUI rules, consistent, and associated with the specific CUI category; FIPS Cert # of appliance or application.
|-
| [b] cryptographic mechanisms to protect the confidentiality of remote access sessions are implemented. || Screen Share || Screenshot of VPN concentration that shows encryption is on and enabled (point-to-point, etc.).
|}

=== AC.L2-3.1.14 – Remote Access Routing ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.14_Details|'''AC.L2-3.1.14''']] Route remote access via managed access control points.
|-
| [a] managed access control points are identified and implemented. || Screen Share || Screen share that shows access control points (groups and/or users).
|-
| [b] remote access is routed through managed network access control points. || Screen Share || Screen share that shows access control points and how they are managed.
|}

=== AC.L2-3.1.15 – Privileged Remote Access ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.15_Details|'''AC.L2-3.1.15''']] Authorize remote execution of privileged commands and remote access to security-relevant information.
|-
| [a] privileged commands authorized for remote execution are identified. || Document || SSP or policy (documentation) that defines what is authorized to be executed remotely and how that is handled.
|-
| [b] security-relevant information authorized to be accessed remotely is identified. || Document || SSP or policy (documentation) that defines what can be accessed remotely and what procedures are implemented to allow this (RDP, jump box).
|-
| [c] the execution of the identified privileged commands via remote access is authorized. || Artifact || Screen share that shows who has access to perform privileged commands a remotely (access groups for privileged accounts).
|-
| [d] access to the identified security-relevant information via remote access is authorized. || Artifact || Screen share that shows the routing of remote access and how it is monitored and how many locations (Firewall, VPN Concentrator).
|}

=== AC.L2-3.1.16 – Wireless Access Authorization ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.16_Details|'''AC.L2-3.1.16''']] Authorize wireless access prior to allowing such connections.
|-
| [a] wireless access points are identified. || Document || SSP, network administration document.
|-
| [b] wireless access is authorized prior to allowing such connections. || Screen Share || Authorization profile(s) in Wireless Access Controller or Identity Manager (i.e. Cisco ISE).
|}

=== AC.L2-3.1.17 – Wireless Access Protection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.17_Details|'''AC.L2-3.1.17''']] Protect wireless access using authentication and encryption.
|-
| [a] wireless access to the system is protected using authentication. || Screen Share || Security page (or similar) of a Wireless Access Controller.
|-
| [b] wireless access to the system is protected using encryption. || Screen Share || Security page (or similar) of a Wireless Access Controller.
|}

=== AC.L2-3.1.18 – Mobile Device Connection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.18_Details|'''AC.L2-3.1.18''']] Control connection of mobile devices.
|-
| [a] mobile devices that process, store, or transmit CUI are identified. || Document || SSP, Mobile Device Policy.
|-
| [b] mobile device connections are authorized. || Artifact || Authorization profile(s) in Wireless Access Controller or Identity Manager (i.e. Cisco ISE).
|-
| [c] mobile device connections are monitored and logged. || Screen Share || Mobile device logs within the MDM, log intake (sources) configuration (within SIEM) showing MDM is feeding logs to the SIEM.
|}

=== AC.L2-3.1.19 – Encrypt CUI on Mobile ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.19_Details|'''AC.L2-3.1.19''']] Encrypt CUI on mobile devices and mobile computing platforms.
|-
| [a] mobile devices and mobile computing platforms that process, store, or transmit CUI are identified. || Document || SSP, Mobile Device Policy.
|-
| [b] encryption is employed to protect CUI on identified mobile devices and mobile computing platforms. || Screen Share || Security policy page in MDM showing how encryption are enforced on mobile device. If no MDM or MDM doesn't enforce encryption, then validate if the devices used are on the list of devices with native FIPS approved validation.
|}

=== AC.L2-3.1.20 – External Connections [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.20_Details|'''AC.L2-3.1.20''']] Verify and control/limit connections to and use of external information systems.
|-
| [a] connections to external systems are identified. || Document || SSP, Systems Interconnection Agreements, SLA.
|-
| [b] the use of external systems is identified. || Document || SSP, Systems Interconnection Agreements, SLA.
|-
| [c] connections to external systems are verified. || Artifact || SLA for external systems, memorandum for interconnection, information to prove that any cloud solution is at FedRAMP impact level of moderate or higher (i.e. license information, screenshot of AWS cloud dashboard, purchase order document).
|-
| [d] the use of external systems is verified. || Artifact || SLA for external systems, memorandum for interconnection, information to prove that any cloud solution is at FedRAMP impact level of moderate or higher (i.e. license information, screenshot of AWS cloud dashboard, purchase order document).
|-
| [e] connections to external systems are controlled/limited. || Screen Share || Firewall ruleset for controlling access to cloud service or external system.
|-
| [f] the use of external systems is controlled/limited. || Screen Share || Firewall ruleset for controlling access to cloud service or external system.
|}

=== AC.L2-3.1.21 – Portable Storage Use ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.21_Details|'''AC.L2-3.1.21''']] Limit use of portable storage devices on external systems.
|-
| [a] the use of portable storage devices containing CUI on external systems is identified and documented. || Document || SSP, Removable Media Policy, Acceptable Use Policy (with emphasis on portable media use).
|-
| [b] limits on the use of portable storage devices containing CUI on external systems are defined. || Document || SSP, Removable Media Policy, Acceptable Use Policy (with emphasis on portable media use).
|-
| [c] the use of portable storage devices containing CUI on external systems is limited as defined. || Document || SSP, Removable Media Policy, Acceptable Use Policy (with emphasis on portable media use).
|}

=== AC.L2-3.1.22 – Control Public Information [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.22_Details|'''AC.L2-3.1.22''']] Control information posted or processed on publicly accessible information systems.
|-
| [a] individuals authorized to post or process information on publicly accessible systems are identified. || Document || SSP, Website Governance Plan, Information Release Document.
|-
| [b] procedures to ensure CUI is not posted or processed on publicly accessible systems are identified. || Document || SSP, Website Governance Plan, Information Release Document.
|-
| [c] a review process is in place prior to posting of any content to publicly accessible systems. || Artifact || "Information release approval process, i.e. chain of email communication from originator, approver, and final decision (may or may not include individual authorized to post);
SharePoint/electronic or paper form/ ticket system showing information flow between requestor and approver (may or may not include individual authorized to post)."
|-
| [d] content on publicly accessible systems is reviewed to ensure that it does not include CUI. || Artifact || Incident response process, web design/update/modification SOP etc.
|-
| [e] mechanisms are in place to remove and address improper posting of CUI. || Artifact || Incident response process, web design/update/modification SOP etc.
|}

== Awareness and Training (AT) ==
=== AT.L2-3.2.1 – Role-Based Risk Awareness ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AT.L2-3.2.1_Details|'''AT.L2-3.2.1''']] Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems.
|-
| [a] security risks associated with organizational activities involving CUI are identified. || Document || Policy of Security Awareness Training; Security Awareness Training Briefing.
|-
| [b] policies, standards, and procedures related to the security of the system are identified. || Document || Acceptable Use Policy, Policy/Procedures/Instruction related to the security of the system.
|-
| [c] managers, systems administrators, and users of the system are made aware of the security risks associated with their activities. || Artifact || Security Training Brief, training records.
|-
| [d] managers, systems administrators, and users of the system are made aware of the applicable policies, standards, and procedures related to the security of the system. || Artifact || Policies, standards and procedures for employees within training (completed training report).
|}

=== AT.L2-3.2.2 – Role-Based Training ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AT.L2-3.2.2_Details|'''AT.L2-3.2.2''']] Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities.|-
|-
| [a] information security-related duties, roles, and responsibilities are defined. || Document || Policy/Procedures/Instruction, Job Role Matrix, Position Descriptions, User Roles.
|-
| [b] information security-related duties, roles, and responsibilities are assigned to designated personnel. || Artifact || Screenshot of breakout of different roles/permissions assigned to individuals (i.e. ActiveDirectory); Privilege Access Agreement.
|-
| [c] personnel are adequately trained to carry out their assigned information security-related duties, roles, and responsibilities. || Artifact || Screenshot of tool and/or training specifying security specific roles, duties and responsibilities; Screenshot of required certifications (i.e. Sec+, CISSP).
|}

=== AT.L2-3.2.3 – Insider Threat Awareness ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AT.L2-3.2.3_Details|'''AT.L2-3.2.3''']] Provide security awareness training on recognizing and reporting potential indicators of insider threat.
|-
| [a] potential indicators associated with insider threats are identified. || Document || Insidert Threat Policy/Procedures/Instruction; Insider Threat Training/Briefing.
|-
| [b] security awareness training on recognizing and reporting potential indicators of insider threat is provided to managers and employees. || Artifact || Screenshot of training records showing completion of Insider Threat training, emails showing completion of Insider Threat training, Screenshot of certificate showing completion with individual's name.
|}

== Audit and Accountability (AU) ==
=== AU.L2-3.3.1 – System Auditing ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.1_Details|'''AU.L2-3.3.1''']] Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.
|-
| [a] audit logs needed (i.e., event types to be logged) to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity are specified. || Document || SSP, policy, or auditing and logging process that defines specific types of events to be logged.
|-
| [b] the content of audit records needed to support monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity is defined. || Document || SSP, policy, or auditing and logging process that defines specific content of audit records/files.
|-
| [c] audit records are created (generated). || Screen Share || Screen share of tool that shows logs are generated for all systems.
|-
| [d] audit records, once created, contain the defined content. || Screen Share || Screen share of tool that shows logs contain defined content as defined in SSP, policy, or procedures.
|-
| [e] retention requirements for audit records are defined. || Document || SSP, Polocy, or Auditing and logging process that describes how long records are kept.
|-
| [f] audit records are retained as defined. || Screen Share || Screen share of tool that shows records and audit content retained at a minimum as defined.
|}

=== AU.L2-3.3.2 – User Accountability ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.2_Details|'''AU.L2-3.3.2''']] Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions.
|-
| [a] the content of the audit records needed to support the ability to uniquely trace users to their actions is defined. || Document || SSP, policy, or process that defines actions traced back to individuals.
|-
| [b] audit records, once created, contain the defined content. || Screen Share || Screen share of tool that shows audit records traced to specific users/roles.
|}

=== AU.L2-3.3.3 – Event Review ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.3_Details|'''AU.L2-3.3.3''']] Review and update logged events.
|-
| [a] a process for determining when to review logged events is defined. || Document || SSP, policy, or documented process that shows frequency of when to review types of logged events.
|-
| [b] event types being logged are reviewed in accordance with the defined review process. || Artifact || Evidence through a documented method such as meeting minutes, CAB minutes, etc. of log sources and log events being logged at the defined frequency.
|-
| [c] event types being logged are updated based on the review. || Artifact || Evidence of implementation based on the results of the review of logged events/sources through a ticket, meeting minutes, or screen share of the tool that shows changes implemented (finetuning).
|}

=== AU.L2-3.3.4 – Audit Failure Alerting ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.4_Details|'''AU.L2-3.3.4''']] Alert in the event of an audit logging process failure.
|-
| [a] personnel or roles to be alerted in the event of an audit logging process failure are identified. || Document || SSP, policy, or procedure that shows who needs to be notified in case of an audit failure.
|-
| [b] types of audit logging process failures for which alert will be generated are defined. || Document || SSP, policy, or procedure that shows what types of failure will generate notifications.
|-
| [c] identified personnel or roles are alerted in the event of an audit logging process failure. || Artifact || Artifact such as email or ticket that shows the identified personnel were alerted of any audit/logging process failure as defined.
|}

=== AU.L2-3.3.5 – Audit Correlation ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.5_Details|'''AU.L2-3.3.5''']] Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.
|-
| [a] audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity are defined. || Document || SSP, policy, or procedure covering audit logging, monitoring, and reporting.
|-
| [b] defined audit record review, analysis, and reporting processes are correlated. || Artifact || Artifact showing an audit event and the resultant corrective action or actions to the event; this can be a Help Desk ticket, meeting notes, or a change control board items showing the event and any corrective action taken.
|}

=== AU.L2-3.3.6 – Reduction & Reporting ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.6_Details|'''AU.L2-3.3.6''']] Provide audit record reduction and report generation to support on-demand analysis and reporting.
|-
| [a] an audit record reduction capability that supports on-demand analysis is provided. || Screen Share || Screen share of the logging environment where an event can be selected and traced back to a specific device, or dashboard showing realtime event analysis.
|-
| [b] a report generation capability that supports on-demand reporting is provided. || Screen Share || Screen share showing the generation of an on demand report.
|}

=== AU.L2-3.3.7 – Authoritative Time Source ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.7_Details|'''AU.L2-3.3.7''']] Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.
|-
| [a] internal system clocks are used to generate time stamps for audit records. || Screen Share || Screen share showing the NTP settings of a windows, Unix, Linux device; a screen share showing the NTP settings of network appliances.
|-
| [b] an authoritative source with which to compare and synchronize internal system clocks is specified. || Document || SSP or policy indicating that devices need to be synched to a local authoritative time device that is synched with an authoritative time service.
|-
| [c] internal system clocks used to generate time stamps for audit records are compared to and synchronized with the specified authoritative time source. || Screen Share || Screen share showing device logging appliance time is point to the appropriate authoritative time server.
|}

=== AU.L2-3.3.8 – Audit Protection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.8_Details|'''AU.L2-3.3.8''']] Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
|-
| [a] audit information is protected from unauthorized access. || Screen Share || Screen share showing operating system permissions on the audit folders being restricted to appropriate users.
|-
| [b] audit information is protected from unauthorized modification. || Screen Share || Screen share showing operating system permissions on the audit folders being restricted to appropriate users.
|-
| [c] audit information is protected from unauthorized deletion. || Screen Share || Screen share showing operating system permissions on the audit folders being restricted to appropriate users.
|-
| [d] audit logging tools are protected from unauthorized access. || Screen Share || Artifact showing access permissions in the SIEM tool.
|-
| [e] audit logging tools are protected from unauthorized modification. || Screen Share || Artifact showing update permissions in the SIEM tool.
|-
| [f] audit logging tools are protected from unauthorized deletion. || Screen Share || Artifact showing delete permissions in the SIEM tool.
|}

=== AU.L2-3.3.9 – Audit Management ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.9_Details|'''AU.L2-3.3.9''']] Limit management of audit logging functionality to a subset of privileged users.
|-
| [a] a subset of privileged users granted access to manage audit logging functionality is defined. || Document || SSP or policy indicating which users or groups have access to audit logs.
|-
| [b] management of audit logging functionality is limited to the defined subset of privileged users. || Screen Share || Artifact showing SIEM or OS folder permissions (this should be limited to the assigned users or groups); artifact showing an ACL setting in SIEM tool in regards to logs.
|}

== Configuration Management (CM) ==
=== CM.L2-3.4.1 – System Baselining ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.1_Details|'''CM.L2-3.4.1''']] Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.
|-
| [a] a baseline configuration is established. || Document || Documentation showing or explaining standard imaging process (how standard images are deployed and where they are stored).
|-
| [b] the baseline configuration includes hardware, software, firmware, and documentation. || Artifact || Screenshot of repository of where images are maintained and information relating to hardware, software, and firmware.
|-
| [c] the baseline configuration is maintained (reviewed and updated) throughout the system development life cycle. || Artifact || Screenshot/evidence displaying management of baseline configurations (how often they are being managed as stated).
|-
| [d] a system inventory is established. || Document || Screenshot/evidence displaying inventory listing of approved products for use.
|-
| [e] the system inventory includes hardware, software, firmware, and documentation. || Artifact || Screeenshot/evidence displaying inventory listing of approved products and versions permitted for use.
|-
| [f] the inventory is maintained (reviewed and updated) throughout the system development life cycle. || Artifact || Screeenshot/evidence displaying management of baseline configurations (How often and are they being managed as stated.
|}

=== CM.L2-3.4.2 – Security Configuration Enforcement ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.2_Details|'''CM.L2-3.4.2''']] Establish and enforce security configuration settings for information technology products employed in organizational systems.
|-
| [a] security configuration settings for information technology products employed in the system are established and included in the baseline configuration. || Document || Documentation explaining methodology used by organization to create secure baselines (STIGs, benchmarks).
|-
| [b] security configuration settings for information technology products employed in the system are enforced. || Artifact || Evidence of tool/s used to enforce security configurations to ensure images used are free from modification unless authorized.
|}

=== CM.L2-3.4.3 – System Change Management ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.3_Details|'''CM.L2-3.4.3''']] Track, review, approve or disapprove, and log changes to organizational systems.
|-
| [a] changes to the system are tracked. || Artifact || Evidence of IT Service Management tool / process used to track system changes.
|-
| [b] changes to the system are reviewed. || Artifact || Evidence of IT Service Management tool / process used to review system changes.
|-
| [c] changes to the system are approved or disapproved. || Artifact || Evidence of IT Service Management tool / process used to approve/disapprove system changes.
|-
| [d] changes to the system are logged. || Artifact || Evidence of IT Service Management tool / process used to log system changes.
|}

=== CM.L2-3.4.4 – Security Impact Analysis ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.4_Details|'''CM.L2-3.4.4''']] Analyze the security impact of changes prior to implementation.
|-
| [a] the security impact of changes to the system is analyzed prior to implementation. || Artifact || Document explaining that security impact analysis of proposed changes to a system is conducted prior to implementation.
|}

=== CM.L2-3.4.5 – Access Restrictions for Change ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.5_Details|'''CM.L2-3.4.5''']] Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.
|-
| [a] physical access restrictions associated with changes to the system are defined. || Document || Document explaining the process of how physical access restrictions are defined for an individuals ability to make system changes.
|-
| [b] physical access restrictions associated with changes to the system are documented. || Document || Document explaining the process of how physical access restrictions are defined for an individuals ability to make system changes are documented; access request process.
|-
| [c] physical access restrictions associated with changes to the system are approved. || Artifact || Evidence of process of how physical access to systems are granted (i.e. physical access request sample).
|-
| [d] physical access restrictions associated with changes to the system are enforced. || Physical Review || Evidence of process of how physical access to systems are enforced (physical access system).
|-
| [e] logical access restrictions associated with changes to the system are defined. || Document || Document explaining the process of how logical access restrictions are defined for an individual's ability to make system changes.
|-
| [f] logical access restrictions associated with changes to the system are documented. || Document || Document explaining the process of how logical access restrictions are defined for an individual's ability to make system changes are documented.
|-
| [g] logical access restrictions associated with changes to the system are approved. || Artifact || Evidence of process of how logical access to systems are granted.
|-
| [h] logical access restrictions associated with changes to the system are enforced. || Artifact || Evidence of process of how logical access to systems are enforced.
|}

=== CM.L2-3.4.6 – Least Functionality ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.6_Details|'''CM.L2-3.4.6''']] Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.
|-
| [a] essential system capabilities are defined based on the principle of least functionality. || Document || Documentation explaining how systems are configured to utilize the principle of least functionality for designated users.
|-
| [b] the system is configured to provide only the defined essential capabilities. || Screen Share || Evidence displaying how systems are configured to utilize the principle of least functionality for designated users; disabled service settings, accepted standards for hardening (CIS benchmarks, etc.).
|}

=== CM.L2-3.4.7 – Nonessential Functionality ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.7_Details|'''CM.L2-3.4.7''']] Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.
|-
| [a] essential programs are defined. || Document || Documented essential programs specified; build documents; software center; SSP.
|-
| [b] the use of nonessential programs is defined. || Document || Documented listing of nonessential programs (whatever is NOT specified in [a]); AUP/User Agreement may identify nonessential use/programs.
|-
| [c] the use of nonessential programs is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict nonessential programs displays restrictions as defined (McAfee ePO settings, Carbon Black rules, etc.).
|-
| [d] essential functions are defined. || Document || Documented essential functions are specified.
|-
| [e] the use of nonessential functions is defined. || Document || Documented nonessential functions are specified.
|-
| [f] the use of nonessential functions is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict essential/nonessential functions displays restrictions as defined.
|-
| [g] essential ports are defined. || Document || Documented essential ports are specified.
|-
| [h] the use of nonessential ports is defined. || Document || Documented nonessential ports functions are specified.
|-
| [i] the use of nonessential ports is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict essential/nonessential ports displays restrictions as defined (FW rules; McAfee; GPO, etc.).
|-
| [j] essential protocols are defined. || Document || Documented essential protocols are specified.
|-
| [k] the use of nonessential protocols is defined. || Document || Documented nonessential protocols functions are specified.
|-
| [l] the use of nonessential protocols is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict essential/nonessential protocols displays restrictions as defined (FW rules; GPO, etc.).
|-
| [m] essential services are defined. || Document || Documented essential services specified.
|-
| [n] the use of nonessential services is defined. || Document || Documented nonessential services functions are specified.
|-
| [o] the use of nonessential services is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict essential/nonessential services displays restrictions as defined.
|}

=== CM.L2-3.4.8 – Application Execution Policy ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.8_Details|'''CM.L2-3.4.8''']] Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.
|-
| [a] a policy specifying whether whitelisting or blacklisting is to be implemented is specified. || Document || Documentation explaining whitelisting or blacklisting process.
|-
| [b] the software allowed to execute under whitelisting or denied use under blacklisting is specified. || Document || Documentation explaining whitelisting or blacklisting process for software.
|-
| [c] whitelisting to allow the execution of authorized software or blacklisting to prevent the use of unauthorized software is implemented as specified. || Screen Share || Tool used for whitelisting or blacklisting for software shows capability of restricting/authorizing software (Carbon Black dashboard, "SW Store", web proxies, DNS Blackhole, etc.).
|}

=== CM.L2-3.4.9 – User-Installed Software ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.9_Details|'''CM.L2-3.4.9''']] Control and monitor user-installed software.
|-
| [a] a policy for controlling the installation of software by users is established. || Document || Documented software authorization process or methodology for approval.
|-
| [b] installation of software by users is controlled based on the established policy. || Screen Share || Evidence that approval/restriction in installation of software by authorized personnel is implemented as specified (AUP, GPO, etc.).
|-
| [c] installation of software by users is monitored. || Screen Share || Evidence that installation of software by authorized personnel is monitored (SCCM groups, SW Center, etc.).
|}

== Identification and Authentication (IA) ==
=== IA.L2-3.5.1 – Identification [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.1_Details|'''IA.L2-3.5.1''']] Identify information system users, processes acting on behalf of users, or devices.
|-
| [a] system users are identified. || Document || Based on what is defined in their documentation (SSP, AUP, Policy, SOP), request to see a sample of non-privileged/privileged users in AD OU group (overlaps with 3.1.1 and 3.1.5).
|-
| [b] processes acting on behalf of users are identified. || Document || Based on what is defined in their documentation (SSP, AUP, Policy, SOP), request to see a sample of service accounts in AD OU group (overlaps with 3.1.1 and 3.1.5).
|-
| [c] devices accessing the system are identified. || Document || Based on what is defined in their documentation (SSP, AUP, Policy, SOP), request to see a sample of domain-joined workstation & servers in AD OU group (overlaps with 3.1.1 and 3.1.5). For network devices, request screen share/artifact to show how they are identified on the enterprise network.
|}

=== IA.L2-3.5.2 – Authentication [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.2_Details|'''IA.L2-3.5.2''']] Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems.
|-
| [a] the identity of each user is authenticated or verified as a prerequisite to system access. || Screen Share || If the user logs in with non-privileged account during other demoes and then a privileged account, then this should be satisfied. If screen share is unavailable, request logs to show successful and unsuccessful login by privileged and non-privilged users.
|-
| [b] the identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access. || Screen Share || Request a log that shows successful/unsuccessful service account trying to log on to company's asset.
|-
| [c] the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access. || Screen Share || Request a log that shows domain-joined workstation/server authenticating to AD (focus on the MAC/IP address/hostname).
|}

=== IA.L2-3.5.3 – Multifactor Authentication ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.3_Details|'''IA.L2-3.5.3''']] Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
|-
| [a] privileged accounts are identified. || Document || Based on what is defined in their documentation, request to see a sample of privileged users in AD OU group. Overlaps with 3.1.5. Screenshot/screen share to show implementation is enforced.
|-
| [b] multifactor authentication is implemented for local access to privileged accounts. || Screen Share || SSP, AUP, Policy, SOP that defines that MFA is needed for privileged local access.
|-
| [c] multifactor authentication is implemented for network access to privileged accounts. || Screen Share || Within the MFA implementation mechanism, show that privileged users are forced to use MFA; Screenshot/Screen share to show implementation is enforced.
|-
| [d] multifactor authentication is implemented for network access to non-privileged accounts. || Screen Share || Within the MFA implementation mechanism, show that non-privileged users are forced to use MFA; Screenshot/Screen share to show implementation is enforced.
|}

=== IA.L2-3.5.4 – Replay-Resistant Authentication ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.4_Details|'''IA.L2-3.5.4''']] Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.
|-
| [a] replay-resistant authentication mechanisms are implemented for network account access to privileged and non-privileged accounts. || Screen Share || Show the GPO setting that enforces Kerberos within AD. If MFA is used, show the implementation to enforce replay resistant techniques. For non-windows, show the technical solution to enforce replay resistant attacks.
|}

=== IA.L2-3.5.5 – Identifier Reuse ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.5_Details|'''IA.L2-3.5.5''']] Prevent reuse of identifiers for a defined period.
|-
| [a] a period within which identifiers cannot be reused is defined. || Document || SSP, policies, or SOP that defines identifier reuse.
|-
| [b] reuse of identifiers is prevented within the defined period. || Artifact || Show the GPO setting/technical solution that enforces what is defined in policy/documentation (this can be automated or manual process; screen share/artifacts can be presented to satisfy this requirement.
|}

=== IA.L2-3.5.6 – Identifier Handling ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.6_Details|'''IA.L2-3.5.6''']] Disable identifiers after a defined period of inactivity.
|-
| [a] a period of inactivity after which an identifier is disabled is defined. || Document || SSP, policy that defines the period of inactivity after which an identifier is disabled.
|-
| [b] identifiers are disabled after the defined period of inactivity. || Artifact || Screen share AD or similar tool supporting directory-based identity-related services for disabled accounts (can be done by hand or script).
|}

=== IA.L2-3.5.7 – Password Complexity ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.7_Details|'''IA.L2-3.5.7''']] Enforce a minimum password complexity and change of characters when new passwords are created.
|-
| [a] password complexity requirements are defined. || Document || SSP, policy that defines password complexity requirements.
|-
| [b] password change of character requirements are defined. || Document || SSP, policy that defines change of character requirements are defined.
|-
| [c] minimum password complexity requirements as defined are enforced when new passwords are created. || Screen Share || Screen share of AD or similar directory-based identity-related service tool to show complexity requirements.
|-
| [d] minimum password change of character requirements as defined are enforced when new passwords are created. || Screen Share || Screen share of Group Policy configuration or similar tool providing centralized management and configuration of operating systems, applications, and users' settings to show that characters must be changed.
|}

=== IA.L2-3.5.8 – Password Reuse ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.8_Details|'''IA.L2-3.5.8''']] Prohibit password reuse for a specified number of generations.
|-
| [a] the number of generations during which a password cannot be reused is specified. || Document || SSP, policy that specifies the number of generations during which a password cannot be reused is specified.
|-
| [b] reuse of passwords is prohibited during the specified number of generations. || Screen Share || Screen share Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration to show reuse of passwords is prohibited.
|}

=== IA.L2-3.5.9 – Temporary Passwords ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.9_Details|'''IA.L2-3.5.9''']] Allow temporary password use for system logons with an immediate change to a permanent password.
|-
| [a] an immediate change to a permanent password is required when a temporary password is used for system logon. || Screen Share || Screen share of Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration to show "change password at first logon."
|}

=== IA.L2-3.5.10 – Cryptographically-Protected Passwords ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.1_Details|'''IA.L2-3.5.1''']] Store and transmit only cryptographically-protected passwords.
|-
| [a] passwords are cryptographically protected in storage. || Screen Share || Screen share Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration that Kerberos, or a similar network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner, is enabled.
|-
| [b] passwords are cryptographically protected in transit. || Screen Share || Screen share Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration that Kerberos, or a similar network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner, is enabled.
|}

=== IA.L2-3.5.11 – Obscure Feedback ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.10_Details|'''IA.L2-3.5.10''']] Obscure feedback of authentication information.
|-
| [a] authentication information is obscured during the authentication process. || Screen Share || Screen share of Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration to show that passwords are obscured.
|}

== Incident Response (IR) ==
=== IR.L2-3.6.1 – Incident Handling ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IR.L2-3.6.1_Details|'''IR.L2-3.6.1''']] Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.
|-
| [a] an operational incident-handling capability is established. || Document || Incident Response SOP/Plan.
|-
| [b] the operational incident-handling capability includes preparation. || Document || Incident Response SOP/Plan, prior incident report, training, COOP plan.
|-
| [c] the operational incident-handling capability includes detection. || Document || Incident Response SOP/Plan; definition of tools used to detect; artifacts showing tools used; prior incident report.
|-
| [d] the operational incident-handling capability includes analysis. || Document || Incident Response SOP/Plan; Definition of tools used to analyze potential incidents; artifacts showing tools used for analysis; prior incident report.
|-
| [e] the operational incident-handling capability includes containment. || Document || Incident Response SOP/Plan; isolation/quarantine process; user training.
|-
| [f] the operational incident-handling capability includes recovery. || Document || Incident Response SOP/Plan; COOP Plan; prior incident reports, re-baselining impacted devices.
|-
| [g] the operational incident-handling capability includes user response. || Document || Incident Response SOP/Plan; user awareness training; Help Desk process.

|}

=== IR.L2-3.6.2 – Incident Reporting ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IR.L2-3.6.2_Details|'''IR.L2-3.6.2''']] Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.
|-
| [a] incidents are tracked. || Artifact || Incident Response SOP/Plan; ITSM artifact; technical implementation for incident tracking.
|-
| [b] incidents are documented. || Artifact || Incident Response SOP/Plan; ITSM artifact; technical implementation for incident tracking.
|-
| [c] authorities to whom incidents are to be reported are identified. || Document || Incident Response SOP/Plan.
|-
| [d] organizational officials to whom incidents are to be reported are identified. || Document || Incident Response SOP/Plan.
|-
| [e] identified authorities are notified of incidents. || Screen Share || Prior incident report; DIBNET login; prior email notifications.
|-
| [f] identified organizational officials are notified of incidents. || Artifact || Prior incident report; prior email notifications; tabletop exercises.
|}

=== IR.L2-3.6.3 – Incident Response Testing ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IR.L2-3.6.3_Details|'''IR.L2-3.6.3''']] Test the organizational incident response capability.
|-
| [a] the incident response capability is tested. || Artifact || Incident response table top/scheduled or unscheduled test or penetration test.
|}

== Maintenance (MA) ==
=== MA.L2-3.7.1 – Perform Maintenance ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.1_Details|'''MA.L2-3.7.1''']] Perform maintenance on organizational systems.
|-
| [a] system maintenance is performed. || Artifact || Establish typical maintenance activities (HVAC, UPS, power distribution, generators, copier maintenance) that are performed; maintenance agreements or contracts detailing these types of activities are acceptable; interview responses should be considered. This requirement should not be confused with 3.14.1 - report, remediate, and correct system flaws in a timely manner (patch management).
|}

=== MA.L2-3.7.2 – System Maintenance Control ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.2_Details|'''MA.L2-3.7.2''']] Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance.
|-
| [a] tools used to conduct system maintenance are controlled. || Artifact || Tools may largely depend on the assessed environment; discussion examples include network diagnostic and monitoring tools (including hardware and software); artifacts could demonstrate secured locations/areas for these tools (photos) or checkout sheets/rosters (documents) depicting responsible personnel and the dates/times of checkout.
|-
| [b] techniques used to conduct system maintenance are controlled. || Artifact || Processes for scheduling, performing, documenting, reviewing, approving, and monitoring maintenance and repairs for the information system.
|-
| [c] mechanisms used to conduct system maintenance are controlled. || Artifact || Processes for scheduling, performing, documenting, reviewing, approving, and monitoring maintenance and repairs for the information system.
|-
| [d] personnel used to conduct system maintenance are controlled. || Physical Review || Screenshot of who is authorized to conduct maintenance; maintenance personnel training program.
|}

=== MA.L2-3.7.3 – Equipment Sanitization ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.3_Details|'''MA.L2-3.7.3''']] Ensure equipment removed for off-site maintenance is sanitized of any CUI.
|-
| [a] equipment to be removed from organizational spaces for off-site maintenance is sanitized of any CUI. || Artifact || Document or artifact; record if equipment sanitized; categories of sanitization/destruction defined; sanitization procedural document.
|}

=== MA.L2-3.7.4 – Media Inspection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.4_Details|'''MA.L2-3.7.4''']] Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems.
|-
| [a] media containing diagnostic and test programs are checked for malicious code before being used in organizational systems that process, store, or transmit CUI. || Artifact || Screenshot of diagnostic/test program being used (such as Symantec and McAfee on access scans…).
|}

=== MA.L2-3.7.5 – Nonlocal Maintenance ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.5_Details|'''MA.L2-3.7.5''']] Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete.
|-
| [a] multifactor authentication is used to establish nonlocal maintenance sessions via external network connections. || Screen Share || Describe MFA used to remote from external service to organizational systems for maintenance and screenshot of MFA (3.5.3)(points associated with admin).
|-
| [b] nonlocal maintenance sessions established via external network connections are terminated when nonlocal maintenance is complete. || Screen Share || Screenshot VPN session timeout.
|}

=== MA.L2-3.7.6 – Maintenance Personnel ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.6_Details|'''MA.L2-3.7.6''']] Supervise the maintenance activities of maintenance personnel without required access authorization.
|-
| [a] maintenance personnel without required access authorization are supervised during maintenance activities. || Document || System maintenance policy; list of authorized personnel; maintenance records or, contracts/SLAs; WebEx.
|}

== Media Protection (MP) ==
=== MP.L2-3.8.1 – Media Protection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.1_Details|'''MP.L2-3.8.1''']] Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital.
|-
| [a] paper media containing CUI is physically controlled. || Document || Policy showing CUI paper media is controlled; artifact showing who has access; artifacts/records of inventories conducted; media check out procedures (i.e. file cabinets, encryption, password protection).
|-
| [b] digital media containing CUI is physically controlled. || Document || Policy showing CUI digital media is controlled; artifact showing who has access; artifacts/records of inventories conducted; media check out procedures (i.e. file cabinets, external drives, USBs, encryption, password protection).
|-
| [c] paper media containing CUI is securely stored. || Physical Review || Check out/sign out sheets; possible photo of storage container/video walk through of storage area; badge reader logs or access lists for keys for secured areas; interview response considered (i.e. file cabinets, encryption, password protection).
|-
| [d] digital media containing CUI is securely stored. || Physical Review || Check out/sign out sheets; possible photo of storage container/video walk through of storage area; badge reader logs or access lists for keys for secured areas; interview response considered (i.e. file cabinets, external drives, USBs, encryption, password protection).
|}

=== MP.L2-3.8.2 – Media Access ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.2_Details|'''MP.L2-3.8.2''']] Limit access to CUI on system media to authorized users.
|-
| [a] access to CUI on system media is limited to authorized users. || Artifact || Document describing how CUI is limited AND artifact showing principle of least access is implemented.
|}

=== MP.L2-3.8.3 – Media Disposal [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.3_Details|'''MP.L2-3.8.3''']] Sanitize or destroy information system media containing Federal Contract Information before disposal or release for reuse.
|-
| [a] system media containing CUI is sanitized or destroyed before disposal. || Document || Policy or artifact of media destruction logs; certificates of destruction; SLAs or contracts.
|-
| [b] system media containing CUI is sanitized before it is released for reuse. || Document || Policy or artifact describing method to sanitize, software used (i.e. DoD Wipe, ShredIT and Iron Mountain; Blancco; GDisk, DBAN).
|}

=== MP.L2-3.8.4 – Media Markings ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.4_Details|'''MP.L2-3.8.4''']] Mark media with necessary CUI markings and distribution limitations.
|-
| [a] media containing CUI is marked with applicable CUI markings. || Physical Review || Document or artifact showing CUI markings (i.e. labeling standards ).
|-
| [b] media containing CUI is marked with distribution limitations. || Physical Review || Document or artifact showing distro limitations (i.e. labeling standards ).
|}

=== MP.L2-3.8.5 – Media Accountability ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.5_Details|'''MP.L2-3.8.5''']] Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas.
|-
| [a] access to media containing CUI is controlled. || Document || Policy, artifact of audit logs showing tracking, Access Control Lists, records of transport activities (i.e. USB drives, CDs, chain of custody.
|-
| [b] accountability for media containing CUI is maintained during transport outside of controlled areas. || Artifact || Artifact of audit logs showing tracking, Access Control Lists, records of transport activities (i.e. USB drives, CDs; chain of custody.
|}

=== MP.L2-3.8.6 – Portable Storage Encryption ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.6_Details|'''MP.L2-3.8.6''']] Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards.
|-
| [a] the confidentiality of CUI stored on digital media is protected during transport using cryptographic mechanisms or alternative physical safeguards. || Artifact || Artifact showing crypto mechanisms used to protect (are they FIPS 140-2 [13.11]); artifact showing what alternative physical safeguards are in place (i.e. encryption; BitLocker; McAfee ).
|}

=== MP.L2-3.8.7 – Removable Media ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.7_Details|'''MP.L2-3.8.7''']] Control the use of removable media on system components.
|-
| [a] the use of removable media on system components is controlled. || Artifact || Policy showing if removable media is allowed; writable removable media is restricted; tracking artifacts; what tools are used (i.e. Carbon Black, Crowd Strike, GPO, Zoho Desktop Central); procedure/process describing what happens if it is lost; what mechanisms are in place to control/restrict removable media (i.e. Active Directory Groups and Group Policy artifact showing restriction).
|}

=== MP.L2-3.8.8 – Shared Media ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.8_Details|'''MP.L2-3.8.8''']] Prohibit the use of portable storage devices when such devices have no identifiable owner.ASSESSMENT OBJECTIVES'''
|-
| [a] the use of portable storage devices is prohibited when such devices have no identifiable owner. || Artifact || Policy and/or artifact showing company stance on portable storage devices if there is no owner (are personal USB devices allowed or are they company-issued; artifact showing alerts if device is connected to network (i.e. external HDD, Carbon Black, Crowd Strike, GPO, Zoho Desktop Central.
|}

=== MP.L2-3.8.9 – Protect Backups ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.9_Details|'''MP.L2-3.8.9''']] Protect the confidentiality of backup CUI at storage locations.
|-
| [a] the confidentiality of backup CUI is protected at storage locations. || Artifact || Policy on system backups; artifact showing media labeling; artifact showing encyption (is it FIPS 140-2 [13.11]); Access Control List artifact (i.e. backup tapes, Tivoli Storage Manager).
|}

== Personnel Security (PS) ==
=== PS.L2-3.9.1 – Screen Individuals ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PS.L2-3.9.1_Details|'''PS.L2-3.9.1''']] Screen individuals prior to authorizing access to organizational systems containing CUI.
|-
| [a] individuals are screened prior to authorizing access to organizational systems containing CUI. || Artifact || Screenshot of records of screened personnel/background checks.
|}

=== PS.L2-3.9.2 – Personnel Actions ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PS.L2-3.9.2_Details|'''PS.L2-3.9.2''']] Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers.
|-
| [a] a policy and/or process for terminating system access and any credentials coincident with personnel actions is established. || Document || Personnel security policy/procedures/instruction; Access control policy/procedure/instruction.
|-
| [b] system access and credentials are terminated consistent with personnel actions such as termination or transfer. || Artifact || Screenshot of records of personnel transfer and termination actions.
|-
| [c] the system is protected during and after personnel transfer actions. || Artifact || Completed outprocessing checklist.
|}

== Physical Protection (PE) ==
=== PE.L2-3.10.1 – Limit Physical Access [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.1_Details|'''PE.L2-3.10.1''']] Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals.
|-
| [a] authorized individuals allowed physical access are identified. || Artifact || Authorized personnel (names) access list.
|-
| [b] physical access to organizational systems is limited to authorized individuals. || Physical Review || Badge reader logs, audit logs, and/or card swipe test.
|-
| [c] physical access to equipment is limited to authorized individuals. || Physical Review || Badge reader logs, audit logs, and/or card swipe test.
|-
| [d] physical access to operating environments is limited to authorized. || Physical Review || Badge reader logs, audit logs, and/or card swipe test.
|}

=== PE.L2-3.10.2 – Monitor Facility ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.2_Details|'''PE.L2-3.10.2''']] Protect and monitor the physical facility and support infrastructure for organizational systems.
|-
| [a] the physical facility where organizational systems reside is protected. || Physical Review || Physical security measures and barriers into the physical facility (cameras/locks/gates/guards, etc.).
|-
| [b] the support infrastructure for organizational systems is protected. || Physical Review || Physical barriers to entries into computer spaces, server rooms, etc.
|-
| [c] the physical facility where organizational systems reside is monitored. || Physical Review || Audit logs/how the physical facility is being monitored (cameras/access system/guards, etc.).
|-
| [d] the support infrastructure for organizational systems is monitored. || Physical Review || Audit logs/how the physical facility is being monitored (cameras/access system/guards, etc.).
|}

=== PE.L2-3.10.3 – Escort Visitors [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.3_Details|'''PE.L2-3.10.3''']] Escort visitors and monitor visitor activity.
|-
| [a] visitors are escorted. || Physical Review || Policy/procedures/instruction on methodology for handling non-authorized personnel (entry to exit).
|-
| [b] visitor activity is monitored. || Physical Review || Policy/procedures/instructio on methodology for handling non-authorized personnel (entry to exit).
|}

=== PE.L2-3.10.4 – Physical Access Logs [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.4_Details|'''PE.L2-3.10.4''']] Maintain audit logs of physical access.
|-
| [a] audit logs of physical access are maintained. || Artifact || Log or report from badging system.
|}

=== PE.L2-3.10.5 – Manage Physical Access [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.5_Details|'''PE.L2-3.10.5''']] Control and manage physical access devices.
|-
| [a] physical access devices are identified. || Document || Physical access control systems description, guard force contract/policy, key locks, logical systems specifications, etc.
|-
| [b] physical access devices are controlled. || Physical Review || Inventory records of physical access control devices (e.g. keys, locks, card readers, locks, etc.).
|-
| [c] physical access devices are managed. || Physical Review || List of security safeguards controlling access to the facility (e.g. cameras, monitoring by guards, isolation of IT systems equiment and or system components).
|}

=== PE.L2-3.10.6 – Alternative Work Sites ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.6_Details|'''PE.L2-3.10.6''']] Enforce safeguarding measures for CUI at alternate work sites.
|-
| [a] safeguarding measures for CUI are defined for alternate work sites. || Document || Telework agreement, Acceptable Use Policy and SOP for alternate work locations; user security training validation which includes physical/logical/technical protections of system at alternate work sites.
|-
| [b] safeguarding measures for CUI are enforced for alternate work sites. || Artifact || Monitoring/audit log of user activity and logical/physical/technical mechanisms in place to preclude unauthorized activity (telework agreement , AUP?).
|}

== Risk Assessment (RA) ==
=== RA.L2-3.11.1 – Risk Assessments ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_RA.L2-3.11.1_Details|'''RA.L2-3.11.1''']] Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI.
|-
| [a] the frequency to assess risk to organizational operations, organizational assets, and individuals is defined. || Document || Risk assessment policy.
|-
| [b] risk to organizational operations, organizational assets, and individuals resulting from the operation of an organizational system that processes, stores, or transmits CUI is assessed with the defined frequency. || Artifact || Copy of last risk assessment done within defined frequency.
|}

=== RA.L2-3.11.2 – Vulnerability Scan ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_RA.L2-3.11.2_Details|'''RA.L2-3.11.2''']] Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
|-
| [a] the frequency to scan for vulnerabilities in organizational systems and applications is defined. || Document || Policy/procedures/instruction addressing vulnerability scanning records.
|-
| [b] vulnerability scans are performed on organizational systems with the defined frequency. || Screen Share || System configuration settings of vulnerability scanning scheduling and vulnerability scan results of systems within defined frequency.
|-
| [c] vulnerability scans are performed on applications with the defined frequency. || Screen Share || System configuration settings of vulnerability scanning scheduling and vulnerability scan results of applications within defined frequency.
|-
| [d] vulnerability scans are performed on organizational systems when new vulnerabilities are identified. || Screen Share || View signatures in scanning tool/ad hoc scan performed as a result.
|-
| [e] vulnerability scans are performed on applications when new vulnerabilities are identified. || Screen Share || View signatures in scanning tool/ad hoc scan performed as a result.
|}

=== RA.L2-3.11.3 – Vulnerability Remediation ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_RA.L2-3.11.3_Details|'''RA.L2-3.11.3''']] Remediate vulnerabilities in accordance with risk assessments.
|-
| [a] vulnerabilities are identified. || Artifact || Scan results showing vulnerabilities identified.
|-
| [b] vulnerabilities are remediated in accordance with risk assessments. || Artifact || Screenshot/document of scan results of remediated vulnerabilities in accordance to risk assessments.
|}

== Security Assessment (CA) ==
=== CA.L2-3.12.1 – Security Control Assessment ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CA.L2-3.12.1_Details|'''CA.L2-3.12.1''']] Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.
|-
| [a] the frequency of security control assessments is defined. || Document || SSP.
|-
| [b] security controls are assessed with the defined frequency to determine if the controls are effective in their application. || Artifact || Copy of last security control assessment done within defined frequency.
|}

=== CA.L2-3.12.2 – Operational Plan of Action ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CA.L2-3.12.2_Details|'''CA.L2-3.12.2''']] Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.
|-
| [a] deficiencies and vulnerabilities to be addressed by the plan of action are identified. || Artifact || Plan of Action (POA).
|-
| [b] a plan of action is developed to correct identified deficiencies and reduce or eliminate identified vulnerabilities. || Artifact || Plan of Action (POA).
|-
| [c] the plan of action is implemented to correct identified deficiencies and reduce or eliminate identified vulnerabilities. || Artifact || Plan of Action (POA)/previously completed POAs.
|}

=== CA.L2-3.12.3 – Security Control Monitoring ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CA.L2-3.12.3_Details|'''CA.L2-3.12.3''']] Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.
|-
| [a] security controls are monitored on an ongoing basis to ensure the continued effectiveness of those controls. || Artifact || Collection of risk assessment results, internal or third-party audits/security assessments and/or continuous monitoring reports/alerts (SIEM tool, etc.).
|}

=== CA.L2-3.12.4 – System Security Plan ====
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CA.L2-3.12.4_Details|'''CA.L2-3.12.4''']] Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.
|-
| [a] a system security plan is developed. || Document || SSP.
|-
| [b] the system boundary is described and documented in the system security plan. || Document || SSP and any supporting documentation.
|-
| [c] the system environment of operation is described and documented in the system security plan. || Document || SSP and any supporting documentation.
|-
| [d] the security requirements identified and approved by the designated authority as non-applicable are identified. || Document || SSP and required adjudication from DoD CIO.
|-
| [e] the method of security requirement implementation is described and documented in the system security plan. || Document || SSP and any supporting documentation.
|-
| [f] the relationship with or connection to other systems is described and documented in the system security plan. || Document || SSP and any supporting documentation.
|-
| [g] the frequency to update the system security plan is defined. || Document || SSP.
|-
| [h] system security plan is updated with the defined frequency. || Document || SSP/any previous versions.
|}

== System and Communications Protection (SC) ==
=== SC.L2-3.13.1 – Boundary Protection [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.1_Details|'''SC.L2-3.13.1''']] Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems.
|-
| [a] the external system boundary is defined. || Document || SSP, network diagrams, CUI flow, cloud provider FedRAMP Moderate.
|-
| [b] key internal system boundaries are defined. || Document || SSP, network diagrams, CUI flow.
|-
| [c] communications are monitored at the external system boundary. || Screen Share || SSP, logging server, boundary device configurations, monitoring policy.
|-
| [d] communications are monitored at key internal boundaries. || Screen Share || SSP, logging server, boundary device configurations, monitoring policy.
|-
| [e] communications are controlled at the external system boundary. || Screen Share || SSP, boundary device configurations, ACL, subnets, DMZ.
|-
| [f] communications are controlled at key internal boundaries. || Screen Share || SSP, boundary device configurations, ACL, subnets.
|-
| [g] communications are protected at the external system boundary. || Screen Share || Configurations for IPS/IDS, email gateway, VLAN, proxy, firewall, malware protection, DNS, TSL.
|-
| [h] communications are protected at key internal boundaries. || Screen Share || Configurations for IPS/IDS, VLAN, firewall, malware protection, SSL.
|}

=== SC.L2-3.13.2 – Security Engineering ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.2_Details|'''SC.L2-3.13.2''']] Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.
|-
| [a] architectural designs that promote effective information security are identified. || Document || SSP, config management policy, network diagram, CCB minutes, enterprise architecture process.
|-
| [b] software development techniques that promote effective information security are identified. || Document || SSP, config management policy, SDLC, CCB minutes.
|-
| [c] systems engineering principles that promote effective information security are identified. || Document || SSP, config management policy, CCB minutes, security architecture engineering.
|-
| [d] identified architectural designs that promote effective information security are employed. || Artifact || CCB minutes, Network diagrams and configurations, Project Plans.
|-
| [e] identified software development techniques that promote effective information security are employed. || Artifact || CCB minutes, SDLC, code scanner results, code management tracking.
|-
| [f] identified systems engineering principles that promote effective information security are employed. || Artifact || CCB minutes, configuration management, ITSM, patch management, lifecycle replacement processes.
|}

=== SC.L2-3.13.3 – Role Separation ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.3_Details|'''SC.L2-3.13.3''']] Separate user functionality from system management functionality.
|-
| [a] user functionality is identified. || Document || SSP, AUP.
|-
| [b] system management functionality is identified. || Document || SSP, Privileged Account Agreement.
|-
| [c] user functionality is separated from system management functionality. || Screen Share || Active Directory, Jump Boxes, GPO, VM, RDP.
|}

=== SC.L2-3.13.4 – Shared Resource Control ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.4_Details|'''SC.L2-3.13.4''']] Prevent unauthorized and unintended information transfer via shared system resources.
|-
| [a] unauthorized and unintended information transfer via shared system resources is prevented. || Screen Share || SSP, OS configurations, Linux containers, system/media reuse policies, certificate management policies, media destruction policies, printer configs, VDI configuration.
|}

=== SC.L2-3.13.5 – Public-Access System Separation [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.5_Details|'''SC.L2-3.13.5''']] Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
|-
| [a] publicly accessible system components are identified. || Document || SSP, network diagram, DMZ inventory/roles.
|-
| [b] subnetworks for publicly accessible system components are physically or logically separated from internal networks. || Artifact || Network diagram, IPAM, VLAN, DHCP, DMZ.
|}

=== SC.L2-3.13.6 – Network Communication by Exception ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.6_Details|'''SC.L2-3.13.6''']] Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).
|-
| [a] network communications traffic is denied by default. || Screen Share || Host and network firewall rules, SIEM logs, hit counts.
|-
| [b] network communications traffic is allowed by exception. || Screen Share || Host and network firewall rules, SIEM logs, hit counts.
|}

=== SC.L2-3.13.7 – Split Tunneling ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.7_Details|'''SC.L2-3.13.7''']] Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling).
|-
| [a] remote devices are prevented from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks (i.e., split tunneling). || Screen Share || VPN appliance/server configuration, endpoint VPN software configuration.
|}

=== SC.L2-3.13.8 – Data in Transit ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.8_Details|'''SC.L2-3.13.8''']] Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.
|-
| [a] cryptographic mechanisms intended to prevent unauthorized disclosure of CUI are identified. || Document || SSP, PKI policies, configuration processes, config management, email attachment encryption policy, removable media policy, data at rest policy.
|-
| [b] alternative physical safeguards intended to prevent unauthorized disclosure of CUI are identified. || Document || SSP, physical security policy.
|-
| [c] either cryptographic mechanisms or alternative physical safeguards are implemented to prevent unauthorized disclosure of CUI during transmission. || Artifact || TLS settings, SSL settings, VPN/Wireless Access Points/Mobile Devices cryptographic settings, ODBC connector settings, SAN configuration, IPSec/MPLS, backup configuration, physical security.
|}

=== SC.L2-3.13.9 – Connections Termination ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.9_Details|'''SC.L2-3.13.9''']] Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity.
|-
| [a] a period of inactivity to terminate network connections associated with communications sessions is defined. || Document || SSP, network communications policy.
|-
| [b] network connections associated with communications sessions are terminated at the end of the sessions. || Screen Share || VPN appliance/server logs, VPN configurations, web server configurations, firewall connection settings.
|-
| [c] network connections associated with communications sessions are terminated after the defined period of inactivity. || Artifact || VPN appliance/server logs, VPN configurations, web server configurations, frewall connection settings.
|}

=== SC.L2-3.13.10 – Key Management ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.10_Details|'''SC.L2-3.13.10''']] Establish and manage cryptographic keys for cryptography employed in organizational systems.
|-
| [a] cryptographic keys are established whenever cryptography is employed. || Artifact || SSP, PKI/certificate management policy, configuration management.
|-
| [b] cryptographic keys are managed whenever cryptography is employed. || Artifact || SSP, PKI/certificate management policy, configuration management, access control policy.
|}

=== SC.L2-3.13.11 – CUI Encryption ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.11_Details|'''SC.L2-3.13.11''']] Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.
|-
| [a] FIPS-validated cryptography is employed to protect the confidentiality of CUI. || Screen Share || VPN, wireless, mobile devices, client certificates, server certificates, disk encryption, Outlook plugin, external mail, backup media, ePO server, removable storage, SAN, file compression; look for FIPS mode enabled on appliances.
|}

=== SC.L2-3.13.12 – Collaborative Device Control ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.12_Details|'''SC.L2-3.13.12''']] Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device.
|-
| [a] collaborative computing devices are identified. || Document || SSP, network diagrams.
|-
| [b] collaborative computing devices provide indication to users of devices in use. || Physical Review || Physical inspection of device.
|-
| [c] remote activation of collaborative computing devices is prohibited. || Screen Share || Collaboration device configuration/console.
|}

=== SC.L2-3.13.13 – Mobile Code ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.13_Details|'''SC.L2-3.13.13''']] Control and monitor the use of mobile code.
|-
| [a] use of mobile code is controlled. || Screen Share || GPO settings, malware protection, software agent configurations, software development policies, code scanners, MDM configuration, firewall/secure web gateway/proxy config.
|-
| [b] use of mobile code is monitored. || Screen Share || SIEM/console monitoring.
|}

=== SC.L2-3.13.14 – Voice over Internet Protocol ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.14_Details|'''SC.L2-3.13.14''']] Control and monitor the use of Voice over Internet Protocol (VoIP) technologies.
|-
| [a] use of Voice over Internet Protocol (VoIP) technologies is controlled. || Artifact || VLAN, ACL, firewall config, VoIP gateway/condenser configuration.
|-
| [b] use of Voice over Internet Protocol (VoIP) technologies is monitored. || Artifact || SIEM/VoIP console monitoring, session border controller.
|}

=== SC.L2-3.13.15 – Communications Authenticity ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.15_Details|'''SC.L2-3.13.15''']] Protect the authenticity of communications sessions.
|-
| [a] the authenticity of communications sessions is protected. || Screen Share || SSL, TLS, SMB3, SFTP, IPSec, SSH, Kerberos configs, MPLS, Network Access Control.
|}

=== SC.L2-3.13.16 – Data at Rest ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.16_Details|'''SC.L2-3.13.16''']] Protect the confidentiality of CUI at rest.
|-
| [a] the confidentiality of CUI at rest is protected. || Artifact || Full disk encryption, removable media encryption, SAN encryption, digital backups, mobile device encryption, third party offsite backup storage, cloud virtualization encryption, physical media storage policies.
|}

== System and Information Integrity (SI) ==
=== SI.L2-3.14.1 – Flaw Remediation [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.1_Details|'''SI.L2-3.14.1''']] Identify, report, and correct information and information system flaws in a timely manner.
|-
| [a] the time within which to identify system flaws is specified. || Document || SSP, patch management policy.
|-
| [b] system flaws are identified within the specified time frame. || Screen Share || Vulnerability management scanner output and scan policy configuration.
|-
| [c] the time within which to report system flaws is specified. || Document || SSP, patch management policy.
|-
| [d] system flaws are reported within the specified time frame. || Screen Share || ITSM/trouble tickets, vulnerability management scanner output.
|-
| [e] the time within which to correct system flaws is specified. || Document || SSP, patch management policy.
|-
| [f] system flaws are corrected within the specified time frame. || Screen Share || Vulnerability management scanner output and scan policy configuration.
|}

=== SI.L2-3.14.2 – Malicious Code ProTection [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.2_Details|'''SI.L2-3.14.2''']] Provide protection from malicious code at appropriate locations within organizational information systems.
|-
| [a] designated locations for malicious code protection are identified. || Document || SSP, system protection policy, network diagrams, security architecture documents.
|-
| [b] protection from malicious code at designated locations is provided. || Screen Share || Endpoint security settings, email/web proxy gateways, firewall, IPS sensor, MDM configuration, Network Access Control.
|}

=== SI.L2-3.14.3 – Security Alerts & Advisories ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.3_Details|'''SI.L2-3.14.3''']] Monitor system security alerts and advisories and take action in response.
|-
| [a] response actions to system security alerts and advisories are identified. || Document || SSP, vulnerability management policy, Incident Response Plan.
|-
| [b] system security alerts and advisories are monitored. || Artifact || Threat intelligence subscriptions, email advisories.
|-
| [c] actions in response to system security alerts and advisories are taken. || Artifact || ITSM/trouble tickets, user notifications, updates to firewall/IPS, etc.
|}

=== SI.L2-3.14.4 – Update Malicious Code Protection [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.4_Details|'''SI.L2-3.14.4''']] Update malicious code protection mechanisms when new releases are available.
|-
| [a] malicious code protection mechanisms are updated when new releases are available. || Screen Share || Antivirus console dashboard, firewall AV, Email gateway signatures,proxy, IPS updates.
|}

=== SI.L2-3.14.5 – System & File Scanning [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.5_Details|'''SI.L2-3.14.5''']] Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed.
|-
| [a] the frequency for malicious code scans is defined. || Document || SSP, vulnerability management policy.
|-
| [b] malicious code scans are performed with the defined frequency. || Screen Share || Consoles for AV (endpoints, servers, and file shares), firewall, email gateway, proxy, IPS, MDM configurations.
|-
| [c] real-time malicious code scans of files from external sources as files are downloaded, opened, or executed are performed. || Screen Share || Consoles for AV (endpoints, servers, and file shares), firewall, email gateway, proxy, IPS, MDM configurations.
|}

=== SI.L2-3.14.6 – Monitor Communications for Attacks ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.6_Details|'''SI.L2-3.14.6''']] Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.
|-
| [a] the system is monitored to detect attacks and indicators of potential attacks. || Screen Share || Firewall, IPS, endpoint protection, SIEM alerts and reports.
|-
| [b] inbound communications traffic is monitored to detect attacks and indicators of potential attacks. || Screen Share || Firewall, IPS, endpoint protection, SIEM alerts and reports.
|-
| [c] outbound communications traffic is monitored to detect attacks and indicators of potential attacks. || Screen Share || Firewall, IPS, endpoint protection, SIEM alerts and reports.
|}

=== SI.L2-3.14.7 – Identify Unauthorized Use ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.7_Details|'''SI.L2-3.14.7''']] Identify unauthorized use of organizational systems.
|-
| [a] authorized use of the system is defined. || Document || AUP, SSP.
|-
| [b] unauthorized use of the system is identified. || Artifact || SIEM logs, endpoint protection console, IPS, Firewall.
|}

Evidence Collection Approach

2026-07-20T01:48:42Z

David: /* SC.L2-3.13.9 – Connections Termination */

CMMC assessments and certification require substantial evidence and documentation. The following tables outline general guidelines for collecting evidence to assess control requirements and objectives. While these guidelines provide a structured approach, they are not the only means of conducting an accurate assessment. Assessors should exercise professional judgment and may employ alternative methods appropriate to the specific organizational context and circumstances.

Evidence collection approaches are defined as:
* '''Documentation''': Tangible materials containing information over which an organization has authority, including all types of written records and their copies.
* '''Artifacts''': Tangible, reviewable records directly resulting from a practice or process being performed by a system or by personnel executing their role within that practice, control, or process.
* '''Physical Review''': Direct on-site observation and examination of evidence.
* '''Screen Share''': Real-time remote observation of a user demonstrating a task or process via shared computer screen, sometimes called "over-the-shoulder" review.

DISCLAIMER: Evidence requirements vary significantly across assessment types. '''The examples provided are illustrative only and should be tailored to meet the specific adequacy and sufficiency standards of your particular assessment context.'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmctoolkit.org contact us]. Thank you.

== Access Control (AC) ==
=== AC.L2-3.1.1 – Authorized Access Control [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.1_Details|'''AC.L2-3.1.1''']] Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems).
|-
| [a] authorized users are identified. || Document || Document defining account request, approval, provisioning.
|-
| [b] processes acting on behalf of authorized users are identified. || Document || Document defining account request, approval, provisioning.
|-
| [c] devices (and other systems) authorized to connect to the system are identified. || Document || Document defining account request, approval, provisioning.
|-
| [d] system access is limited to authorized users. || Screen Share || Screen share showing login requirements are enforced. Example of an unauthorized user denied (unauthorized username entered at login).
|-
| [e] system access is limited to processes acting on behalf of authorized users. || Screen Share || Screenshot showing that service accounts are assigned to authorized users only; no rogue accounts without an authorized user are active.
|-
| [f] system access is limited to authorized devices (including other systems). || Screen Share || Screen share showing that all devices running are authorized; no rogue devices on the network.
|}

=== AC.L2-3.1.2 – Transaction & Function Control [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.2_Details|'''AC.L2-3.1.2''']] Limit information system access to the types of transactions and functions that authorized users are permitted to execute.
|-
| [a] the types of transactions and functions that authorized users are permitted to execute are defined. || Document || SSP, AUP, or IAM document that defines what authorized users can execute.
|-
| [b] system access is limited to the defined types of transactions and functions for authorized users. || Screen Share || Screenshot of security roles in AD or IAM or other directory-based identity-related services tool that shows transactions are as defined in the SSP or IAM document; privileged and non-privileged accounts need to be defined and identified in the artifact; screenshot of a non-privileged user trying to execute a privileged function.
|}

=== AC.L2-3.1.3 – Control CUI Flow ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.3_Details|'''AC.L2-3.1.3''']] Control the flow of CUI in accordance with approved authorizations.
|-
| [a] information flow control policies are defined. || Document || SSP or other document describing the control of CUI on the network.
|-
| [b] methods and enforcement mechanisms for controlling the flow of CUI are defined. || Document || Document that defines the networking devices that are on the CUI network and answers what measures are in place to control the flow. List of firewalls, border and internal layer 3 devices, IDS/IPS, DLP, that process CUI.
|-
| [c] designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified. || Artifact || Network diagram, data flow diagram, external system connection diagrams, document describing the policies for CUI on the network; listing of VLANs and subnets where CUI is authorized; document must describe source and authorized destinations.
|-
| [d] authorizations for controlling the flow of CUI are defined. || Document || Document that defines how CUI is to be controlled, such as an InfoSec plan, and/or network management plan.
|-
| [e] approved authorizations for controlling the flow of CUI are enforced. || Screen Share || Screenshots of firewall rules, ACLs, etc.
|}

=== AC.L2-3.1.4 – Separation of Duties ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.4_Details|'''AC.L2-3.1.4''']] Separate the duties of individuals to reduce the risk of malevolent activity without collusion.
|-
| [a] the duties of individuals requiring separation are defined. || Document || Document, SSP, account management policy, defining separation of duties by person or role.
|-
| [b] responsibilities for duties that require separation are assigned to separate individuals. || Screen Share || Screenshot showing that separation of duties is enforced by showing admin accounts are assigned to different people based on role.
|-
| [c] access privileges that enable individuals to exercise the duties that require separation are granted to separate individuals. || Screen Share || Screen shot showing an example such as a security manager can not log into a network device and change ACLs, or network admins can not access security logs in the SIEM tool.
|}

=== AC.L2-3.1.5 – Least Privilege ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.5_Details|'''AC.L2-3.1.5''']] Employ the principle of least privilege, including for specific security functions and privileged accounts.
|-
| [a] privileged accounts are identified. || Document || "SSP or policy (documentation) identify what is considered a privileged account."
|-
| [b] access to privileged accounts is authorized in accordance with the principle of least privilege. || Artifact || An artifact that identifies the least amount of permissions associated with different types of privileged accounts are approved.
|-
| [c] security functions are identified. || Document || "SSP or policy (documentation) identifies what is considered a security account."
|-
| [d] access to security functions is authorized in accordance with the principle of least privilege. || Artifact || Artifact(s) that identify the least amount of permissions associated with different types of security accounts are approved.
|}

=== AC.L2-3.1.6 – Non-Privileged Account Use ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.6_Details|'''AC.L2-3.1.6''']] Use non-privileged accounts or roles when accessing nonsecurity functions.
|-
| [a] nonsecurity functions are identified. || Document || SSP or account management document, AUP, that defines non-security functions.
|-
| [b] users are required to use non-privileged accounts or roles when accessing nonsecurity functions. || Screen Share || Screenshot showing that a privileged user tried to use their admin account to access a non-security function, such as a browser or email (whatever is defined in their policy) and was blocked.
|}

=== AC.L2-3.1.7 – Privileged Functions ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.7_Details|'''AC.L2-3.1.7''']] Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.
|-
| [a] privileged functions are defined. || Document || SSP or policy (documentation) that defines privileged functions.
|-
| [b] non-privileged users are defined. || Document || SSP or policy (documentation) that defines non-privileged users.
|-
| [c] non-privileged users are prevented from executing privileged functions. || Screen Share || Screen share that shows that a non-privileged user is not allowed to complete a privileged function (installing software).
|-
| [d] the execution of privileged functions is captured in audit logs. || Screen Share || Screen share that shows logs being captured of the execution of privileged functions.
|}

=== AC.L2-3.1.8 – Unsuccessful Logon Attempts ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.8_Details|'''AC.L2-3.1.8''']] Limit unsuccessful logon attempts.
|-
| [a] the means of limiting unsuccessful logon attempts is defined. || Document || SSP or policy (documentation) showing unsuccessful logon attempts settings and or policy.
|-
| [b] the defined means of limiting unsuccessful logon attempts is implemented. || Artifact || Artifact showing GPO / Policy for limiting logon attempts.
|}

=== AC.L2-3.1.9 – Privacy & Security Notices ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.9_Details|'''AC.L2-3.1.9''']] Provide privacy and security notices consistent with applicable CUI rules.
|-
| [a] privacy and security notices required by CUI-specified rules are identified, consistent, and associated with the specific CUI category. || Document || SSP or policy (documentation) showing CUI-specified rules are identified, consistent, and associated with the specific CUI category.
|-
| [b] privacy and security notices are displayed. || Artifact || Artifact that shows a consent banner or screen that a user sees as they log in to the system.
|}

=== AC.L2-3.1.10 – Session Lock ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.10_Details|'''AC.L2-3.1.10''']] Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity.
|-
| [a] the period of inactivity after which the system initiates a session lock is defined. || Document || SSP or policy (documentation) that defines the period of inactivity and when a session lock is defined.
|-
| [b] access to the system and viewing of data is prevented by initiating a session lock after the defined period of inactivity. || Artifact || Artifact that shows the setting of session lock (GPO or system policy or similar solution addressing the controls supporting centralized management and configuration of operating systems, applications, and users' settings for the working environment of user accounts and computer accounts).
|-
| [c] previously visible information is concealed via a pattern-hiding display after the defined period of inactivity. || Document || Screenshot of GPO setting and configuration settings, or similar solution addressing the controls supporting centralized management and configuration of operating systems, applications, and users' settings for the working environment of user accounts and computer accounts.
|}

=== AC.L2-3.1.11 – Session Termination ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.11_Details|'''AC.L2-3.1.11''']] Terminate (automatically) a user session after a defined condition.
|-
| [a] conditions requiring a user session to terminate are defined. || Document || SSP or policy (documentation) that defines the conditions requiring a user session to be terminated.
|-
| [b] a user session is automatically terminated after any of the defined conditions. || Screen Share || Screen share showing GPO / VPN Settings that show when a session would be terminated (Idle time, max connection time).
|}

=== AC.L2-3.1.12 – Control Remote Access ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.12_Details|'''AC.L2-3.1.12''']] Monitor and control remote access sessions.
|-
| [a] remote access sessions are permitted. || Document || SSP or policy (documentation) that defines remote access sessions.
|-
| [b] the types of permitted remote access are identified. || Document || SSP or policy (documentation) that defines remote access is permitted.
|-
| [c] remote access sessions are controlled. || Screen Share || Screen share that shows how the remote access is controlled (access session, and or groups).
|-
| [d] remote access sessions are monitored. || Screen Share || Screen share that shows how remote sessions are monitored (logs).
|}

=== AC.L2-3.1.13 – Remote Access Confidentiality ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.13_Details|'''AC.L2-3.1.13''']] Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.
|-
| [a] cryptographic mechanisms to protect the confidentiality of remote access sessions are identified. || Document || SSP or policy (documentation) that discusses the CUI rules, consistent, and associated with the specific CUI category; FIPS Cert # of appliance or application.
|-
| [b] cryptographic mechanisms to protect the confidentiality of remote access sessions are implemented. || Screen Share || Screenshot of VPN concentration that shows encryption is on and enabled (point-to-point, etc.).
|}

=== AC.L2-3.1.14 – Remote Access Routing ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.14_Details|'''AC.L2-3.1.14''']] Route remote access via managed access control points.
|-
| [a] managed access control points are identified and implemented. || Screen Share || Screen share that shows access control points (groups and/or users).
|-
| [b] remote access is routed through managed network access control points. || Screen Share || Screen share that shows access control points and how they are managed.
|}

=== AC.L2-3.1.15 – Privileged Remote Access ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.15_Details|'''AC.L2-3.1.15''']] Authorize remote execution of privileged commands and remote access to security-relevant information.
|-
| [a] privileged commands authorized for remote execution are identified. || Document || SSP or policy (documentation) that defines what is authorized to be executed remotely and how that is handled.
|-
| [b] security-relevant information authorized to be accessed remotely is identified. || Document || SSP or policy (documentation) that defines what can be accessed remotely and what procedures are implemented to allow this (RDP, jump box).
|-
| [c] the execution of the identified privileged commands via remote access is authorized. || Artifact || Screen share that shows who has access to perform privileged commands a remotely (access groups for privileged accounts).
|-
| [d] access to the identified security-relevant information via remote access is authorized. || Artifact || Screen share that shows the routing of remote access and how it is monitored and how many locations (Firewall, VPN Concentrator).
|}

=== AC.L2-3.1.16 – Wireless Access Authorization ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.16_Details|'''AC.L2-3.1.16''']] Authorize wireless access prior to allowing such connections.
|-
| [a] wireless access points are identified. || Document || SSP, network administration document.
|-
| [b] wireless access is authorized prior to allowing such connections. || Screen Share || Authorization profile(s) in Wireless Access Controller or Identity Manager (i.e. Cisco ISE).
|}

=== AC.L2-3.1.17 – Wireless Access Protection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.17_Details|'''AC.L2-3.1.17''']] Protect wireless access using authentication and encryption.
|-
| [a] wireless access to the system is protected using authentication. || Screen Share || Security page (or similar) of a Wireless Access Controller.
|-
| [b] wireless access to the system is protected using encryption. || Screen Share || Security page (or similar) of a Wireless Access Controller.
|}

=== AC.L2-3.1.18 – Mobile Device Connection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.18_Details|'''AC.L2-3.1.18''']] Control connection of mobile devices.
|-
| [a] mobile devices that process, store, or transmit CUI are identified. || Document || SSP, Mobile Device Policy.
|-
| [b] mobile device connections are authorized. || Artifact || Authorization profile(s) in Wireless Access Controller or Identity Manager (i.e. Cisco ISE).
|-
| [c] mobile device connections are monitored and logged. || Screen Share || Mobile device logs within the MDM, log intake (sources) configuration (within SIEM) showing MDM is feeding logs to the SIEM.
|}

=== AC.L2-3.1.19 – Encrypt CUI on Mobile ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.19_Details|'''AC.L2-3.1.19''']] Encrypt CUI on mobile devices and mobile computing platforms.
|-
| [a] mobile devices and mobile computing platforms that process, store, or transmit CUI are identified. || Document || SSP, Mobile Device Policy.
|-
| [b] encryption is employed to protect CUI on identified mobile devices and mobile computing platforms. || Screen Share || Security policy page in MDM showing how encryption are enforced on mobile device. If no MDM or MDM doesn't enforce encryption, then validate if the devices used are on the list of devices with native FIPS approved validation.
|}

=== AC.L2-3.1.20 – External Connections [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.20_Details|'''AC.L2-3.1.20''']] Verify and control/limit connections to and use of external information systems.
|-
| [a] connections to external systems are identified. || Document || SSP, Systems Interconnection Agreements, SLA.
|-
| [b] the use of external systems is identified. || Document || SSP, Systems Interconnection Agreements, SLA.
|-
| [c] connections to external systems are verified. || Artifact || SLA for external systems, memorandum for interconnection, information to prove that any cloud solution is at FedRAMP impact level of moderate or higher (i.e. license information, screenshot of AWS cloud dashboard, purchase order document).
|-
| [d] the use of external systems is verified. || Artifact || SLA for external systems, memorandum for interconnection, information to prove that any cloud solution is at FedRAMP impact level of moderate or higher (i.e. license information, screenshot of AWS cloud dashboard, purchase order document).
|-
| [e] connections to external systems are controlled/limited. || Screen Share || Firewall ruleset for controlling access to cloud service or external system.
|-
| [f] the use of external systems is controlled/limited. || Screen Share || Firewall ruleset for controlling access to cloud service or external system.
|}

=== AC.L2-3.1.21 – Portable Storage Use ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.21_Details|'''AC.L2-3.1.21''']] Limit use of portable storage devices on external systems.
|-
| [a] the use of portable storage devices containing CUI on external systems is identified and documented. || Document || SSP, Removable Media Policy, Acceptable Use Policy (with emphasis on portable media use).
|-
| [b] limits on the use of portable storage devices containing CUI on external systems are defined. || Document || SSP, Removable Media Policy, Acceptable Use Policy (with emphasis on portable media use).
|-
| [c] the use of portable storage devices containing CUI on external systems is limited as defined. || Document || SSP, Removable Media Policy, Acceptable Use Policy (with emphasis on portable media use).
|}

=== AC.L2-3.1.22 – Control Public Information [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.22_Details|'''AC.L2-3.1.22''']] Control information posted or processed on publicly accessible information systems.
|-
| [a] individuals authorized to post or process information on publicly accessible systems are identified. || Document || SSP, Website Governance Plan, Information Release Document.
|-
| [b] procedures to ensure CUI is not posted or processed on publicly accessible systems are identified. || Document || SSP, Website Governance Plan, Information Release Document.
|-
| [c] a review process is in place prior to posting of any content to publicly accessible systems. || Artifact || "Information release approval process, i.e. chain of email communication from originator, approver, and final decision (may or may not include individual authorized to post);
SharePoint/electronic or paper form/ ticket system showing information flow between requestor and approver (may or may not include individual authorized to post)."
|-
| [d] content on publicly accessible systems is reviewed to ensure that it does not include CUI. || Artifact || Incident response process, web design/update/modification SOP etc.
|-
| [e] mechanisms are in place to remove and address improper posting of CUI. || Artifact || Incident response process, web design/update/modification SOP etc.
|}

== Awareness and Training (AT) ==
=== AT.L2-3.2.1 – Role-Based Risk Awareness ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AT.L2-3.2.1_Details|'''AT.L2-3.2.1''']] Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems.
|-
| [a] security risks associated with organizational activities involving CUI are identified. || Document || Policy of Security Awareness Training; Security Awareness Training Briefing.
|-
| [b] policies, standards, and procedures related to the security of the system are identified. || Document || Acceptable Use Policy, Policy/Procedures/Instruction related to the security of the system.
|-
| [c] managers, systems administrators, and users of the system are made aware of the security risks associated with their activities. || Artifact || Security Training Brief, training records.
|-
| [d] managers, systems administrators, and users of the system are made aware of the applicable policies, standards, and procedures related to the security of the system. || Artifact || Policies, standards and procedures for employees within training (completed training report).
|}

=== AT.L2-3.2.2 – Role-Based Training ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AT.L2-3.2.2_Details|'''AT.L2-3.2.2''']] Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities.|-
|-
| [a] information security-related duties, roles, and responsibilities are defined. || Document || Policy/Procedures/Instruction, Job Role Matrix, Position Descriptions, User Roles.
|-
| [b] information security-related duties, roles, and responsibilities are assigned to designated personnel. || Artifact || Screenshot of breakout of different roles/permissions assigned to individuals (i.e. ActiveDirectory); Privilege Access Agreement.
|-
| [c] personnel are adequately trained to carry out their assigned information security-related duties, roles, and responsibilities. || Artifact || Screenshot of tool and/or training specifying security specific roles, duties and responsibilities; Screenshot of required certifications (i.e. Sec+, CISSP).
|}

=== AT.L2-3.2.3 – Insider Threat Awareness ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AT.L2-3.2.3_Details|'''AT.L2-3.2.3''']] Provide security awareness training on recognizing and reporting potential indicators of insider threat.
|-
| [a] potential indicators associated with insider threats are identified. || Document || Insidert Threat Policy/Procedures/Instruction; Insider Threat Training/Briefing.
|-
| [b] security awareness training on recognizing and reporting potential indicators of insider threat is provided to managers and employees. || Artifact || Screenshot of training records showing completion of Insider Threat training, emails showing completion of Insider Threat training, Screenshot of certificate showing completion with individual's name.
|}

== Audit and Accountability (AU) ==
=== AU.L2-3.3.1 – System Auditing ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.1_Details|'''AU.L2-3.3.1''']] Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.
|-
| [a] audit logs needed (i.e., event types to be logged) to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity are specified. || Document || SSP, policy, or auditing and logging process that defines specific types of events to be logged.
|-
| [b] the content of audit records needed to support monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity is defined. || Document || SSP, policy, or auditing and logging process that defines specific content of audit records/files.
|-
| [c] audit records are created (generated). || Screen Share || Screen share of tool that shows logs are generated for all systems.
|-
| [d] audit records, once created, contain the defined content. || Screen Share || Screen share of tool that shows logs contain defined content as defined in SSP, policy, or procedures.
|-
| [e] retention requirements for audit records are defined. || Document || SSP, Polocy, or Auditing and logging process that describes how long records are kept.
|-
| [f] audit records are retained as defined. || Screen Share || Screen share of tool that shows records and audit content retained at a minimum as defined.
|}

=== AU.L2-3.3.2 – User Accountability ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.2_Details|'''AU.L2-3.3.2''']] Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions.
|-
| [a] the content of the audit records needed to support the ability to uniquely trace users to their actions is defined. || Document || SSP, policy, or process that defines actions traced back to individuals.
|-
| [b] audit records, once created, contain the defined content. || Screen Share || Screen share of tool that shows audit records traced to specific users/roles.
|}

=== AU.L2-3.3.3 – Event Review ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.3_Details|'''AU.L2-3.3.3''']] Review and update logged events.
|-
| [a] a process for determining when to review logged events is defined. || Document || SSP, policy, or documented process that shows frequency of when to review types of logged events.
|-
| [b] event types being logged are reviewed in accordance with the defined review process. || Artifact || Evidence through a documented method such as meeting minutes, CAB minutes, etc. of log sources and log events being logged at the defined frequency.
|-
| [c] event types being logged are updated based on the review. || Artifact || Evidence of implementation based on the results of the review of logged events/sources through a ticket, meeting minutes, or screen share of the tool that shows changes implemented (finetuning).
|}

=== AU.L2-3.3.4 – Audit Failure Alerting ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.4_Details|'''AU.L2-3.3.4''']] Alert in the event of an audit logging process failure.
|-
| [a] personnel or roles to be alerted in the event of an audit logging process failure are identified. || Document || SSP, policy, or procedure that shows who needs to be notified in case of an audit failure.
|-
| [b] types of audit logging process failures for which alert will be generated are defined. || Document || SSP, policy, or procedure that shows what types of failure will generate notifications.
|-
| [c] identified personnel or roles are alerted in the event of an audit logging process failure. || Artifact || Artifact such as email or ticket that shows the identified personnel were alerted of any audit/logging process failure as defined.
|}

=== AU.L2-3.3.5 – Audit Correlation ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.5_Details|'''AU.L2-3.3.5''']] Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.
|-
| [a] audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity are defined. || Document || SSP, policy, or procedure covering audit logging, monitoring, and reporting.
|-
| [b] defined audit record review, analysis, and reporting processes are correlated. || Artifact || Artifact showing an audit event and the resultant corrective action or actions to the event; this can be a Help Desk ticket, meeting notes, or a change control board items showing the event and any corrective action taken.
|}

=== AU.L2-3.3.6 – Reduction & Reporting ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.6_Details|'''AU.L2-3.3.6''']] Provide audit record reduction and report generation to support on-demand analysis and reporting.
|-
| [a] an audit record reduction capability that supports on-demand analysis is provided. || Screen Share || Screen share of the logging environment where an event can be selected and traced back to a specific device, or dashboard showing realtime event analysis.
|-
| [b] a report generation capability that supports on-demand reporting is provided. || Screen Share || Screen share showing the generation of an on demand report.
|}

=== AU.L2-3.3.7 – Authoritative Time Source ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.7_Details|'''AU.L2-3.3.7''']] Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.
|-
| [a] internal system clocks are used to generate time stamps for audit records. || Screen Share || Screen share showing the NTP settings of a windows, Unix, Linux device; a screen share showing the NTP settings of network appliances.
|-
| [b] an authoritative source with which to compare and synchronize internal system clocks is specified. || Document || SSP or policy indicating that devices need to be synched to a local authoritative time device that is synched with an authoritative time service.
|-
| [c] internal system clocks used to generate time stamps for audit records are compared to and synchronized with the specified authoritative time source. || Screen Share || Screen share showing device logging appliance time is point to the appropriate authoritative time server.
|}

=== AU.L2-3.3.8 – Audit Protection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.8_Details|'''AU.L2-3.3.8''']] Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
|-
| [a] audit information is protected from unauthorized access. || Screen Share || Screen share showing operating system permissions on the audit folders being restricted to appropriate users.
|-
| [b] audit information is protected from unauthorized modification. || Screen Share || Screen share showing operating system permissions on the audit folders being restricted to appropriate users.
|-
| [c] audit information is protected from unauthorized deletion. || Screen Share || Screen share showing operating system permissions on the audit folders being restricted to appropriate users.
|-
| [d] audit logging tools are protected from unauthorized access. || Screen Share || Artifact showing access permissions in the SIEM tool.
|-
| [e] audit logging tools are protected from unauthorized modification. || Screen Share || Artifact showing update permissions in the SIEM tool.
|-
| [f] audit logging tools are protected from unauthorized deletion. || Screen Share || Artifact showing delete permissions in the SIEM tool.
|}

=== AU.L2-3.3.9 – Audit Management ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.9_Details|'''AU.L2-3.3.9''']] Limit management of audit logging functionality to a subset of privileged users.
|-
| [a] a subset of privileged users granted access to manage audit logging functionality is defined. || Document || SSP or policy indicating which users or groups have access to audit logs.
|-
| [b] management of audit logging functionality is limited to the defined subset of privileged users. || Screen Share || Artifact showing SIEM or OS folder permissions (this should be limited to the assigned users or groups); artifact showing an ACL setting in SIEM tool in regards to logs.
|}

== Configuration Management (CM) ==
=== CM.L2-3.4.1 – System Baselining ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.1_Details|'''CM.L2-3.4.1''']] Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.
|-
| [a] a baseline configuration is established. || Document || Documentation showing or explaining standard imaging process (how standard images are deployed and where they are stored).
|-
| [b] the baseline configuration includes hardware, software, firmware, and documentation. || Artifact || Screenshot of repository of where images are maintained and information relating to hardware, software, and firmware.
|-
| [c] the baseline configuration is maintained (reviewed and updated) throughout the system development life cycle. || Artifact || Screenshot/evidence displaying management of baseline configurations (how often they are being managed as stated).
|-
| [d] a system inventory is established. || Document || Screenshot/evidence displaying inventory listing of approved products for use.
|-
| [e] the system inventory includes hardware, software, firmware, and documentation. || Artifact || Screeenshot/evidence displaying inventory listing of approved products and versions permitted for use.
|-
| [f] the inventory is maintained (reviewed and updated) throughout the system development life cycle. || Artifact || Screeenshot/evidence displaying management of baseline configurations (How often and are they being managed as stated.
|}

=== CM.L2-3.4.2 – Security Configuration Enforcement ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.2_Details|'''CM.L2-3.4.2''']] Establish and enforce security configuration settings for information technology products employed in organizational systems.
|-
| [a] security configuration settings for information technology products employed in the system are established and included in the baseline configuration. || Document || Documentation explaining methodology used by organization to create secure baselines (STIGs, benchmarks).
|-
| [b] security configuration settings for information technology products employed in the system are enforced. || Artifact || Evidence of tool/s used to enforce security configurations to ensure images used are free from modification unless authorized.
|}

=== CM.L2-3.4.3 – System Change Management ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.3_Details|'''CM.L2-3.4.3''']] Track, review, approve or disapprove, and log changes to organizational systems.
|-
| [a] changes to the system are tracked. || Artifact || Evidence of IT Service Management tool / process used to track system changes.
|-
| [b] changes to the system are reviewed. || Artifact || Evidence of IT Service Management tool / process used to review system changes.
|-
| [c] changes to the system are approved or disapproved. || Artifact || Evidence of IT Service Management tool / process used to approve/disapprove system changes.
|-
| [d] changes to the system are logged. || Artifact || Evidence of IT Service Management tool / process used to log system changes.
|}

=== CM.L2-3.4.4 – Security Impact Analysis ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.4_Details|'''CM.L2-3.4.4''']] Analyze the security impact of changes prior to implementation.
|-
| [a] the security impact of changes to the system is analyzed prior to implementation. || Artifact || Document explaining that security impact analysis of proposed changes to a system is conducted prior to implementation.
|}

=== CM.L2-3.4.5 – Access Restrictions for Change ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.5_Details|'''CM.L2-3.4.5''']] Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.
|-
| [a] physical access restrictions associated with changes to the system are defined. || Document || Document explaining the process of how physical access restrictions are defined for an individuals ability to make system changes.
|-
| [b] physical access restrictions associated with changes to the system are documented. || Document || Document explaining the process of how physical access restrictions are defined for an individuals ability to make system changes are documented; access request process.
|-
| [c] physical access restrictions associated with changes to the system are approved. || Artifact || Evidence of process of how physical access to systems are granted (i.e. physical access request sample).
|-
| [d] physical access restrictions associated with changes to the system are enforced. || Physical Review || Evidence of process of how physical access to systems are enforced (physical access system).
|-
| [e] logical access restrictions associated with changes to the system are defined. || Document || Document explaining the process of how logical access restrictions are defined for an individual's ability to make system changes.
|-
| [f] logical access restrictions associated with changes to the system are documented. || Document || Document explaining the process of how logical access restrictions are defined for an individual's ability to make system changes are documented.
|-
| [g] logical access restrictions associated with changes to the system are approved. || Artifact || Evidence of process of how logical access to systems are granted.
|-
| [h] logical access restrictions associated with changes to the system are enforced. || Artifact || Evidence of process of how logical access to systems are enforced.
|}

=== CM.L2-3.4.6 – Least Functionality ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.6_Details|'''CM.L2-3.4.6''']] Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.
|-
| [a] essential system capabilities are defined based on the principle of least functionality. || Document || Documentation explaining how systems are configured to utilize the principle of least functionality for designated users.
|-
| [b] the system is configured to provide only the defined essential capabilities. || Screen Share || Evidence displaying how systems are configured to utilize the principle of least functionality for designated users; disabled service settings, accepted standards for hardening (CIS benchmarks, etc.).
|}

=== CM.L2-3.4.7 – Nonessential Functionality ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.7_Details|'''CM.L2-3.4.7''']] Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.
|-
| [a] essential programs are defined. || Document || Documented essential programs specified; build documents; software center; SSP.
|-
| [b] the use of nonessential programs is defined. || Document || Documented listing of nonessential programs (whatever is NOT specified in [a]); AUP/User Agreement may identify nonessential use/programs.
|-
| [c] the use of nonessential programs is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict nonessential programs displays restrictions as defined (McAfee ePO settings, Carbon Black rules, etc.).
|-
| [d] essential functions are defined. || Document || Documented essential functions are specified.
|-
| [e] the use of nonessential functions is defined. || Document || Documented nonessential functions are specified.
|-
| [f] the use of nonessential functions is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict essential/nonessential functions displays restrictions as defined.
|-
| [g] essential ports are defined. || Document || Documented essential ports are specified.
|-
| [h] the use of nonessential ports is defined. || Document || Documented nonessential ports functions are specified.
|-
| [i] the use of nonessential ports is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict essential/nonessential ports displays restrictions as defined (FW rules; McAfee; GPO, etc.).
|-
| [j] essential protocols are defined. || Document || Documented essential protocols are specified.
|-
| [k] the use of nonessential protocols is defined. || Document || Documented nonessential protocols functions are specified.
|-
| [l] the use of nonessential protocols is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict essential/nonessential protocols displays restrictions as defined (FW rules; GPO, etc.).
|-
| [m] essential services are defined. || Document || Documented essential services specified.
|-
| [n] the use of nonessential services is defined. || Document || Documented nonessential services functions are specified.
|-
| [o] the use of nonessential services is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict essential/nonessential services displays restrictions as defined.
|}

=== CM.L2-3.4.8 – Application Execution Policy ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.8_Details|'''CM.L2-3.4.8''']] Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.
|-
| [a] a policy specifying whether whitelisting or blacklisting is to be implemented is specified. || Document || Documentation explaining whitelisting or blacklisting process.
|-
| [b] the software allowed to execute under whitelisting or denied use under blacklisting is specified. || Document || Documentation explaining whitelisting or blacklisting process for software.
|-
| [c] whitelisting to allow the execution of authorized software or blacklisting to prevent the use of unauthorized software is implemented as specified. || Screen Share || Tool used for whitelisting or blacklisting for software shows capability of restricting/authorizing software (Carbon Black dashboard, "SW Store", web proxies, DNS Blackhole, etc.).
|}

=== CM.L2-3.4.9 – User-Installed Software ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.9_Details|'''CM.L2-3.4.9''']] Control and monitor user-installed software.
|-
| [a] a policy for controlling the installation of software by users is established. || Document || Documented software authorization process or methodology for approval.
|-
| [b] installation of software by users is controlled based on the established policy. || Screen Share || Evidence that approval/restriction in installation of software by authorized personnel is implemented as specified (AUP, GPO, etc.).
|-
| [c] installation of software by users is monitored. || Screen Share || Evidence that installation of software by authorized personnel is monitored (SCCM groups, SW Center, etc.).
|}

== Identification and Authentication (IA) ==
=== IA.L2-3.5.1 – Identification [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.1_Details|'''IA.L2-3.5.1''']] Identify information system users, processes acting on behalf of users, or devices.
|-
| [a] system users are identified. || Document || Based on what is defined in their documentation (SSP, AUP, Policy, SOP), request to see a sample of non-privileged/privileged users in AD OU group (overlaps with 3.1.1 and 3.1.5).
|-
| [b] processes acting on behalf of users are identified. || Document || Based on what is defined in their documentation (SSP, AUP, Policy, SOP), request to see a sample of service accounts in AD OU group (overlaps with 3.1.1 and 3.1.5).
|-
| [c] devices accessing the system are identified. || Document || Based on what is defined in their documentation (SSP, AUP, Policy, SOP), request to see a sample of domain-joined workstation & servers in AD OU group (overlaps with 3.1.1 and 3.1.5). For network devices, request screen share/artifact to show how they are identified on the enterprise network.
|}

=== IA.L2-3.5.2 – Authentication [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.2_Details|'''IA.L2-3.5.2''']] Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems.
|-
| [a] the identity of each user is authenticated or verified as a prerequisite to system access. || Screen Share || If the user logs in with non-privileged account during other demoes and then a privileged account, then this should be satisfied. If screen share is unavailable, request logs to show successful and unsuccessful login by privileged and non-privilged users.
|-
| [b] the identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access. || Screen Share || Request a log that shows successful/unsuccessful service account trying to log on to company's asset.
|-
| [c] the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access. || Screen Share || Request a log that shows domain-joined workstation/server authenticating to AD (focus on the MAC/IP address/hostname).
|}

=== IA.L2-3.5.3 – Multifactor Authentication ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.3_Details|'''IA.L2-3.5.3''']] Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
|-
| [a] privileged accounts are identified. || Document || Based on what is defined in their documentation, request to see a sample of privileged users in AD OU group. Overlaps with 3.1.5. Screenshot/screen share to show implementation is enforced.
|-
| [b] multifactor authentication is implemented for local access to privileged accounts. || Screen Share || SSP, AUP, Policy, SOP that defines that MFA is needed for privileged local access.
|-
| [c] multifactor authentication is implemented for network access to privileged accounts. || Screen Share || Within the MFA implementation mechanism, show that privileged users are forced to use MFA; Screenshot/Screen share to show implementation is enforced.
|-
| [d] multifactor authentication is implemented for network access to non-privileged accounts. || Screen Share || Within the MFA implementation mechanism, show that non-privileged users are forced to use MFA; Screenshot/Screen share to show implementation is enforced.
|}

=== IA.L2-3.5.4 – Replay-Resistant Authentication ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.4_Details|'''IA.L2-3.5.4''']] Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.
|-
| [a] replay-resistant authentication mechanisms are implemented for network account access to privileged and non-privileged accounts. || Screen Share || Show the GPO setting that enforces Kerberos within AD. If MFA is used, show the implementation to enforce replay resistant techniques. For non-windows, show the technical solution to enforce replay resistant attacks.
|}

=== IA.L2-3.5.5 – Identifier Reuse ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.5_Details|'''IA.L2-3.5.5''']] Prevent reuse of identifiers for a defined period.
|-
| [a] a period within which identifiers cannot be reused is defined. || Document || SSP, policies, or SOP that defines identifier reuse.
|-
| [b] reuse of identifiers is prevented within the defined period. || Artifact || Show the GPO setting/technical solution that enforces what is defined in policy/documentation (this can be automated or manual process; screen share/artifacts can be presented to satisfy this requirement.
|}

=== IA.L2-3.5.6 – Identifier Handling ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.6_Details|'''IA.L2-3.5.6''']] Disable identifiers after a defined period of inactivity.
|-
| [a] a period of inactivity after which an identifier is disabled is defined. || Document || SSP, policy that defines the period of inactivity after which an identifier is disabled.
|-
| [b] identifiers are disabled after the defined period of inactivity. || Artifact || Screen share AD or similar tool supporting directory-based identity-related services for disabled accounts (can be done by hand or script).
|}

=== IA.L2-3.5.7 – Password Complexity ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.7_Details|'''IA.L2-3.5.7''']] Enforce a minimum password complexity and change of characters when new passwords are created.
|-
| [a] password complexity requirements are defined. || Document || SSP, policy that defines password complexity requirements.
|-
| [b] password change of character requirements are defined. || Document || SSP, policy that defines change of character requirements are defined.
|-
| [c] minimum password complexity requirements as defined are enforced when new passwords are created. || Screen Share || Screen share of AD or similar directory-based identity-related service tool to show complexity requirements.
|-
| [d] minimum password change of character requirements as defined are enforced when new passwords are created. || Screen Share || Screen share of Group Policy configuration or similar tool providing centralized management and configuration of operating systems, applications, and users' settings to show that characters must be changed.
|}

=== IA.L2-3.5.8 – Password Reuse ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.8_Details|'''IA.L2-3.5.8''']] Prohibit password reuse for a specified number of generations.
|-
| [a] the number of generations during which a password cannot be reused is specified. || Document || SSP, policy that specifies the number of generations during which a password cannot be reused is specified.
|-
| [b] reuse of passwords is prohibited during the specified number of generations. || Screen Share || Screen share Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration to show reuse of passwords is prohibited.
|}

=== IA.L2-3.5.9 – Temporary Passwords ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.9_Details|'''IA.L2-3.5.9''']] Allow temporary password use for system logons with an immediate change to a permanent password.
|-
| [a] an immediate change to a permanent password is required when a temporary password is used for system logon. || Screen Share || Screen share of Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration to show "change password at first logon."
|}

=== IA.L2-3.5.10 – Cryptographically-Protected Passwords ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.1_Details|'''IA.L2-3.5.1''']] Store and transmit only cryptographically-protected passwords.
|-
| [a] passwords are cryptographically protected in storage. || Screen Share || Screen share Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration that Kerberos, or a similar network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner, is enabled.
|-
| [b] passwords are cryptographically protected in transit. || Screen Share || Screen share Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration that Kerberos, or a similar network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner, is enabled.
|}

=== IA.L2-3.5.11 – Obscure Feedback ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.10_Details|'''IA.L2-3.5.10''']] Obscure feedback of authentication information.
|-
| [a] authentication information is obscured during the authentication process. || Screen Share || Screen share of Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration to show that passwords are obscured.
|}

== Incident Response (IR) ==
=== IR.L2-3.6.1 – Incident Handling ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IR.L2-3.6.1_Details|'''IR.L2-3.6.1''']] Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.
|-
| [a] an operational incident-handling capability is established. || Document || Incident Response SOP/Plan.
|-
| [b] the operational incident-handling capability includes preparation. || Document || Incident Response SOP/Plan, prior incident report, training, COOP plan.
|-
| [c] the operational incident-handling capability includes detection. || Document || Incident Response SOP/Plan; definition of tools used to detect; artifacts showing tools used; prior incident report.
|-
| [d] the operational incident-handling capability includes analysis. || Document || Incident Response SOP/Plan; Definition of tools used to analyze potential incidents; artifacts showing tools used for analysis; prior incident report.
|-
| [e] the operational incident-handling capability includes containment. || Document || Incident Response SOP/Plan; isolation/quarantine process; user training.
|-
| [f] the operational incident-handling capability includes recovery. || Document || Incident Response SOP/Plan; COOP Plan; prior incident reports, re-baselining impacted devices.
|-
| [g] the operational incident-handling capability includes user response. || Document || Incident Response SOP/Plan; user awareness training; Help Desk process.

|}

=== IR.L2-3.6.2 – Incident Reporting ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IR.L2-3.6.2_Details|'''IR.L2-3.6.2''']] Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.
|-
| [a] incidents are tracked. || Artifact || Incident Response SOP/Plan; ITSM artifact; technical implementation for incident tracking.
|-
| [b] incidents are documented. || Artifact || Incident Response SOP/Plan; ITSM artifact; technical implementation for incident tracking.
|-
| [c] authorities to whom incidents are to be reported are identified. || Document || Incident Response SOP/Plan.
|-
| [d] organizational officials to whom incidents are to be reported are identified. || Document || Incident Response SOP/Plan.
|-
| [e] identified authorities are notified of incidents. || Screen Share || Prior incident report; DIBNET login; prior email notifications.
|-
| [f] identified organizational officials are notified of incidents. || Artifact || Prior incident report; prior email notifications; tabletop exercises.
|}

=== IR.L2-3.6.3 – Incident Response Testing ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IR.L2-3.6.3_Details|'''IR.L2-3.6.3''']] Test the organizational incident response capability.
|-
| [a] the incident response capability is tested. || Artifact || Incident response table top/scheduled or unscheduled test or penetration test.
|}

== Maintenance (MA) ==
=== MA.L2-3.7.1 – Perform Maintenance ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.1_Details|'''MA.L2-3.7.1''']] Perform maintenance on organizational systems.
|-
| [a] system maintenance is performed. || Artifact || Establish typical maintenance activities (HVAC, UPS, power distribution, generators, copier maintenance) that are performed; maintenance agreements or contracts detailing these types of activities are acceptable; interview responses should be considered. This requirement should not be confused with 3.14.1 - report, remediate, and correct system flaws in a timely manner (patch management).
|}

=== MA.L2-3.7.2 – System Maintenance Control ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.2_Details|'''MA.L2-3.7.2''']] Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance.
|-
| [a] tools used to conduct system maintenance are controlled. || Artifact || Tools may largely depend on the assessed environment; discussion examples include network diagnostic and monitoring tools (including hardware and software); artifacts could demonstrate secured locations/areas for these tools (photos) or checkout sheets/rosters (documents) depicting responsible personnel and the dates/times of checkout.
|-
| [b] techniques used to conduct system maintenance are controlled. || Artifact || Processes for scheduling, performing, documenting, reviewing, approving, and monitoring maintenance and repairs for the information system.
|-
| [c] mechanisms used to conduct system maintenance are controlled. || Artifact || Processes for scheduling, performing, documenting, reviewing, approving, and monitoring maintenance and repairs for the information system.
|-
| [d] personnel used to conduct system maintenance are controlled. || Physical Review || Screenshot of who is authorized to conduct maintenance; maintenance personnel training program.
|}

=== MA.L2-3.7.3 – Equipment Sanitization ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.3_Details|'''MA.L2-3.7.3''']] Ensure equipment removed for off-site maintenance is sanitized of any CUI.
|-
| [a] equipment to be removed from organizational spaces for off-site maintenance is sanitized of any CUI. || Artifact || Document or artifact; record if equipment sanitized; categories of sanitization/destruction defined; sanitization procedural document.
|}

=== MA.L2-3.7.4 – Media Inspection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.4_Details|'''MA.L2-3.7.4''']] Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems.
|-
| [a] media containing diagnostic and test programs are checked for malicious code before being used in organizational systems that process, store, or transmit CUI. || Artifact || Screenshot of diagnostic/test program being used (such as Symantec and McAfee on access scans…).
|}

=== MA.L2-3.7.5 – Nonlocal Maintenance ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.5_Details|'''MA.L2-3.7.5''']] Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete.
|-
| [a] multifactor authentication is used to establish nonlocal maintenance sessions via external network connections. || Screen Share || Describe MFA used to remote from external service to organizational systems for maintenance and screenshot of MFA (3.5.3)(points associated with admin).
|-
| [b] nonlocal maintenance sessions established via external network connections are terminated when nonlocal maintenance is complete. || Screen Share || Screenshot VPN session timeout.
|}

=== MA.L2-3.7.6 – Maintenance Personnel ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.6_Details|'''MA.L2-3.7.6''']] Supervise the maintenance activities of maintenance personnel without required access authorization.
|-
| [a] maintenance personnel without required access authorization are supervised during maintenance activities. || Document || System maintenance policy; list of authorized personnel; maintenance records or, contracts/SLAs; WebEx.
|}

== Media Protection (MP) ==
=== MP.L2-3.8.1 – Media Protection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.1_Details|'''MP.L2-3.8.1''']] Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital.
|-
| [a] paper media containing CUI is physically controlled. || Document || Policy showing CUI paper media is controlled; artifact showing who has access; artifacts/records of inventories conducted; media check out procedures (i.e. file cabinets, encryption, password protection).
|-
| [b] digital media containing CUI is physically controlled. || Document || Policy showing CUI digital media is controlled; artifact showing who has access; artifacts/records of inventories conducted; media check out procedures (i.e. file cabinets, external drives, USBs, encryption, password protection).
|-
| [c] paper media containing CUI is securely stored. || Physical Review || Check out/sign out sheets; possible photo of storage container/video walk through of storage area; badge reader logs or access lists for keys for secured areas; interview response considered (i.e. file cabinets, encryption, password protection).
|-
| [d] digital media containing CUI is securely stored. || Physical Review || Check out/sign out sheets; possible photo of storage container/video walk through of storage area; badge reader logs or access lists for keys for secured areas; interview response considered (i.e. file cabinets, external drives, USBs, encryption, password protection).
|}

=== MP.L2-3.8.2 – Media Access ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.2_Details|'''MP.L2-3.8.2''']] Limit access to CUI on system media to authorized users.
|-
| [a] access to CUI on system media is limited to authorized users. || Artifact || Document describing how CUI is limited AND artifact showing principle of least access is implemented.
|}

=== MP.L2-3.8.3 – Media Disposal [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.3_Details|'''MP.L2-3.8.3''']] Sanitize or destroy information system media containing Federal Contract Information before disposal or release for reuse.
|-
| [a] system media containing CUI is sanitized or destroyed before disposal. || Document || Policy or artifact of media destruction logs; certificates of destruction; SLAs or contracts.
|-
| [b] system media containing CUI is sanitized before it is released for reuse. || Document || Policy or artifact describing method to sanitize, software used (i.e. DoD Wipe, ShredIT and Iron Mountain; Blancco; GDisk, DBAN).
|}

=== MP.L2-3.8.4 – Media Markings ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.4_Details|'''MP.L2-3.8.4''']] Mark media with necessary CUI markings and distribution limitations.
|-
| [a] media containing CUI is marked with applicable CUI markings. || Physical Review || Document or artifact showing CUI markings (i.e. labeling standards ).
|-
| [b] media containing CUI is marked with distribution limitations. || Physical Review || Document or artifact showing distro limitations (i.e. labeling standards ).
|}

=== MP.L2-3.8.5 – Media Accountability ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.5_Details|'''MP.L2-3.8.5''']] Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas.
|-
| [a] access to media containing CUI is controlled. || Document || Policy, artifact of audit logs showing tracking, Access Control Lists, records of transport activities (i.e. USB drives, CDs, chain of custody.
|-
| [b] accountability for media containing CUI is maintained during transport outside of controlled areas. || Artifact || Artifact of audit logs showing tracking, Access Control Lists, records of transport activities (i.e. USB drives, CDs; chain of custody.
|}

=== MP.L2-3.8.6 – Portable Storage Encryption ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.6_Details|'''MP.L2-3.8.6''']] Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards.
|-
| [a] the confidentiality of CUI stored on digital media is protected during transport using cryptographic mechanisms or alternative physical safeguards. || Artifact || Artifact showing crypto mechanisms used to protect (are they FIPS 140-2 [13.11]); artifact showing what alternative physical safeguards are in place (i.e. encryption; BitLocker; McAfee ).
|}

=== MP.L2-3.8.7 – Removable Media ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.7_Details|'''MP.L2-3.8.7''']] Control the use of removable media on system components.
|-
| [a] the use of removable media on system components is controlled. || Artifact || Policy showing if removable media is allowed; writable removable media is restricted; tracking artifacts; what tools are used (i.e. Carbon Black, Crowd Strike, GPO, Zoho Desktop Central); procedure/process describing what happens if it is lost; what mechanisms are in place to control/restrict removable media (i.e. Active Directory Groups and Group Policy artifact showing restriction).
|}

=== MP.L2-3.8.8 – Shared Media ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.8_Details|'''MP.L2-3.8.8''']] Prohibit the use of portable storage devices when such devices have no identifiable owner.ASSESSMENT OBJECTIVES'''
|-
| [a] the use of portable storage devices is prohibited when such devices have no identifiable owner. || Artifact || Policy and/or artifact showing company stance on portable storage devices if there is no owner (are personal USB devices allowed or are they company-issued; artifact showing alerts if device is connected to network (i.e. external HDD, Carbon Black, Crowd Strike, GPO, Zoho Desktop Central.
|}

=== MP.L2-3.8.9 – Protect Backups ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.9_Details|'''MP.L2-3.8.9''']] Protect the confidentiality of backup CUI at storage locations.
|-
| [a] the confidentiality of backup CUI is protected at storage locations. || Artifact || Policy on system backups; artifact showing media labeling; artifact showing encyption (is it FIPS 140-2 [13.11]); Access Control List artifact (i.e. backup tapes, Tivoli Storage Manager).
|}

== Personnel Security (PS) ==
=== PS.L2-3.9.1 – Screen Individuals ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PS.L2-3.9.1_Details|'''PS.L2-3.9.1''']] Screen individuals prior to authorizing access to organizational systems containing CUI.
|-
| [a] individuals are screened prior to authorizing access to organizational systems containing CUI. || Artifact || Screenshot of records of screened personnel/background checks.
|}

=== PS.L2-3.9.2 – Personnel Actions ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PS.L2-3.9.2_Details|'''PS.L2-3.9.2''']] Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers.
|-
| [a] a policy and/or process for terminating system access and any credentials coincident with personnel actions is established. || Document || Personnel security policy/procedures/instruction; Access control policy/procedure/instruction.
|-
| [b] system access and credentials are terminated consistent with personnel actions such as termination or transfer. || Artifact || Screenshot of records of personnel transfer and termination actions.
|-
| [c] the system is protected during and after personnel transfer actions. || Artifact || Completed outprocessing checklist.
|}

== Physical Protection (PE) ==
=== PE.L2-3.10.1 – Limit Physical Access [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.1_Details|'''PE.L2-3.10.1''']] Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals.
|-
| [a] authorized individuals allowed physical access are identified. || Artifact || Authorized personnel (names) access list.
|-
| [b] physical access to organizational systems is limited to authorized individuals. || Physical Review || Badge reader logs, audit logs, and/or card swipe test.
|-
| [c] physical access to equipment is limited to authorized individuals. || Physical Review || Badge reader logs, audit logs, and/or card swipe test.
|-
| [d] physical access to operating environments is limited to authorized. || Physical Review || Badge reader logs, audit logs, and/or card swipe test.
|}

=== PE.L2-3.10.2 – Monitor Facility ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.2_Details|'''PE.L2-3.10.2''']] Protect and monitor the physical facility and support infrastructure for organizational systems.
|-
| [a] the physical facility where organizational systems reside is protected. || Physical Review || Physical security measures and barriers into the physical facility (cameras/locks/gates/guards, etc.).
|-
| [b] the support infrastructure for organizational systems is protected. || Physical Review || Physical barriers to entries into computer spaces, server rooms, etc.
|-
| [c] the physical facility where organizational systems reside is monitored. || Physical Review || Audit logs/how the physical facility is being monitored (cameras/access system/guards, etc.).
|-
| [d] the support infrastructure for organizational systems is monitored. || Physical Review || Audit logs/how the physical facility is being monitored (cameras/access system/guards, etc.).
|}

=== PE.L2-3.10.3 – Escort Visitors [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.3_Details|'''PE.L2-3.10.3''']] Escort visitors and monitor visitor activity.
|-
| [a] visitors are escorted. || Physical Review || Policy/procedures/instruction on methodology for handling non-authorized personnel (entry to exit).
|-
| [b] visitor activity is monitored. || Physical Review || Policy/procedures/instructio on methodology for handling non-authorized personnel (entry to exit).
|}

=== PE.L2-3.10.4 – Physical Access Logs [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.4_Details|'''PE.L2-3.10.4''']] Maintain audit logs of physical access.
|-
| [a] audit logs of physical access are maintained. || Artifact || Log or report from badging system.
|}

=== PE.L2-3.10.5 – Manage Physical Access [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.5_Details|'''PE.L2-3.10.5''']] Control and manage physical access devices.
|-
| [a] physical access devices are identified. || Document || Physical access control systems description, guard force contract/policy, key locks, logical systems specifications, etc.
|-
| [b] physical access devices are controlled. || Physical Review || Inventory records of physical access control devices (e.g. keys, locks, card readers, locks, etc.).
|-
| [c] physical access devices are managed. || Physical Review || List of security safeguards controlling access to the facility (e.g. cameras, monitoring by guards, isolation of IT systems equiment and or system components).
|}

=== PE.L2-3.10.6 – Alternative Work Sites ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.6_Details|'''PE.L2-3.10.6''']] Enforce safeguarding measures for CUI at alternate work sites.
|-
| [a] safeguarding measures for CUI are defined for alternate work sites. || Document || Telework agreement, Acceptable Use Policy and SOP for alternate work locations; user security training validation which includes physical/logical/technical protections of system at alternate work sites.
|-
| [b] safeguarding measures for CUI are enforced for alternate work sites. || Artifact || Monitoring/audit log of user activity and logical/physical/technical mechanisms in place to preclude unauthorized activity (telework agreement , AUP?).
|}

== Risk Assessment (RA) ==
=== RA.L2-3.11.1 – Risk Assessments ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_RA.L2-3.11.1_Details|'''RA.L2-3.11.1''']] Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI.
|-
| [a] the frequency to assess risk to organizational operations, organizational assets, and individuals is defined. || Document || Risk assessment policy.
|-
| [b] risk to organizational operations, organizational assets, and individuals resulting from the operation of an organizational system that processes, stores, or transmits CUI is assessed with the defined frequency. || Artifact || Copy of last risk assessment done within defined frequency.
|}

=== RA.L2-3.11.2 – Vulnerability Scan ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_RA.L2-3.11.2_Details|'''RA.L2-3.11.2''']] Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
|-
| [a] the frequency to scan for vulnerabilities in organizational systems and applications is defined. || Document || Policy/procedures/instruction addressing vulnerability scanning records.
|-
| [b] vulnerability scans are performed on organizational systems with the defined frequency. || Screen Share || System configuration settings of vulnerability scanning scheduling and vulnerability scan results of systems within defined frequency.
|-
| [c] vulnerability scans are performed on applications with the defined frequency. || Screen Share || System configuration settings of vulnerability scanning scheduling and vulnerability scan results of applications within defined frequency.
|-
| [d] vulnerability scans are performed on organizational systems when new vulnerabilities are identified. || Screen Share || View signatures in scanning tool/ad hoc scan performed as a result.
|-
| [e] vulnerability scans are performed on applications when new vulnerabilities are identified. || Screen Share || View signatures in scanning tool/ad hoc scan performed as a result.
|}

=== RA.L2-3.11.3 – Vulnerability Remediation ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_RA.L2-3.11.3_Details|'''RA.L2-3.11.3''']] Remediate vulnerabilities in accordance with risk assessments.
|-
| [a] vulnerabilities are identified. || Artifact || Scan results showing vulnerabilities identified.
|-
| [b] vulnerabilities are remediated in accordance with risk assessments. || Artifact || Screenshot/document of scan results of remediated vulnerabilities in accordance to risk assessments.
|}

== Security Assessment (CA) ==
=== CA.L2-3.12.1 – Security Control Assessment ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CA.L2-3.12.1_Details|'''CA.L2-3.12.1''']] Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.
|-
| [a] the frequency of security control assessments is defined. || Document || SSP.
|-
| [b] security controls are assessed with the defined frequency to determine if the controls are effective in their application. || Artifact || Copy of last security control assessment done within defined frequency.
|}

=== CA.L2-3.12.2 – Operational Plan of Action ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CA.L2-3.12.2_Details|'''CA.L2-3.12.2''']] Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.
|-
| [a] deficiencies and vulnerabilities to be addressed by the plan of action are identified. || Artifact || Plan of Action (POA).
|-
| [b] a plan of action is developed to correct identified deficiencies and reduce or eliminate identified vulnerabilities. || Artifact || Plan of Action (POA).
|-
| [c] the plan of action is implemented to correct identified deficiencies and reduce or eliminate identified vulnerabilities. || Artifact || Plan of Action (POA)/previously completed POAs.
|}

=== CA.L2-3.12.3 – Security Control Monitoring ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CA.L2-3.12.3_Details|'''CA.L2-3.12.3''']] Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.
|-
| [a] security controls are monitored on an ongoing basis to ensure the continued effectiveness of those controls. || Artifact || Collection of risk assessment results, internal or third-party audits/security assessments and/or continuous monitoring reports/alerts (SIEM tool, etc.).
|}

=== CA.L2-3.12.4 – System Security Plan ====
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CA.L2-3.12.4_Details|'''CA.L2-3.12.4''']] Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.
|-
| [a] a system security plan is developed. || Document || SSP.
|-
| [b] the system boundary is described and documented in the system security plan. || Document || SSP and any supporting documentation.
|-
| [c] the system environment of operation is described and documented in the system security plan. || Document || SSP and any supporting documentation.
|-
| [d] the security requirements identified and approved by the designated authority as non-applicable are identified. || Document || SSP and required adjudication from DoD CIO.
|-
| [e] the method of security requirement implementation is described and documented in the system security plan. || Document || SSP and any supporting documentation.
|-
| [f] the relationship with or connection to other systems is described and documented in the system security plan. || Document || SSP and any supporting documentation.
|-
| [g] the frequency to update the system security plan is defined. || Document || SSP.
|-
| [h] system security plan is updated with the defined frequency. || Document || SSP/any previous versions.
|}

== System and Communications Protection (SC) ==
=== SC.L2-3.13.1 – Boundary Protection [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.1_Details|'''SC.L2-3.13.1''']] Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems.
|-
| [a] the external system boundary is defined. || Document || SSP, network diagrams, CUI flow, cloud provider FedRAMP Moderate.
|-
| [b] key internal system boundaries are defined. || Document || SSP, network diagrams, CUI flow.
|-
| [c] communications are monitored at the external system boundary. || Screen Share || SSP, logging server, boundary device configurations, monitoring policy.
|-
| [d] communications are monitored at key internal boundaries. || Screen Share || SSP, logging server, boundary device configurations, monitoring policy.
|-
| [e] communications are controlled at the external system boundary. || Screen Share || SSP, boundary device configurations, ACL, subnets, DMZ.
|-
| [f] communications are controlled at key internal boundaries. || Screen Share || SSP, boundary device configurations, ACL, subnets.
|-
| [g] communications are protected at the external system boundary. || Screen Share || Configurations for IPS/IDS, email gateway, VLAN, proxy, firewall, malware protection, DNS, TSL.
|-
| [h] communications are protected at key internal boundaries. || Screen Share || Configurations for IPS/IDS, VLAN, firewall, malware protection, SSL.
|}

=== SC.L2-3.13.2 – Security Engineering ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.2_Details|'''SC.L2-3.13.2''']] Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.
|-
| [a] architectural designs that promote effective information security are identified. || Document || SSP, config management policy, network diagram, CCB minutes, enterprise architecture process.
|-
| [b] software development techniques that promote effective information security are identified. || Document || SSP, config management policy, SDLC, CCB minutes.
|-
| [c] systems engineering principles that promote effective information security are identified. || Document || SSP, config management policy, CCB minutes, security architecture engineering.
|-
| [d] identified architectural designs that promote effective information security are employed. || Artifact || CCB minutes, Network diagrams and configurations, Project Plans.
|-
| [e] identified software development techniques that promote effective information security are employed. || Artifact || CCB minutes, SDLC, code scanner results, code management tracking.
|-
| [f] identified systems engineering principles that promote effective information security are employed. || Artifact || CCB minutes, configuration management, ITSM, patch management, lifecycle replacement processes.
|}

=== SC.L2-3.13.3 – Role Separation ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.3_Details|'''SC.L2-3.13.3''']] Separate user functionality from system management functionality.
|-
| [a] user functionality is identified. || Document || SSP, AUP.
|-
| [b] system management functionality is identified. || Document || SSP, Privileged Account Agreement.
|-
| [c] user functionality is separated from system management functionality. || Screen Share || Active Directory, Jump Boxes, GPO, VM, RDP.
|}

=== SC.L2-3.13.4 – Shared Resource Control ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.4_Details|'''SC.L2-3.13.4''']] Prevent unauthorized and unintended information transfer via shared system resources.
|-
| [a] unauthorized and unintended information transfer via shared system resources is prevented. || Screen Share || SSP, OS configurations, Linux containers, system/media reuse policies, certificate management policies, media destruction policies, printer configs, VDI configuration.
|}

=== SC.L2-3.13.5 – Public-Access System Separation [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.5_Details|'''SC.L2-3.13.5''']] Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
|-
| [a] publicly accessible system components are identified. || Document || SSP, network diagram, DMZ inventory/roles.
|-
| [b] subnetworks for publicly accessible system components are physically or logically separated from internal networks. || Artifact || Network diagram, IPAM, VLAN, DHCP, DMZ.
|}

=== SC.L2-3.13.6 – Network Communication by Exception ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.6_Details|'''SC.L2-3.13.6''']] Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).
|-
| [a] network communications traffic is denied by default. || Screen Share || Host and network firewall rules, SIEM logs, hit counts.
|-
| [b] network communications traffic is allowed by exception. || Screen Share || Host and network firewall rules, SIEM logs, hit counts.
|}

=== SC.L2-3.13.7 – Split Tunneling ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.7_Details|'''SC.L2-3.13.7''']] Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling).
|-
| [a] remote devices are prevented from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks (i.e., split tunneling). || Screen Share || VPN appliance/server configuration, endpoint VPN software configuration.
|}

=== SC.L2-3.13.8 – Data in Transit ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.8_Details|'''SC.L2-3.13.8''']] Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.
|-
| [a] cryptographic mechanisms intended to prevent unauthorized disclosure of CUI are identified. || Document || SSP, PKI policies, configuration processes, config management, email attachment encryption policy, removable media policy, data at rest policy.
|-
| [b] alternative physical safeguards intended to prevent unauthorized disclosure of CUI are identified. || Document || SSP, physical security policy.
|-
| [c] either cryptographic mechanisms or alternative physical safeguards are implemented to prevent unauthorized disclosure of CUI during transmission. || Screen Share || TLS settings, SSL settings, VPN/Wireless Access Points/Mobile Devices cryptographic settings, ODBC connector settings, SAN configuration, IPSec/MPLS, backup configuration, physical security.
|}

=== SC.L2-3.13.9 – Connections Termination ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.9_Details|'''SC.L2-3.13.9''']] Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity.
|-
| [a] a period of inactivity to terminate network connections associated with communications sessions is defined. || Document || SSP, network communications policy.
|-
| [b] network connections associated with communications sessions are terminated at the end of the sessions. || Screen Share || VPN appliance/server logs, VPN configurations, web server configurations, firewall connection settings.
|-
| [c] network connections associated with communications sessions are terminated after the defined period of inactivity. || Artifact || VPN appliance/server logs, VPN configurations, web server configurations, frewall connection settings.
|}

=== SC.L2-3.13.10 – Key Management ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.10_Details|'''SC.L2-3.13.10''']] Establish and manage cryptographic keys for cryptography employed in organizational systems.
|-
| [a] cryptographic keys are established whenever cryptography is employed. || Artifact || SSP, PKI/certificate management policy, configuration management.
|-
| [b] cryptographic keys are managed whenever cryptography is employed. || Artifact || SSP, PKI/certificate management policy, configuration management, access control policy.
|}

=== SC.L2-3.13.11 – CUI Encryption ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.11_Details|'''SC.L2-3.13.11''']] Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.
|-
| [a] FIPS-validated cryptography is employed to protect the confidentiality of CUI. || Screen Share || VPN, wireless, mobile devices, client certificates, server certificates, disk encryption, Outlook plugin, external mail, backup media, ePO server, removable storage, SAN, file compression; look for FIPS mode enabled on appliances.
|}

=== SC.L2-3.13.12 – Collaborative Device Control ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.12_Details|'''SC.L2-3.13.12''']] Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device.
|-
| [a] collaborative computing devices are identified. || Document || SSP, network diagrams.
|-
| [b] collaborative computing devices provide indication to users of devices in use. || Physical Review || Physical inspection of device.
|-
| [c] remote activation of collaborative computing devices is prohibited. || Screen Share || Collaboration device configuration/console.
|}

=== SC.L2-3.13.13 – Mobile Code ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.13_Details|'''SC.L2-3.13.13''']] Control and monitor the use of mobile code.
|-
| [a] use of mobile code is controlled. || Screen Share || GPO settings, malware protection, software agent configurations, software development policies, code scanners, MDM configuration, firewall/secure web gateway/proxy config.
|-
| [b] use of mobile code is monitored. || Screen Share || SIEM/console monitoring.
|}

=== SC.L2-3.13.14 – Voice over Internet Protocol ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.14_Details|'''SC.L2-3.13.14''']] Control and monitor the use of Voice over Internet Protocol (VoIP) technologies.
|-
| [a] use of Voice over Internet Protocol (VoIP) technologies is controlled. || Artifact || VLAN, ACL, firewall config, VoIP gateway/condenser configuration.
|-
| [b] use of Voice over Internet Protocol (VoIP) technologies is monitored. || Artifact || SIEM/VoIP console monitoring, session border controller.
|}

=== SC.L2-3.13.15 – Communications Authenticity ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.15_Details|'''SC.L2-3.13.15''']] Protect the authenticity of communications sessions.
|-
| [a] the authenticity of communications sessions is protected. || Screen Share || SSL, TLS, SMB3, SFTP, IPSec, SSH, Kerberos configs, MPLS, Network Access Control.
|}

=== SC.L2-3.13.16 – Data at Rest ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.16_Details|'''SC.L2-3.13.16''']] Protect the confidentiality of CUI at rest.
|-
| [a] the confidentiality of CUI at rest is protected. || Artifact || Full disk encryption, removable media encryption, SAN encryption, digital backups, mobile device encryption, third party offsite backup storage, cloud virtualization encryption, physical media storage policies.
|}

== System and Information Integrity (SI) ==
=== SI.L2-3.14.1 – Flaw Remediation [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.1_Details|'''SI.L2-3.14.1''']] Identify, report, and correct information and information system flaws in a timely manner.
|-
| [a] the time within which to identify system flaws is specified. || Document || SSP, patch management policy.
|-
| [b] system flaws are identified within the specified time frame. || Screen Share || Vulnerability management scanner output and scan policy configuration.
|-
| [c] the time within which to report system flaws is specified. || Document || SSP, patch management policy.
|-
| [d] system flaws are reported within the specified time frame. || Screen Share || ITSM/trouble tickets, vulnerability management scanner output.
|-
| [e] the time within which to correct system flaws is specified. || Document || SSP, patch management policy.
|-
| [f] system flaws are corrected within the specified time frame. || Screen Share || Vulnerability management scanner output and scan policy configuration.
|}

=== SI.L2-3.14.2 – Malicious Code ProTection [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.2_Details|'''SI.L2-3.14.2''']] Provide protection from malicious code at appropriate locations within organizational information systems.
|-
| [a] designated locations for malicious code protection are identified. || Document || SSP, system protection policy, network diagrams, security architecture documents.
|-
| [b] protection from malicious code at designated locations is provided. || Screen Share || Endpoint security settings, email/web proxy gateways, firewall, IPS sensor, MDM configuration, Network Access Control.
|}

=== SI.L2-3.14.3 – Security Alerts & Advisories ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.3_Details|'''SI.L2-3.14.3''']] Monitor system security alerts and advisories and take action in response.
|-
| [a] response actions to system security alerts and advisories are identified. || Document || SSP, vulnerability management policy, Incident Response Plan.
|-
| [b] system security alerts and advisories are monitored. || Artifact || Threat intelligence subscriptions, email advisories.
|-
| [c] actions in response to system security alerts and advisories are taken. || Artifact || ITSM/trouble tickets, user notifications, updates to firewall/IPS, etc.
|}

=== SI.L2-3.14.4 – Update Malicious Code Protection [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.4_Details|'''SI.L2-3.14.4''']] Update malicious code protection mechanisms when new releases are available.
|-
| [a] malicious code protection mechanisms are updated when new releases are available. || Screen Share || Antivirus console dashboard, firewall AV, Email gateway signatures,proxy, IPS updates.
|}

=== SI.L2-3.14.5 – System & File Scanning [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.5_Details|'''SI.L2-3.14.5''']] Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed.
|-
| [a] the frequency for malicious code scans is defined. || Document || SSP, vulnerability management policy.
|-
| [b] malicious code scans are performed with the defined frequency. || Screen Share || Consoles for AV (endpoints, servers, and file shares), firewall, email gateway, proxy, IPS, MDM configurations.
|-
| [c] real-time malicious code scans of files from external sources as files are downloaded, opened, or executed are performed. || Screen Share || Consoles for AV (endpoints, servers, and file shares), firewall, email gateway, proxy, IPS, MDM configurations.
|}

=== SI.L2-3.14.6 – Monitor Communications for Attacks ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.6_Details|'''SI.L2-3.14.6''']] Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.
|-
| [a] the system is monitored to detect attacks and indicators of potential attacks. || Screen Share || Firewall, IPS, endpoint protection, SIEM alerts and reports.
|-
| [b] inbound communications traffic is monitored to detect attacks and indicators of potential attacks. || Screen Share || Firewall, IPS, endpoint protection, SIEM alerts and reports.
|-
| [c] outbound communications traffic is monitored to detect attacks and indicators of potential attacks. || Screen Share || Firewall, IPS, endpoint protection, SIEM alerts and reports.
|}

=== SI.L2-3.14.7 – Identify Unauthorized Use ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.7_Details|'''SI.L2-3.14.7''']] Identify unauthorized use of organizational systems.
|-
| [a] authorized use of the system is defined. || Document || AUP, SSP.
|-
| [b] unauthorized use of the system is identified. || Artifact || SIEM logs, endpoint protection console, IPS, Firewall.
|}

Evidence Collection Approach

2026-07-20T01:42:47Z

David: /* IA.L2-3.5.6 – Identifier Handling */

CMMC assessments and certification require substantial evidence and documentation. The following tables outline general guidelines for collecting evidence to assess control requirements and objectives. While these guidelines provide a structured approach, they are not the only means of conducting an accurate assessment. Assessors should exercise professional judgment and may employ alternative methods appropriate to the specific organizational context and circumstances.

Evidence collection approaches are defined as:
* '''Documentation''': Tangible materials containing information over which an organization has authority, including all types of written records and their copies.
* '''Artifacts''': Tangible, reviewable records directly resulting from a practice or process being performed by a system or by personnel executing their role within that practice, control, or process.
* '''Physical Review''': Direct on-site observation and examination of evidence.
* '''Screen Share''': Real-time remote observation of a user demonstrating a task or process via shared computer screen, sometimes called "over-the-shoulder" review.

DISCLAIMER: Evidence requirements vary significantly across assessment types. '''The examples provided are illustrative only and should be tailored to meet the specific adequacy and sufficiency standards of your particular assessment context.'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmctoolkit.org contact us]. Thank you.

== Access Control (AC) ==
=== AC.L2-3.1.1 – Authorized Access Control [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.1_Details|'''AC.L2-3.1.1''']] Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems).
|-
| [a] authorized users are identified. || Document || Document defining account request, approval, provisioning.
|-
| [b] processes acting on behalf of authorized users are identified. || Document || Document defining account request, approval, provisioning.
|-
| [c] devices (and other systems) authorized to connect to the system are identified. || Document || Document defining account request, approval, provisioning.
|-
| [d] system access is limited to authorized users. || Screen Share || Screen share showing login requirements are enforced. Example of an unauthorized user denied (unauthorized username entered at login).
|-
| [e] system access is limited to processes acting on behalf of authorized users. || Screen Share || Screenshot showing that service accounts are assigned to authorized users only; no rogue accounts without an authorized user are active.
|-
| [f] system access is limited to authorized devices (including other systems). || Screen Share || Screen share showing that all devices running are authorized; no rogue devices on the network.
|}

=== AC.L2-3.1.2 – Transaction & Function Control [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.2_Details|'''AC.L2-3.1.2''']] Limit information system access to the types of transactions and functions that authorized users are permitted to execute.
|-
| [a] the types of transactions and functions that authorized users are permitted to execute are defined. || Document || SSP, AUP, or IAM document that defines what authorized users can execute.
|-
| [b] system access is limited to the defined types of transactions and functions for authorized users. || Screen Share || Screenshot of security roles in AD or IAM or other directory-based identity-related services tool that shows transactions are as defined in the SSP or IAM document; privileged and non-privileged accounts need to be defined and identified in the artifact; screenshot of a non-privileged user trying to execute a privileged function.
|}

=== AC.L2-3.1.3 – Control CUI Flow ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.3_Details|'''AC.L2-3.1.3''']] Control the flow of CUI in accordance with approved authorizations.
|-
| [a] information flow control policies are defined. || Document || SSP or other document describing the control of CUI on the network.
|-
| [b] methods and enforcement mechanisms for controlling the flow of CUI are defined. || Document || Document that defines the networking devices that are on the CUI network and answers what measures are in place to control the flow. List of firewalls, border and internal layer 3 devices, IDS/IPS, DLP, that process CUI.
|-
| [c] designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified. || Artifact || Network diagram, data flow diagram, external system connection diagrams, document describing the policies for CUI on the network; listing of VLANs and subnets where CUI is authorized; document must describe source and authorized destinations.
|-
| [d] authorizations for controlling the flow of CUI are defined. || Document || Document that defines how CUI is to be controlled, such as an InfoSec plan, and/or network management plan.
|-
| [e] approved authorizations for controlling the flow of CUI are enforced. || Screen Share || Screenshots of firewall rules, ACLs, etc.
|}

=== AC.L2-3.1.4 – Separation of Duties ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.4_Details|'''AC.L2-3.1.4''']] Separate the duties of individuals to reduce the risk of malevolent activity without collusion.
|-
| [a] the duties of individuals requiring separation are defined. || Document || Document, SSP, account management policy, defining separation of duties by person or role.
|-
| [b] responsibilities for duties that require separation are assigned to separate individuals. || Screen Share || Screenshot showing that separation of duties is enforced by showing admin accounts are assigned to different people based on role.
|-
| [c] access privileges that enable individuals to exercise the duties that require separation are granted to separate individuals. || Screen Share || Screen shot showing an example such as a security manager can not log into a network device and change ACLs, or network admins can not access security logs in the SIEM tool.
|}

=== AC.L2-3.1.5 – Least Privilege ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.5_Details|'''AC.L2-3.1.5''']] Employ the principle of least privilege, including for specific security functions and privileged accounts.
|-
| [a] privileged accounts are identified. || Document || "SSP or policy (documentation) identify what is considered a privileged account."
|-
| [b] access to privileged accounts is authorized in accordance with the principle of least privilege. || Artifact || An artifact that identifies the least amount of permissions associated with different types of privileged accounts are approved.
|-
| [c] security functions are identified. || Document || "SSP or policy (documentation) identifies what is considered a security account."
|-
| [d] access to security functions is authorized in accordance with the principle of least privilege. || Artifact || Artifact(s) that identify the least amount of permissions associated with different types of security accounts are approved.
|}

=== AC.L2-3.1.6 – Non-Privileged Account Use ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.6_Details|'''AC.L2-3.1.6''']] Use non-privileged accounts or roles when accessing nonsecurity functions.
|-
| [a] nonsecurity functions are identified. || Document || SSP or account management document, AUP, that defines non-security functions.
|-
| [b] users are required to use non-privileged accounts or roles when accessing nonsecurity functions. || Screen Share || Screenshot showing that a privileged user tried to use their admin account to access a non-security function, such as a browser or email (whatever is defined in their policy) and was blocked.
|}

=== AC.L2-3.1.7 – Privileged Functions ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.7_Details|'''AC.L2-3.1.7''']] Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.
|-
| [a] privileged functions are defined. || Document || SSP or policy (documentation) that defines privileged functions.
|-
| [b] non-privileged users are defined. || Document || SSP or policy (documentation) that defines non-privileged users.
|-
| [c] non-privileged users are prevented from executing privileged functions. || Screen Share || Screen share that shows that a non-privileged user is not allowed to complete a privileged function (installing software).
|-
| [d] the execution of privileged functions is captured in audit logs. || Screen Share || Screen share that shows logs being captured of the execution of privileged functions.
|}

=== AC.L2-3.1.8 – Unsuccessful Logon Attempts ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.8_Details|'''AC.L2-3.1.8''']] Limit unsuccessful logon attempts.
|-
| [a] the means of limiting unsuccessful logon attempts is defined. || Document || SSP or policy (documentation) showing unsuccessful logon attempts settings and or policy.
|-
| [b] the defined means of limiting unsuccessful logon attempts is implemented. || Artifact || Artifact showing GPO / Policy for limiting logon attempts.
|}

=== AC.L2-3.1.9 – Privacy & Security Notices ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.9_Details|'''AC.L2-3.1.9''']] Provide privacy and security notices consistent with applicable CUI rules.
|-
| [a] privacy and security notices required by CUI-specified rules are identified, consistent, and associated with the specific CUI category. || Document || SSP or policy (documentation) showing CUI-specified rules are identified, consistent, and associated with the specific CUI category.
|-
| [b] privacy and security notices are displayed. || Artifact || Artifact that shows a consent banner or screen that a user sees as they log in to the system.
|}

=== AC.L2-3.1.10 – Session Lock ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.10_Details|'''AC.L2-3.1.10''']] Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity.
|-
| [a] the period of inactivity after which the system initiates a session lock is defined. || Document || SSP or policy (documentation) that defines the period of inactivity and when a session lock is defined.
|-
| [b] access to the system and viewing of data is prevented by initiating a session lock after the defined period of inactivity. || Artifact || Artifact that shows the setting of session lock (GPO or system policy or similar solution addressing the controls supporting centralized management and configuration of operating systems, applications, and users' settings for the working environment of user accounts and computer accounts).
|-
| [c] previously visible information is concealed via a pattern-hiding display after the defined period of inactivity. || Document || Screenshot of GPO setting and configuration settings, or similar solution addressing the controls supporting centralized management and configuration of operating systems, applications, and users' settings for the working environment of user accounts and computer accounts.
|}

=== AC.L2-3.1.11 – Session Termination ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.11_Details|'''AC.L2-3.1.11''']] Terminate (automatically) a user session after a defined condition.
|-
| [a] conditions requiring a user session to terminate are defined. || Document || SSP or policy (documentation) that defines the conditions requiring a user session to be terminated.
|-
| [b] a user session is automatically terminated after any of the defined conditions. || Screen Share || Screen share showing GPO / VPN Settings that show when a session would be terminated (Idle time, max connection time).
|}

=== AC.L2-3.1.12 – Control Remote Access ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.12_Details|'''AC.L2-3.1.12''']] Monitor and control remote access sessions.
|-
| [a] remote access sessions are permitted. || Document || SSP or policy (documentation) that defines remote access sessions.
|-
| [b] the types of permitted remote access are identified. || Document || SSP or policy (documentation) that defines remote access is permitted.
|-
| [c] remote access sessions are controlled. || Screen Share || Screen share that shows how the remote access is controlled (access session, and or groups).
|-
| [d] remote access sessions are monitored. || Screen Share || Screen share that shows how remote sessions are monitored (logs).
|}

=== AC.L2-3.1.13 – Remote Access Confidentiality ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.13_Details|'''AC.L2-3.1.13''']] Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.
|-
| [a] cryptographic mechanisms to protect the confidentiality of remote access sessions are identified. || Document || SSP or policy (documentation) that discusses the CUI rules, consistent, and associated with the specific CUI category; FIPS Cert # of appliance or application.
|-
| [b] cryptographic mechanisms to protect the confidentiality of remote access sessions are implemented. || Screen Share || Screenshot of VPN concentration that shows encryption is on and enabled (point-to-point, etc.).
|}

=== AC.L2-3.1.14 – Remote Access Routing ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.14_Details|'''AC.L2-3.1.14''']] Route remote access via managed access control points.
|-
| [a] managed access control points are identified and implemented. || Screen Share || Screen share that shows access control points (groups and/or users).
|-
| [b] remote access is routed through managed network access control points. || Screen Share || Screen share that shows access control points and how they are managed.
|}

=== AC.L2-3.1.15 – Privileged Remote Access ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.15_Details|'''AC.L2-3.1.15''']] Authorize remote execution of privileged commands and remote access to security-relevant information.
|-
| [a] privileged commands authorized for remote execution are identified. || Document || SSP or policy (documentation) that defines what is authorized to be executed remotely and how that is handled.
|-
| [b] security-relevant information authorized to be accessed remotely is identified. || Document || SSP or policy (documentation) that defines what can be accessed remotely and what procedures are implemented to allow this (RDP, jump box).
|-
| [c] the execution of the identified privileged commands via remote access is authorized. || Artifact || Screen share that shows who has access to perform privileged commands a remotely (access groups for privileged accounts).
|-
| [d] access to the identified security-relevant information via remote access is authorized. || Artifact || Screen share that shows the routing of remote access and how it is monitored and how many locations (Firewall, VPN Concentrator).
|}

=== AC.L2-3.1.16 – Wireless Access Authorization ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.16_Details|'''AC.L2-3.1.16''']] Authorize wireless access prior to allowing such connections.
|-
| [a] wireless access points are identified. || Document || SSP, network administration document.
|-
| [b] wireless access is authorized prior to allowing such connections. || Screen Share || Authorization profile(s) in Wireless Access Controller or Identity Manager (i.e. Cisco ISE).
|}

=== AC.L2-3.1.17 – Wireless Access Protection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.17_Details|'''AC.L2-3.1.17''']] Protect wireless access using authentication and encryption.
|-
| [a] wireless access to the system is protected using authentication. || Screen Share || Security page (or similar) of a Wireless Access Controller.
|-
| [b] wireless access to the system is protected using encryption. || Screen Share || Security page (or similar) of a Wireless Access Controller.
|}

=== AC.L2-3.1.18 – Mobile Device Connection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.18_Details|'''AC.L2-3.1.18''']] Control connection of mobile devices.
|-
| [a] mobile devices that process, store, or transmit CUI are identified. || Document || SSP, Mobile Device Policy.
|-
| [b] mobile device connections are authorized. || Artifact || Authorization profile(s) in Wireless Access Controller or Identity Manager (i.e. Cisco ISE).
|-
| [c] mobile device connections are monitored and logged. || Screen Share || Mobile device logs within the MDM, log intake (sources) configuration (within SIEM) showing MDM is feeding logs to the SIEM.
|}

=== AC.L2-3.1.19 – Encrypt CUI on Mobile ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.19_Details|'''AC.L2-3.1.19''']] Encrypt CUI on mobile devices and mobile computing platforms.
|-
| [a] mobile devices and mobile computing platforms that process, store, or transmit CUI are identified. || Document || SSP, Mobile Device Policy.
|-
| [b] encryption is employed to protect CUI on identified mobile devices and mobile computing platforms. || Screen Share || Security policy page in MDM showing how encryption are enforced on mobile device. If no MDM or MDM doesn't enforce encryption, then validate if the devices used are on the list of devices with native FIPS approved validation.
|}

=== AC.L2-3.1.20 – External Connections [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.20_Details|'''AC.L2-3.1.20''']] Verify and control/limit connections to and use of external information systems.
|-
| [a] connections to external systems are identified. || Document || SSP, Systems Interconnection Agreements, SLA.
|-
| [b] the use of external systems is identified. || Document || SSP, Systems Interconnection Agreements, SLA.
|-
| [c] connections to external systems are verified. || Artifact || SLA for external systems, memorandum for interconnection, information to prove that any cloud solution is at FedRAMP impact level of moderate or higher (i.e. license information, screenshot of AWS cloud dashboard, purchase order document).
|-
| [d] the use of external systems is verified. || Artifact || SLA for external systems, memorandum for interconnection, information to prove that any cloud solution is at FedRAMP impact level of moderate or higher (i.e. license information, screenshot of AWS cloud dashboard, purchase order document).
|-
| [e] connections to external systems are controlled/limited. || Screen Share || Firewall ruleset for controlling access to cloud service or external system.
|-
| [f] the use of external systems is controlled/limited. || Screen Share || Firewall ruleset for controlling access to cloud service or external system.
|}

=== AC.L2-3.1.21 – Portable Storage Use ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.21_Details|'''AC.L2-3.1.21''']] Limit use of portable storage devices on external systems.
|-
| [a] the use of portable storage devices containing CUI on external systems is identified and documented. || Document || SSP, Removable Media Policy, Acceptable Use Policy (with emphasis on portable media use).
|-
| [b] limits on the use of portable storage devices containing CUI on external systems are defined. || Document || SSP, Removable Media Policy, Acceptable Use Policy (with emphasis on portable media use).
|-
| [c] the use of portable storage devices containing CUI on external systems is limited as defined. || Document || SSP, Removable Media Policy, Acceptable Use Policy (with emphasis on portable media use).
|}

=== AC.L2-3.1.22 – Control Public Information [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.22_Details|'''AC.L2-3.1.22''']] Control information posted or processed on publicly accessible information systems.
|-
| [a] individuals authorized to post or process information on publicly accessible systems are identified. || Document || SSP, Website Governance Plan, Information Release Document.
|-
| [b] procedures to ensure CUI is not posted or processed on publicly accessible systems are identified. || Document || SSP, Website Governance Plan, Information Release Document.
|-
| [c] a review process is in place prior to posting of any content to publicly accessible systems. || Artifact || "Information release approval process, i.e. chain of email communication from originator, approver, and final decision (may or may not include individual authorized to post);
SharePoint/electronic or paper form/ ticket system showing information flow between requestor and approver (may or may not include individual authorized to post)."
|-
| [d] content on publicly accessible systems is reviewed to ensure that it does not include CUI. || Artifact || Incident response process, web design/update/modification SOP etc.
|-
| [e] mechanisms are in place to remove and address improper posting of CUI. || Artifact || Incident response process, web design/update/modification SOP etc.
|}

== Awareness and Training (AT) ==
=== AT.L2-3.2.1 – Role-Based Risk Awareness ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AT.L2-3.2.1_Details|'''AT.L2-3.2.1''']] Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems.
|-
| [a] security risks associated with organizational activities involving CUI are identified. || Document || Policy of Security Awareness Training; Security Awareness Training Briefing.
|-
| [b] policies, standards, and procedures related to the security of the system are identified. || Document || Acceptable Use Policy, Policy/Procedures/Instruction related to the security of the system.
|-
| [c] managers, systems administrators, and users of the system are made aware of the security risks associated with their activities. || Artifact || Security Training Brief, training records.
|-
| [d] managers, systems administrators, and users of the system are made aware of the applicable policies, standards, and procedures related to the security of the system. || Artifact || Policies, standards and procedures for employees within training (completed training report).
|}

=== AT.L2-3.2.2 – Role-Based Training ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AT.L2-3.2.2_Details|'''AT.L2-3.2.2''']] Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities.|-
|-
| [a] information security-related duties, roles, and responsibilities are defined. || Document || Policy/Procedures/Instruction, Job Role Matrix, Position Descriptions, User Roles.
|-
| [b] information security-related duties, roles, and responsibilities are assigned to designated personnel. || Artifact || Screenshot of breakout of different roles/permissions assigned to individuals (i.e. ActiveDirectory); Privilege Access Agreement.
|-
| [c] personnel are adequately trained to carry out their assigned information security-related duties, roles, and responsibilities. || Artifact || Screenshot of tool and/or training specifying security specific roles, duties and responsibilities; Screenshot of required certifications (i.e. Sec+, CISSP).
|}

=== AT.L2-3.2.3 – Insider Threat Awareness ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AT.L2-3.2.3_Details|'''AT.L2-3.2.3''']] Provide security awareness training on recognizing and reporting potential indicators of insider threat.
|-
| [a] potential indicators associated with insider threats are identified. || Document || Insidert Threat Policy/Procedures/Instruction; Insider Threat Training/Briefing.
|-
| [b] security awareness training on recognizing and reporting potential indicators of insider threat is provided to managers and employees. || Artifact || Screenshot of training records showing completion of Insider Threat training, emails showing completion of Insider Threat training, Screenshot of certificate showing completion with individual's name.
|}

== Audit and Accountability (AU) ==
=== AU.L2-3.3.1 – System Auditing ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.1_Details|'''AU.L2-3.3.1''']] Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.
|-
| [a] audit logs needed (i.e., event types to be logged) to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity are specified. || Document || SSP, policy, or auditing and logging process that defines specific types of events to be logged.
|-
| [b] the content of audit records needed to support monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity is defined. || Document || SSP, policy, or auditing and logging process that defines specific content of audit records/files.
|-
| [c] audit records are created (generated). || Screen Share || Screen share of tool that shows logs are generated for all systems.
|-
| [d] audit records, once created, contain the defined content. || Screen Share || Screen share of tool that shows logs contain defined content as defined in SSP, policy, or procedures.
|-
| [e] retention requirements for audit records are defined. || Document || SSP, Polocy, or Auditing and logging process that describes how long records are kept.
|-
| [f] audit records are retained as defined. || Screen Share || Screen share of tool that shows records and audit content retained at a minimum as defined.
|}

=== AU.L2-3.3.2 – User Accountability ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.2_Details|'''AU.L2-3.3.2''']] Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions.
|-
| [a] the content of the audit records needed to support the ability to uniquely trace users to their actions is defined. || Document || SSP, policy, or process that defines actions traced back to individuals.
|-
| [b] audit records, once created, contain the defined content. || Screen Share || Screen share of tool that shows audit records traced to specific users/roles.
|}

=== AU.L2-3.3.3 – Event Review ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.3_Details|'''AU.L2-3.3.3''']] Review and update logged events.
|-
| [a] a process for determining when to review logged events is defined. || Document || SSP, policy, or documented process that shows frequency of when to review types of logged events.
|-
| [b] event types being logged are reviewed in accordance with the defined review process. || Artifact || Evidence through a documented method such as meeting minutes, CAB minutes, etc. of log sources and log events being logged at the defined frequency.
|-
| [c] event types being logged are updated based on the review. || Artifact || Evidence of implementation based on the results of the review of logged events/sources through a ticket, meeting minutes, or screen share of the tool that shows changes implemented (finetuning).
|}

=== AU.L2-3.3.4 – Audit Failure Alerting ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.4_Details|'''AU.L2-3.3.4''']] Alert in the event of an audit logging process failure.
|-
| [a] personnel or roles to be alerted in the event of an audit logging process failure are identified. || Document || SSP, policy, or procedure that shows who needs to be notified in case of an audit failure.
|-
| [b] types of audit logging process failures for which alert will be generated are defined. || Document || SSP, policy, or procedure that shows what types of failure will generate notifications.
|-
| [c] identified personnel or roles are alerted in the event of an audit logging process failure. || Artifact || Artifact such as email or ticket that shows the identified personnel were alerted of any audit/logging process failure as defined.
|}

=== AU.L2-3.3.5 – Audit Correlation ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.5_Details|'''AU.L2-3.3.5''']] Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.
|-
| [a] audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity are defined. || Document || SSP, policy, or procedure covering audit logging, monitoring, and reporting.
|-
| [b] defined audit record review, analysis, and reporting processes are correlated. || Artifact || Artifact showing an audit event and the resultant corrective action or actions to the event; this can be a Help Desk ticket, meeting notes, or a change control board items showing the event and any corrective action taken.
|}

=== AU.L2-3.3.6 – Reduction & Reporting ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.6_Details|'''AU.L2-3.3.6''']] Provide audit record reduction and report generation to support on-demand analysis and reporting.
|-
| [a] an audit record reduction capability that supports on-demand analysis is provided. || Screen Share || Screen share of the logging environment where an event can be selected and traced back to a specific device, or dashboard showing realtime event analysis.
|-
| [b] a report generation capability that supports on-demand reporting is provided. || Screen Share || Screen share showing the generation of an on demand report.
|}

=== AU.L2-3.3.7 – Authoritative Time Source ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.7_Details|'''AU.L2-3.3.7''']] Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.
|-
| [a] internal system clocks are used to generate time stamps for audit records. || Screen Share || Screen share showing the NTP settings of a windows, Unix, Linux device; a screen share showing the NTP settings of network appliances.
|-
| [b] an authoritative source with which to compare and synchronize internal system clocks is specified. || Document || SSP or policy indicating that devices need to be synched to a local authoritative time device that is synched with an authoritative time service.
|-
| [c] internal system clocks used to generate time stamps for audit records are compared to and synchronized with the specified authoritative time source. || Screen Share || Screen share showing device logging appliance time is point to the appropriate authoritative time server.
|}

=== AU.L2-3.3.8 – Audit Protection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.8_Details|'''AU.L2-3.3.8''']] Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
|-
| [a] audit information is protected from unauthorized access. || Screen Share || Screen share showing operating system permissions on the audit folders being restricted to appropriate users.
|-
| [b] audit information is protected from unauthorized modification. || Screen Share || Screen share showing operating system permissions on the audit folders being restricted to appropriate users.
|-
| [c] audit information is protected from unauthorized deletion. || Screen Share || Screen share showing operating system permissions on the audit folders being restricted to appropriate users.
|-
| [d] audit logging tools are protected from unauthorized access. || Screen Share || Artifact showing access permissions in the SIEM tool.
|-
| [e] audit logging tools are protected from unauthorized modification. || Screen Share || Artifact showing update permissions in the SIEM tool.
|-
| [f] audit logging tools are protected from unauthorized deletion. || Screen Share || Artifact showing delete permissions in the SIEM tool.
|}

=== AU.L2-3.3.9 – Audit Management ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.9_Details|'''AU.L2-3.3.9''']] Limit management of audit logging functionality to a subset of privileged users.
|-
| [a] a subset of privileged users granted access to manage audit logging functionality is defined. || Document || SSP or policy indicating which users or groups have access to audit logs.
|-
| [b] management of audit logging functionality is limited to the defined subset of privileged users. || Screen Share || Artifact showing SIEM or OS folder permissions (this should be limited to the assigned users or groups); artifact showing an ACL setting in SIEM tool in regards to logs.
|}

== Configuration Management (CM) ==
=== CM.L2-3.4.1 – System Baselining ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.1_Details|'''CM.L2-3.4.1''']] Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.
|-
| [a] a baseline configuration is established. || Document || Documentation showing or explaining standard imaging process (how standard images are deployed and where they are stored).
|-
| [b] the baseline configuration includes hardware, software, firmware, and documentation. || Artifact || Screenshot of repository of where images are maintained and information relating to hardware, software, and firmware.
|-
| [c] the baseline configuration is maintained (reviewed and updated) throughout the system development life cycle. || Artifact || Screenshot/evidence displaying management of baseline configurations (how often they are being managed as stated).
|-
| [d] a system inventory is established. || Document || Screenshot/evidence displaying inventory listing of approved products for use.
|-
| [e] the system inventory includes hardware, software, firmware, and documentation. || Artifact || Screeenshot/evidence displaying inventory listing of approved products and versions permitted for use.
|-
| [f] the inventory is maintained (reviewed and updated) throughout the system development life cycle. || Artifact || Screeenshot/evidence displaying management of baseline configurations (How often and are they being managed as stated.
|}

=== CM.L2-3.4.2 – Security Configuration Enforcement ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.2_Details|'''CM.L2-3.4.2''']] Establish and enforce security configuration settings for information technology products employed in organizational systems.
|-
| [a] security configuration settings for information technology products employed in the system are established and included in the baseline configuration. || Document || Documentation explaining methodology used by organization to create secure baselines (STIGs, benchmarks).
|-
| [b] security configuration settings for information technology products employed in the system are enforced. || Artifact || Evidence of tool/s used to enforce security configurations to ensure images used are free from modification unless authorized.
|}

=== CM.L2-3.4.3 – System Change Management ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.3_Details|'''CM.L2-3.4.3''']] Track, review, approve or disapprove, and log changes to organizational systems.
|-
| [a] changes to the system are tracked. || Artifact || Evidence of IT Service Management tool / process used to track system changes.
|-
| [b] changes to the system are reviewed. || Artifact || Evidence of IT Service Management tool / process used to review system changes.
|-
| [c] changes to the system are approved or disapproved. || Artifact || Evidence of IT Service Management tool / process used to approve/disapprove system changes.
|-
| [d] changes to the system are logged. || Artifact || Evidence of IT Service Management tool / process used to log system changes.
|}

=== CM.L2-3.4.4 – Security Impact Analysis ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.4_Details|'''CM.L2-3.4.4''']] Analyze the security impact of changes prior to implementation.
|-
| [a] the security impact of changes to the system is analyzed prior to implementation. || Artifact || Document explaining that security impact analysis of proposed changes to a system is conducted prior to implementation.
|}

=== CM.L2-3.4.5 – Access Restrictions for Change ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.5_Details|'''CM.L2-3.4.5''']] Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.
|-
| [a] physical access restrictions associated with changes to the system are defined. || Document || Document explaining the process of how physical access restrictions are defined for an individuals ability to make system changes.
|-
| [b] physical access restrictions associated with changes to the system are documented. || Document || Document explaining the process of how physical access restrictions are defined for an individuals ability to make system changes are documented; access request process.
|-
| [c] physical access restrictions associated with changes to the system are approved. || Artifact || Evidence of process of how physical access to systems are granted (i.e. physical access request sample).
|-
| [d] physical access restrictions associated with changes to the system are enforced. || Physical Review || Evidence of process of how physical access to systems are enforced (physical access system).
|-
| [e] logical access restrictions associated with changes to the system are defined. || Document || Document explaining the process of how logical access restrictions are defined for an individual's ability to make system changes.
|-
| [f] logical access restrictions associated with changes to the system are documented. || Document || Document explaining the process of how logical access restrictions are defined for an individual's ability to make system changes are documented.
|-
| [g] logical access restrictions associated with changes to the system are approved. || Artifact || Evidence of process of how logical access to systems are granted.
|-
| [h] logical access restrictions associated with changes to the system are enforced. || Artifact || Evidence of process of how logical access to systems are enforced.
|}

=== CM.L2-3.4.6 – Least Functionality ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.6_Details|'''CM.L2-3.4.6''']] Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.
|-
| [a] essential system capabilities are defined based on the principle of least functionality. || Document || Documentation explaining how systems are configured to utilize the principle of least functionality for designated users.
|-
| [b] the system is configured to provide only the defined essential capabilities. || Screen Share || Evidence displaying how systems are configured to utilize the principle of least functionality for designated users; disabled service settings, accepted standards for hardening (CIS benchmarks, etc.).
|}

=== CM.L2-3.4.7 – Nonessential Functionality ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.7_Details|'''CM.L2-3.4.7''']] Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.
|-
| [a] essential programs are defined. || Document || Documented essential programs specified; build documents; software center; SSP.
|-
| [b] the use of nonessential programs is defined. || Document || Documented listing of nonessential programs (whatever is NOT specified in [a]); AUP/User Agreement may identify nonessential use/programs.
|-
| [c] the use of nonessential programs is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict nonessential programs displays restrictions as defined (McAfee ePO settings, Carbon Black rules, etc.).
|-
| [d] essential functions are defined. || Document || Documented essential functions are specified.
|-
| [e] the use of nonessential functions is defined. || Document || Documented nonessential functions are specified.
|-
| [f] the use of nonessential functions is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict essential/nonessential functions displays restrictions as defined.
|-
| [g] essential ports are defined. || Document || Documented essential ports are specified.
|-
| [h] the use of nonessential ports is defined. || Document || Documented nonessential ports functions are specified.
|-
| [i] the use of nonessential ports is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict essential/nonessential ports displays restrictions as defined (FW rules; McAfee; GPO, etc.).
|-
| [j] essential protocols are defined. || Document || Documented essential protocols are specified.
|-
| [k] the use of nonessential protocols is defined. || Document || Documented nonessential protocols functions are specified.
|-
| [l] the use of nonessential protocols is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict essential/nonessential protocols displays restrictions as defined (FW rules; GPO, etc.).
|-
| [m] essential services are defined. || Document || Documented essential services specified.
|-
| [n] the use of nonessential services is defined. || Document || Documented nonessential services functions are specified.
|-
| [o] the use of nonessential services is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict essential/nonessential services displays restrictions as defined.
|}

=== CM.L2-3.4.8 – Application Execution Policy ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.8_Details|'''CM.L2-3.4.8''']] Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.
|-
| [a] a policy specifying whether whitelisting or blacklisting is to be implemented is specified. || Document || Documentation explaining whitelisting or blacklisting process.
|-
| [b] the software allowed to execute under whitelisting or denied use under blacklisting is specified. || Document || Documentation explaining whitelisting or blacklisting process for software.
|-
| [c] whitelisting to allow the execution of authorized software or blacklisting to prevent the use of unauthorized software is implemented as specified. || Screen Share || Tool used for whitelisting or blacklisting for software shows capability of restricting/authorizing software (Carbon Black dashboard, "SW Store", web proxies, DNS Blackhole, etc.).
|}

=== CM.L2-3.4.9 – User-Installed Software ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.9_Details|'''CM.L2-3.4.9''']] Control and monitor user-installed software.
|-
| [a] a policy for controlling the installation of software by users is established. || Document || Documented software authorization process or methodology for approval.
|-
| [b] installation of software by users is controlled based on the established policy. || Screen Share || Evidence that approval/restriction in installation of software by authorized personnel is implemented as specified (AUP, GPO, etc.).
|-
| [c] installation of software by users is monitored. || Screen Share || Evidence that installation of software by authorized personnel is monitored (SCCM groups, SW Center, etc.).
|}

== Identification and Authentication (IA) ==
=== IA.L2-3.5.1 – Identification [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.1_Details|'''IA.L2-3.5.1''']] Identify information system users, processes acting on behalf of users, or devices.
|-
| [a] system users are identified. || Document || Based on what is defined in their documentation (SSP, AUP, Policy, SOP), request to see a sample of non-privileged/privileged users in AD OU group (overlaps with 3.1.1 and 3.1.5).
|-
| [b] processes acting on behalf of users are identified. || Document || Based on what is defined in their documentation (SSP, AUP, Policy, SOP), request to see a sample of service accounts in AD OU group (overlaps with 3.1.1 and 3.1.5).
|-
| [c] devices accessing the system are identified. || Document || Based on what is defined in their documentation (SSP, AUP, Policy, SOP), request to see a sample of domain-joined workstation & servers in AD OU group (overlaps with 3.1.1 and 3.1.5). For network devices, request screen share/artifact to show how they are identified on the enterprise network.
|}

=== IA.L2-3.5.2 – Authentication [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.2_Details|'''IA.L2-3.5.2''']] Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems.
|-
| [a] the identity of each user is authenticated or verified as a prerequisite to system access. || Screen Share || If the user logs in with non-privileged account during other demoes and then a privileged account, then this should be satisfied. If screen share is unavailable, request logs to show successful and unsuccessful login by privileged and non-privilged users.
|-
| [b] the identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access. || Screen Share || Request a log that shows successful/unsuccessful service account trying to log on to company's asset.
|-
| [c] the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access. || Screen Share || Request a log that shows domain-joined workstation/server authenticating to AD (focus on the MAC/IP address/hostname).
|}

=== IA.L2-3.5.3 – Multifactor Authentication ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.3_Details|'''IA.L2-3.5.3''']] Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
|-
| [a] privileged accounts are identified. || Document || Based on what is defined in their documentation, request to see a sample of privileged users in AD OU group. Overlaps with 3.1.5. Screenshot/screen share to show implementation is enforced.
|-
| [b] multifactor authentication is implemented for local access to privileged accounts. || Screen Share || SSP, AUP, Policy, SOP that defines that MFA is needed for privileged local access.
|-
| [c] multifactor authentication is implemented for network access to privileged accounts. || Screen Share || Within the MFA implementation mechanism, show that privileged users are forced to use MFA; Screenshot/Screen share to show implementation is enforced.
|-
| [d] multifactor authentication is implemented for network access to non-privileged accounts. || Screen Share || Within the MFA implementation mechanism, show that non-privileged users are forced to use MFA; Screenshot/Screen share to show implementation is enforced.
|}

=== IA.L2-3.5.4 – Replay-Resistant Authentication ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.4_Details|'''IA.L2-3.5.4''']] Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.
|-
| [a] replay-resistant authentication mechanisms are implemented for network account access to privileged and non-privileged accounts. || Screen Share || Show the GPO setting that enforces Kerberos within AD. If MFA is used, show the implementation to enforce replay resistant techniques. For non-windows, show the technical solution to enforce replay resistant attacks.
|}

=== IA.L2-3.5.5 – Identifier Reuse ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.5_Details|'''IA.L2-3.5.5''']] Prevent reuse of identifiers for a defined period.
|-
| [a] a period within which identifiers cannot be reused is defined. || Document || SSP, policies, or SOP that defines identifier reuse.
|-
| [b] reuse of identifiers is prevented within the defined period. || Artifact || Show the GPO setting/technical solution that enforces what is defined in policy/documentation (this can be automated or manual process; screen share/artifacts can be presented to satisfy this requirement.
|}

=== IA.L2-3.5.6 – Identifier Handling ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.6_Details|'''IA.L2-3.5.6''']] Disable identifiers after a defined period of inactivity.
|-
| [a] a period of inactivity after which an identifier is disabled is defined. || Document || SSP, policy that defines the period of inactivity after which an identifier is disabled.
|-
| [b] identifiers are disabled after the defined period of inactivity. || Artifact || Screen share AD or similar tool supporting directory-based identity-related services for disabled accounts (can be done by hand or script).
|}

=== IA.L2-3.5.7 – Password Complexity ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.7_Details|'''IA.L2-3.5.7''']] Enforce a minimum password complexity and change of characters when new passwords are created.
|-
| [a] password complexity requirements are defined. || Document || SSP, policy that defines password complexity requirements.
|-
| [b] password change of character requirements are defined. || Document || SSP, policy that defines change of character requirements are defined.
|-
| [c] minimum password complexity requirements as defined are enforced when new passwords are created. || Screen Share || Screen share of AD or similar directory-based identity-related service tool to show complexity requirements.
|-
| [d] minimum password change of character requirements as defined are enforced when new passwords are created. || Screen Share || Screen share of Group Policy configuration or similar tool providing centralized management and configuration of operating systems, applications, and users' settings to show that characters must be changed.
|}

=== IA.L2-3.5.8 – Password Reuse ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.8_Details|'''IA.L2-3.5.8''']] Prohibit password reuse for a specified number of generations.
|-
| [a] the number of generations during which a password cannot be reused is specified. || Document || SSP, policy that specifies the number of generations during which a password cannot be reused is specified.
|-
| [b] reuse of passwords is prohibited during the specified number of generations. || Screen Share || Screen share Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration to show reuse of passwords is prohibited.
|}

=== IA.L2-3.5.9 – Temporary Passwords ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.9_Details|'''IA.L2-3.5.9''']] Allow temporary password use for system logons with an immediate change to a permanent password.
|-
| [a] an immediate change to a permanent password is required when a temporary password is used for system logon. || Screen Share || Screen share of Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration to show "change password at first logon."
|}

=== IA.L2-3.5.10 – Cryptographically-Protected Passwords ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.1_Details|'''IA.L2-3.5.1''']] Store and transmit only cryptographically-protected passwords.
|-
| [a] passwords are cryptographically protected in storage. || Screen Share || Screen share Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration that Kerberos, or a similar network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner, is enabled.
|-
| [b] passwords are cryptographically protected in transit. || Screen Share || Screen share Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration that Kerberos, or a similar network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner, is enabled.
|}

=== IA.L2-3.5.11 – Obscure Feedback ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.10_Details|'''IA.L2-3.5.10''']] Obscure feedback of authentication information.
|-
| [a] authentication information is obscured during the authentication process. || Screen Share || Screen share of Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration to show that passwords are obscured.
|}

== Incident Response (IR) ==
=== IR.L2-3.6.1 – Incident Handling ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IR.L2-3.6.1_Details|'''IR.L2-3.6.1''']] Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.
|-
| [a] an operational incident-handling capability is established. || Document || Incident Response SOP/Plan.
|-
| [b] the operational incident-handling capability includes preparation. || Document || Incident Response SOP/Plan, prior incident report, training, COOP plan.
|-
| [c] the operational incident-handling capability includes detection. || Document || Incident Response SOP/Plan; definition of tools used to detect; artifacts showing tools used; prior incident report.
|-
| [d] the operational incident-handling capability includes analysis. || Document || Incident Response SOP/Plan; Definition of tools used to analyze potential incidents; artifacts showing tools used for analysis; prior incident report.
|-
| [e] the operational incident-handling capability includes containment. || Document || Incident Response SOP/Plan; isolation/quarantine process; user training.
|-
| [f] the operational incident-handling capability includes recovery. || Document || Incident Response SOP/Plan; COOP Plan; prior incident reports, re-baselining impacted devices.
|-
| [g] the operational incident-handling capability includes user response. || Document || Incident Response SOP/Plan; user awareness training; Help Desk process.

|}

=== IR.L2-3.6.2 – Incident Reporting ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IR.L2-3.6.2_Details|'''IR.L2-3.6.2''']] Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.
|-
| [a] incidents are tracked. || Artifact || Incident Response SOP/Plan; ITSM artifact; technical implementation for incident tracking.
|-
| [b] incidents are documented. || Artifact || Incident Response SOP/Plan; ITSM artifact; technical implementation for incident tracking.
|-
| [c] authorities to whom incidents are to be reported are identified. || Document || Incident Response SOP/Plan.
|-
| [d] organizational officials to whom incidents are to be reported are identified. || Document || Incident Response SOP/Plan.
|-
| [e] identified authorities are notified of incidents. || Screen Share || Prior incident report; DIBNET login; prior email notifications.
|-
| [f] identified organizational officials are notified of incidents. || Artifact || Prior incident report; prior email notifications; tabletop exercises.
|}

=== IR.L2-3.6.3 – Incident Response Testing ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IR.L2-3.6.3_Details|'''IR.L2-3.6.3''']] Test the organizational incident response capability.
|-
| [a] the incident response capability is tested. || Artifact || Incident response table top/scheduled or unscheduled test or penetration test.
|}

== Maintenance (MA) ==
=== MA.L2-3.7.1 – Perform Maintenance ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.1_Details|'''MA.L2-3.7.1''']] Perform maintenance on organizational systems.
|-
| [a] system maintenance is performed. || Artifact || Establish typical maintenance activities (HVAC, UPS, power distribution, generators, copier maintenance) that are performed; maintenance agreements or contracts detailing these types of activities are acceptable; interview responses should be considered. This requirement should not be confused with 3.14.1 - report, remediate, and correct system flaws in a timely manner (patch management).
|}

=== MA.L2-3.7.2 – System Maintenance Control ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.2_Details|'''MA.L2-3.7.2''']] Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance.
|-
| [a] tools used to conduct system maintenance are controlled. || Artifact || Tools may largely depend on the assessed environment; discussion examples include network diagnostic and monitoring tools (including hardware and software); artifacts could demonstrate secured locations/areas for these tools (photos) or checkout sheets/rosters (documents) depicting responsible personnel and the dates/times of checkout.
|-
| [b] techniques used to conduct system maintenance are controlled. || Artifact || Processes for scheduling, performing, documenting, reviewing, approving, and monitoring maintenance and repairs for the information system.
|-
| [c] mechanisms used to conduct system maintenance are controlled. || Artifact || Processes for scheduling, performing, documenting, reviewing, approving, and monitoring maintenance and repairs for the information system.
|-
| [d] personnel used to conduct system maintenance are controlled. || Physical Review || Screenshot of who is authorized to conduct maintenance; maintenance personnel training program.
|}

=== MA.L2-3.7.3 – Equipment Sanitization ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.3_Details|'''MA.L2-3.7.3''']] Ensure equipment removed for off-site maintenance is sanitized of any CUI.
|-
| [a] equipment to be removed from organizational spaces for off-site maintenance is sanitized of any CUI. || Artifact || Document or artifact; record if equipment sanitized; categories of sanitization/destruction defined; sanitization procedural document.
|}

=== MA.L2-3.7.4 – Media Inspection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.4_Details|'''MA.L2-3.7.4''']] Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems.
|-
| [a] media containing diagnostic and test programs are checked for malicious code before being used in organizational systems that process, store, or transmit CUI. || Artifact || Screenshot of diagnostic/test program being used (such as Symantec and McAfee on access scans…).
|}

=== MA.L2-3.7.5 – Nonlocal Maintenance ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.5_Details|'''MA.L2-3.7.5''']] Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete.
|-
| [a] multifactor authentication is used to establish nonlocal maintenance sessions via external network connections. || Screen Share || Describe MFA used to remote from external service to organizational systems for maintenance and screenshot of MFA (3.5.3)(points associated with admin).
|-
| [b] nonlocal maintenance sessions established via external network connections are terminated when nonlocal maintenance is complete. || Screen Share || Screenshot VPN session timeout.
|}

=== MA.L2-3.7.6 – Maintenance Personnel ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.6_Details|'''MA.L2-3.7.6''']] Supervise the maintenance activities of maintenance personnel without required access authorization.
|-
| [a] maintenance personnel without required access authorization are supervised during maintenance activities. || Document || System maintenance policy; list of authorized personnel; maintenance records or, contracts/SLAs; WebEx.
|}

== Media Protection (MP) ==
=== MP.L2-3.8.1 – Media Protection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.1_Details|'''MP.L2-3.8.1''']] Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital.
|-
| [a] paper media containing CUI is physically controlled. || Document || Policy showing CUI paper media is controlled; artifact showing who has access; artifacts/records of inventories conducted; media check out procedures (i.e. file cabinets, encryption, password protection).
|-
| [b] digital media containing CUI is physically controlled. || Document || Policy showing CUI digital media is controlled; artifact showing who has access; artifacts/records of inventories conducted; media check out procedures (i.e. file cabinets, external drives, USBs, encryption, password protection).
|-
| [c] paper media containing CUI is securely stored. || Physical Review || Check out/sign out sheets; possible photo of storage container/video walk through of storage area; badge reader logs or access lists for keys for secured areas; interview response considered (i.e. file cabinets, encryption, password protection).
|-
| [d] digital media containing CUI is securely stored. || Physical Review || Check out/sign out sheets; possible photo of storage container/video walk through of storage area; badge reader logs or access lists for keys for secured areas; interview response considered (i.e. file cabinets, external drives, USBs, encryption, password protection).
|}

=== MP.L2-3.8.2 – Media Access ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.2_Details|'''MP.L2-3.8.2''']] Limit access to CUI on system media to authorized users.
|-
| [a] access to CUI on system media is limited to authorized users. || Artifact || Document describing how CUI is limited AND artifact showing principle of least access is implemented.
|}

=== MP.L2-3.8.3 – Media Disposal [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.3_Details|'''MP.L2-3.8.3''']] Sanitize or destroy information system media containing Federal Contract Information before disposal or release for reuse.
|-
| [a] system media containing CUI is sanitized or destroyed before disposal. || Document || Policy or artifact of media destruction logs; certificates of destruction; SLAs or contracts.
|-
| [b] system media containing CUI is sanitized before it is released for reuse. || Document || Policy or artifact describing method to sanitize, software used (i.e. DoD Wipe, ShredIT and Iron Mountain; Blancco; GDisk, DBAN).
|}

=== MP.L2-3.8.4 – Media Markings ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.4_Details|'''MP.L2-3.8.4''']] Mark media with necessary CUI markings and distribution limitations.
|-
| [a] media containing CUI is marked with applicable CUI markings. || Physical Review || Document or artifact showing CUI markings (i.e. labeling standards ).
|-
| [b] media containing CUI is marked with distribution limitations. || Physical Review || Document or artifact showing distro limitations (i.e. labeling standards ).
|}

=== MP.L2-3.8.5 – Media Accountability ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.5_Details|'''MP.L2-3.8.5''']] Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas.
|-
| [a] access to media containing CUI is controlled. || Document || Policy, artifact of audit logs showing tracking, Access Control Lists, records of transport activities (i.e. USB drives, CDs, chain of custody.
|-
| [b] accountability for media containing CUI is maintained during transport outside of controlled areas. || Artifact || Artifact of audit logs showing tracking, Access Control Lists, records of transport activities (i.e. USB drives, CDs; chain of custody.
|}

=== MP.L2-3.8.6 – Portable Storage Encryption ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.6_Details|'''MP.L2-3.8.6''']] Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards.
|-
| [a] the confidentiality of CUI stored on digital media is protected during transport using cryptographic mechanisms or alternative physical safeguards. || Artifact || Artifact showing crypto mechanisms used to protect (are they FIPS 140-2 [13.11]); artifact showing what alternative physical safeguards are in place (i.e. encryption; BitLocker; McAfee ).
|}

=== MP.L2-3.8.7 – Removable Media ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.7_Details|'''MP.L2-3.8.7''']] Control the use of removable media on system components.
|-
| [a] the use of removable media on system components is controlled. || Artifact || Policy showing if removable media is allowed; writable removable media is restricted; tracking artifacts; what tools are used (i.e. Carbon Black, Crowd Strike, GPO, Zoho Desktop Central); procedure/process describing what happens if it is lost; what mechanisms are in place to control/restrict removable media (i.e. Active Directory Groups and Group Policy artifact showing restriction).
|}

=== MP.L2-3.8.8 – Shared Media ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.8_Details|'''MP.L2-3.8.8''']] Prohibit the use of portable storage devices when such devices have no identifiable owner.ASSESSMENT OBJECTIVES'''
|-
| [a] the use of portable storage devices is prohibited when such devices have no identifiable owner. || Artifact || Policy and/or artifact showing company stance on portable storage devices if there is no owner (are personal USB devices allowed or are they company-issued; artifact showing alerts if device is connected to network (i.e. external HDD, Carbon Black, Crowd Strike, GPO, Zoho Desktop Central.
|}

=== MP.L2-3.8.9 – Protect Backups ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.9_Details|'''MP.L2-3.8.9''']] Protect the confidentiality of backup CUI at storage locations.
|-
| [a] the confidentiality of backup CUI is protected at storage locations. || Artifact || Policy on system backups; artifact showing media labeling; artifact showing encyption (is it FIPS 140-2 [13.11]); Access Control List artifact (i.e. backup tapes, Tivoli Storage Manager).
|}

== Personnel Security (PS) ==
=== PS.L2-3.9.1 – Screen Individuals ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PS.L2-3.9.1_Details|'''PS.L2-3.9.1''']] Screen individuals prior to authorizing access to organizational systems containing CUI.
|-
| [a] individuals are screened prior to authorizing access to organizational systems containing CUI. || Artifact || Screenshot of records of screened personnel/background checks.
|}

=== PS.L2-3.9.2 – Personnel Actions ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PS.L2-3.9.2_Details|'''PS.L2-3.9.2''']] Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers.
|-
| [a] a policy and/or process for terminating system access and any credentials coincident with personnel actions is established. || Document || Personnel security policy/procedures/instruction; Access control policy/procedure/instruction.
|-
| [b] system access and credentials are terminated consistent with personnel actions such as termination or transfer. || Artifact || Screenshot of records of personnel transfer and termination actions.
|-
| [c] the system is protected during and after personnel transfer actions. || Artifact || Completed outprocessing checklist.
|}

== Physical Protection (PE) ==
=== PE.L2-3.10.1 – Limit Physical Access [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.1_Details|'''PE.L2-3.10.1''']] Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals.
|-
| [a] authorized individuals allowed physical access are identified. || Artifact || Authorized personnel (names) access list.
|-
| [b] physical access to organizational systems is limited to authorized individuals. || Physical Review || Badge reader logs, audit logs, and/or card swipe test.
|-
| [c] physical access to equipment is limited to authorized individuals. || Physical Review || Badge reader logs, audit logs, and/or card swipe test.
|-
| [d] physical access to operating environments is limited to authorized. || Physical Review || Badge reader logs, audit logs, and/or card swipe test.
|}

=== PE.L2-3.10.2 – Monitor Facility ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.2_Details|'''PE.L2-3.10.2''']] Protect and monitor the physical facility and support infrastructure for organizational systems.
|-
| [a] the physical facility where organizational systems reside is protected. || Physical Review || Physical security measures and barriers into the physical facility (cameras/locks/gates/guards, etc.).
|-
| [b] the support infrastructure for organizational systems is protected. || Physical Review || Physical barriers to entries into computer spaces, server rooms, etc.
|-
| [c] the physical facility where organizational systems reside is monitored. || Physical Review || Audit logs/how the physical facility is being monitored (cameras/access system/guards, etc.).
|-
| [d] the support infrastructure for organizational systems is monitored. || Physical Review || Audit logs/how the physical facility is being monitored (cameras/access system/guards, etc.).
|}

=== PE.L2-3.10.3 – Escort Visitors [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.3_Details|'''PE.L2-3.10.3''']] Escort visitors and monitor visitor activity.
|-
| [a] visitors are escorted. || Physical Review || Policy/procedures/instruction on methodology for handling non-authorized personnel (entry to exit).
|-
| [b] visitor activity is monitored. || Physical Review || Policy/procedures/instructio on methodology for handling non-authorized personnel (entry to exit).
|}

=== PE.L2-3.10.4 – Physical Access Logs [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.4_Details|'''PE.L2-3.10.4''']] Maintain audit logs of physical access.
|-
| [a] audit logs of physical access are maintained. || Artifact || Log or report from badging system.
|}

=== PE.L2-3.10.5 – Manage Physical Access [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.5_Details|'''PE.L2-3.10.5''']] Control and manage physical access devices.
|-
| [a] physical access devices are identified. || Document || Physical access control systems description, guard force contract/policy, key locks, logical systems specifications, etc.
|-
| [b] physical access devices are controlled. || Physical Review || Inventory records of physical access control devices (e.g. keys, locks, card readers, locks, etc.).
|-
| [c] physical access devices are managed. || Physical Review || List of security safeguards controlling access to the facility (e.g. cameras, monitoring by guards, isolation of IT systems equiment and or system components).
|}

=== PE.L2-3.10.6 – Alternative Work Sites ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.6_Details|'''PE.L2-3.10.6''']] Enforce safeguarding measures for CUI at alternate work sites.
|-
| [a] safeguarding measures for CUI are defined for alternate work sites. || Document || Telework agreement, Acceptable Use Policy and SOP for alternate work locations; user security training validation which includes physical/logical/technical protections of system at alternate work sites.
|-
| [b] safeguarding measures for CUI are enforced for alternate work sites. || Artifact || Monitoring/audit log of user activity and logical/physical/technical mechanisms in place to preclude unauthorized activity (telework agreement , AUP?).
|}

== Risk Assessment (RA) ==
=== RA.L2-3.11.1 – Risk Assessments ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_RA.L2-3.11.1_Details|'''RA.L2-3.11.1''']] Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI.
|-
| [a] the frequency to assess risk to organizational operations, organizational assets, and individuals is defined. || Document || Risk assessment policy.
|-
| [b] risk to organizational operations, organizational assets, and individuals resulting from the operation of an organizational system that processes, stores, or transmits CUI is assessed with the defined frequency. || Artifact || Copy of last risk assessment done within defined frequency.
|}

=== RA.L2-3.11.2 – Vulnerability Scan ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_RA.L2-3.11.2_Details|'''RA.L2-3.11.2''']] Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
|-
| [a] the frequency to scan for vulnerabilities in organizational systems and applications is defined. || Document || Policy/procedures/instruction addressing vulnerability scanning records.
|-
| [b] vulnerability scans are performed on organizational systems with the defined frequency. || Screen Share || System configuration settings of vulnerability scanning scheduling and vulnerability scan results of systems within defined frequency.
|-
| [c] vulnerability scans are performed on applications with the defined frequency. || Screen Share || System configuration settings of vulnerability scanning scheduling and vulnerability scan results of applications within defined frequency.
|-
| [d] vulnerability scans are performed on organizational systems when new vulnerabilities are identified. || Screen Share || View signatures in scanning tool/ad hoc scan performed as a result.
|-
| [e] vulnerability scans are performed on applications when new vulnerabilities are identified. || Screen Share || View signatures in scanning tool/ad hoc scan performed as a result.
|}

=== RA.L2-3.11.3 – Vulnerability Remediation ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_RA.L2-3.11.3_Details|'''RA.L2-3.11.3''']] Remediate vulnerabilities in accordance with risk assessments.
|-
| [a] vulnerabilities are identified. || Artifact || Scan results showing vulnerabilities identified.
|-
| [b] vulnerabilities are remediated in accordance with risk assessments. || Artifact || Screenshot/document of scan results of remediated vulnerabilities in accordance to risk assessments.
|}

== Security Assessment (CA) ==
=== CA.L2-3.12.1 – Security Control Assessment ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CA.L2-3.12.1_Details|'''CA.L2-3.12.1''']] Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.
|-
| [a] the frequency of security control assessments is defined. || Document || SSP.
|-
| [b] security controls are assessed with the defined frequency to determine if the controls are effective in their application. || Artifact || Copy of last security control assessment done within defined frequency.
|}

=== CA.L2-3.12.2 – Operational Plan of Action ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CA.L2-3.12.2_Details|'''CA.L2-3.12.2''']] Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.
|-
| [a] deficiencies and vulnerabilities to be addressed by the plan of action are identified. || Artifact || Plan of Action (POA).
|-
| [b] a plan of action is developed to correct identified deficiencies and reduce or eliminate identified vulnerabilities. || Artifact || Plan of Action (POA).
|-
| [c] the plan of action is implemented to correct identified deficiencies and reduce or eliminate identified vulnerabilities. || Artifact || Plan of Action (POA)/previously completed POAs.
|}

=== CA.L2-3.12.3 – Security Control Monitoring ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CA.L2-3.12.3_Details|'''CA.L2-3.12.3''']] Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.
|-
| [a] security controls are monitored on an ongoing basis to ensure the continued effectiveness of those controls. || Artifact || Collection of risk assessment results, internal or third-party audits/security assessments and/or continuous monitoring reports/alerts (SIEM tool, etc.).
|}

=== CA.L2-3.12.4 – System Security Plan ====
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CA.L2-3.12.4_Details|'''CA.L2-3.12.4''']] Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.
|-
| [a] a system security plan is developed. || Document || SSP.
|-
| [b] the system boundary is described and documented in the system security plan. || Document || SSP and any supporting documentation.
|-
| [c] the system environment of operation is described and documented in the system security plan. || Document || SSP and any supporting documentation.
|-
| [d] the security requirements identified and approved by the designated authority as non-applicable are identified. || Document || SSP and required adjudication from DoD CIO.
|-
| [e] the method of security requirement implementation is described and documented in the system security plan. || Document || SSP and any supporting documentation.
|-
| [f] the relationship with or connection to other systems is described and documented in the system security plan. || Document || SSP and any supporting documentation.
|-
| [g] the frequency to update the system security plan is defined. || Document || SSP.
|-
| [h] system security plan is updated with the defined frequency. || Document || SSP/any previous versions.
|}

== System and Communications Protection (SC) ==
=== SC.L2-3.13.1 – Boundary Protection [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.1_Details|'''SC.L2-3.13.1''']] Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems.
|-
| [a] the external system boundary is defined. || Document || SSP, network diagrams, CUI flow, cloud provider FedRAMP Moderate.
|-
| [b] key internal system boundaries are defined. || Document || SSP, network diagrams, CUI flow.
|-
| [c] communications are monitored at the external system boundary. || Screen Share || SSP, logging server, boundary device configurations, monitoring policy.
|-
| [d] communications are monitored at key internal boundaries. || Screen Share || SSP, logging server, boundary device configurations, monitoring policy.
|-
| [e] communications are controlled at the external system boundary. || Screen Share || SSP, boundary device configurations, ACL, subnets, DMZ.
|-
| [f] communications are controlled at key internal boundaries. || Screen Share || SSP, boundary device configurations, ACL, subnets.
|-
| [g] communications are protected at the external system boundary. || Screen Share || Configurations for IPS/IDS, email gateway, VLAN, proxy, firewall, malware protection, DNS, TSL.
|-
| [h] communications are protected at key internal boundaries. || Screen Share || Configurations for IPS/IDS, VLAN, firewall, malware protection, SSL.
|}

=== SC.L2-3.13.2 – Security Engineering ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.2_Details|'''SC.L2-3.13.2''']] Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.
|-
| [a] architectural designs that promote effective information security are identified. || Document || SSP, config management policy, network diagram, CCB minutes, enterprise architecture process.
|-
| [b] software development techniques that promote effective information security are identified. || Document || SSP, config management policy, SDLC, CCB minutes.
|-
| [c] systems engineering principles that promote effective information security are identified. || Document || SSP, config management policy, CCB minutes, security architecture engineering.
|-
| [d] identified architectural designs that promote effective information security are employed. || Artifact || CCB minutes, Network diagrams and configurations, Project Plans.
|-
| [e] identified software development techniques that promote effective information security are employed. || Artifact || CCB minutes, SDLC, code scanner results, code management tracking.
|-
| [f] identified systems engineering principles that promote effective information security are employed. || Artifact || CCB minutes, configuration management, ITSM, patch management, lifecycle replacement processes.
|}

=== SC.L2-3.13.3 – Role Separation ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.3_Details|'''SC.L2-3.13.3''']] Separate user functionality from system management functionality.
|-
| [a] user functionality is identified. || Document || SSP, AUP.
|-
| [b] system management functionality is identified. || Document || SSP, Privileged Account Agreement.
|-
| [c] user functionality is separated from system management functionality. || Screen Share || Active Directory, Jump Boxes, GPO, VM, RDP.
|}

=== SC.L2-3.13.4 – Shared Resource Control ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.4_Details|'''SC.L2-3.13.4''']] Prevent unauthorized and unintended information transfer via shared system resources.
|-
| [a] unauthorized and unintended information transfer via shared system resources is prevented. || Screen Share || SSP, OS configurations, Linux containers, system/media reuse policies, certificate management policies, media destruction policies, printer configs, VDI configuration.
|}

=== SC.L2-3.13.5 – Public-Access System Separation [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.5_Details|'''SC.L2-3.13.5''']] Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
|-
| [a] publicly accessible system components are identified. || Document || SSP, network diagram, DMZ inventory/roles.
|-
| [b] subnetworks for publicly accessible system components are physically or logically separated from internal networks. || Artifact || Network diagram, IPAM, VLAN, DHCP, DMZ.
|}

=== SC.L2-3.13.6 – Network Communication by Exception ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.6_Details|'''SC.L2-3.13.6''']] Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).
|-
| [a] network communications traffic is denied by default. || Screen Share || Host and network firewall rules, SIEM logs, hit counts.
|-
| [b] network communications traffic is allowed by exception. || Screen Share || Host and network firewall rules, SIEM logs, hit counts.
|}

=== SC.L2-3.13.7 – Split Tunneling ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.7_Details|'''SC.L2-3.13.7''']] Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling).
|-
| [a] remote devices are prevented from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks (i.e., split tunneling). || Screen Share || VPN appliance/server configuration, endpoint VPN software configuration.
|}

=== SC.L2-3.13.8 – Data in Transit ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.8_Details|'''SC.L2-3.13.8''']] Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.
|-
| [a] cryptographic mechanisms intended to prevent unauthorized disclosure of CUI are identified. || Document || SSP, PKI policies, configuration processes, config management, email attachment encryption policy, removable media policy, data at rest policy.
|-
| [b] alternative physical safeguards intended to prevent unauthorized disclosure of CUI are identified. || Document || SSP, physical security policy.
|-
| [c] either cryptographic mechanisms or alternative physical safeguards are implemented to prevent unauthorized disclosure of CUI during transmission. || Screen Share || TLS settings, SSL settings, VPN/Wireless Access Points/Mobile Devices cryptographic settings, ODBC connector settings, SAN configuration, IPSec/MPLS, backup configuration, physical security.
|}

=== SC.L2-3.13.9 – Connections Termination ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.9_Details|'''SC.L2-3.13.9''']] Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity.
|-
| [a] a period of inactivity to terminate network connections associated with communications sessions is defined. || Document || SSP, network communications policy.
|-
| [b] network connections associated with communications sessions are terminated at the end of the sessions. || Screen Share || VPN appliance/server logs, VPN configurations, web server configurations, firewall connection settings.
|-
| [c] network connections associated with communications sessions are terminated after the defined period of inactivity. || Screen Share || VPN appliance/server logs, VPN configurations, web server configurations, frewall connection settings.
|}

=== SC.L2-3.13.10 – Key Management ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.10_Details|'''SC.L2-3.13.10''']] Establish and manage cryptographic keys for cryptography employed in organizational systems.
|-
| [a] cryptographic keys are established whenever cryptography is employed. || Artifact || SSP, PKI/certificate management policy, configuration management.
|-
| [b] cryptographic keys are managed whenever cryptography is employed. || Artifact || SSP, PKI/certificate management policy, configuration management, access control policy.
|}

=== SC.L2-3.13.11 – CUI Encryption ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.11_Details|'''SC.L2-3.13.11''']] Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.
|-
| [a] FIPS-validated cryptography is employed to protect the confidentiality of CUI. || Screen Share || VPN, wireless, mobile devices, client certificates, server certificates, disk encryption, Outlook plugin, external mail, backup media, ePO server, removable storage, SAN, file compression; look for FIPS mode enabled on appliances.
|}

=== SC.L2-3.13.12 – Collaborative Device Control ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.12_Details|'''SC.L2-3.13.12''']] Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device.
|-
| [a] collaborative computing devices are identified. || Document || SSP, network diagrams.
|-
| [b] collaborative computing devices provide indication to users of devices in use. || Physical Review || Physical inspection of device.
|-
| [c] remote activation of collaborative computing devices is prohibited. || Screen Share || Collaboration device configuration/console.
|}

=== SC.L2-3.13.13 – Mobile Code ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.13_Details|'''SC.L2-3.13.13''']] Control and monitor the use of mobile code.
|-
| [a] use of mobile code is controlled. || Screen Share || GPO settings, malware protection, software agent configurations, software development policies, code scanners, MDM configuration, firewall/secure web gateway/proxy config.
|-
| [b] use of mobile code is monitored. || Screen Share || SIEM/console monitoring.
|}

=== SC.L2-3.13.14 – Voice over Internet Protocol ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.14_Details|'''SC.L2-3.13.14''']] Control and monitor the use of Voice over Internet Protocol (VoIP) technologies.
|-
| [a] use of Voice over Internet Protocol (VoIP) technologies is controlled. || Artifact || VLAN, ACL, firewall config, VoIP gateway/condenser configuration.
|-
| [b] use of Voice over Internet Protocol (VoIP) technologies is monitored. || Artifact || SIEM/VoIP console monitoring, session border controller.
|}

=== SC.L2-3.13.15 – Communications Authenticity ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.15_Details|'''SC.L2-3.13.15''']] Protect the authenticity of communications sessions.
|-
| [a] the authenticity of communications sessions is protected. || Screen Share || SSL, TLS, SMB3, SFTP, IPSec, SSH, Kerberos configs, MPLS, Network Access Control.
|}

=== SC.L2-3.13.16 – Data at Rest ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.16_Details|'''SC.L2-3.13.16''']] Protect the confidentiality of CUI at rest.
|-
| [a] the confidentiality of CUI at rest is protected. || Artifact || Full disk encryption, removable media encryption, SAN encryption, digital backups, mobile device encryption, third party offsite backup storage, cloud virtualization encryption, physical media storage policies.
|}

== System and Information Integrity (SI) ==
=== SI.L2-3.14.1 – Flaw Remediation [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.1_Details|'''SI.L2-3.14.1''']] Identify, report, and correct information and information system flaws in a timely manner.
|-
| [a] the time within which to identify system flaws is specified. || Document || SSP, patch management policy.
|-
| [b] system flaws are identified within the specified time frame. || Screen Share || Vulnerability management scanner output and scan policy configuration.
|-
| [c] the time within which to report system flaws is specified. || Document || SSP, patch management policy.
|-
| [d] system flaws are reported within the specified time frame. || Screen Share || ITSM/trouble tickets, vulnerability management scanner output.
|-
| [e] the time within which to correct system flaws is specified. || Document || SSP, patch management policy.
|-
| [f] system flaws are corrected within the specified time frame. || Screen Share || Vulnerability management scanner output and scan policy configuration.
|}

=== SI.L2-3.14.2 – Malicious Code ProTection [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.2_Details|'''SI.L2-3.14.2''']] Provide protection from malicious code at appropriate locations within organizational information systems.
|-
| [a] designated locations for malicious code protection are identified. || Document || SSP, system protection policy, network diagrams, security architecture documents.
|-
| [b] protection from malicious code at designated locations is provided. || Screen Share || Endpoint security settings, email/web proxy gateways, firewall, IPS sensor, MDM configuration, Network Access Control.
|}

=== SI.L2-3.14.3 – Security Alerts & Advisories ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.3_Details|'''SI.L2-3.14.3''']] Monitor system security alerts and advisories and take action in response.
|-
| [a] response actions to system security alerts and advisories are identified. || Document || SSP, vulnerability management policy, Incident Response Plan.
|-
| [b] system security alerts and advisories are monitored. || Artifact || Threat intelligence subscriptions, email advisories.
|-
| [c] actions in response to system security alerts and advisories are taken. || Artifact || ITSM/trouble tickets, user notifications, updates to firewall/IPS, etc.
|}

=== SI.L2-3.14.4 – Update Malicious Code Protection [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.4_Details|'''SI.L2-3.14.4''']] Update malicious code protection mechanisms when new releases are available.
|-
| [a] malicious code protection mechanisms are updated when new releases are available. || Screen Share || Antivirus console dashboard, firewall AV, Email gateway signatures,proxy, IPS updates.
|}

=== SI.L2-3.14.5 – System & File Scanning [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.5_Details|'''SI.L2-3.14.5''']] Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed.
|-
| [a] the frequency for malicious code scans is defined. || Document || SSP, vulnerability management policy.
|-
| [b] malicious code scans are performed with the defined frequency. || Screen Share || Consoles for AV (endpoints, servers, and file shares), firewall, email gateway, proxy, IPS, MDM configurations.
|-
| [c] real-time malicious code scans of files from external sources as files are downloaded, opened, or executed are performed. || Screen Share || Consoles for AV (endpoints, servers, and file shares), firewall, email gateway, proxy, IPS, MDM configurations.
|}

=== SI.L2-3.14.6 – Monitor Communications for Attacks ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.6_Details|'''SI.L2-3.14.6''']] Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.
|-
| [a] the system is monitored to detect attacks and indicators of potential attacks. || Screen Share || Firewall, IPS, endpoint protection, SIEM alerts and reports.
|-
| [b] inbound communications traffic is monitored to detect attacks and indicators of potential attacks. || Screen Share || Firewall, IPS, endpoint protection, SIEM alerts and reports.
|-
| [c] outbound communications traffic is monitored to detect attacks and indicators of potential attacks. || Screen Share || Firewall, IPS, endpoint protection, SIEM alerts and reports.
|}

=== SI.L2-3.14.7 – Identify Unauthorized Use ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.7_Details|'''SI.L2-3.14.7''']] Identify unauthorized use of organizational systems.
|-
| [a] authorized use of the system is defined. || Document || AUP, SSP.
|-
| [b] unauthorized use of the system is identified. || Artifact || SIEM logs, endpoint protection console, IPS, Firewall.
|}

Evidence Collection Approach

2026-07-20T01:42:37Z

David: /* IA.L2-3.5.5 – Identifier Reuse */

CMMC assessments and certification require substantial evidence and documentation. The following tables outline general guidelines for collecting evidence to assess control requirements and objectives. While these guidelines provide a structured approach, they are not the only means of conducting an accurate assessment. Assessors should exercise professional judgment and may employ alternative methods appropriate to the specific organizational context and circumstances.

Evidence collection approaches are defined as:
* '''Documentation''': Tangible materials containing information over which an organization has authority, including all types of written records and their copies.
* '''Artifacts''': Tangible, reviewable records directly resulting from a practice or process being performed by a system or by personnel executing their role within that practice, control, or process.
* '''Physical Review''': Direct on-site observation and examination of evidence.
* '''Screen Share''': Real-time remote observation of a user demonstrating a task or process via shared computer screen, sometimes called "over-the-shoulder" review.

DISCLAIMER: Evidence requirements vary significantly across assessment types. '''The examples provided are illustrative only and should be tailored to meet the specific adequacy and sufficiency standards of your particular assessment context.'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmctoolkit.org contact us]. Thank you.

== Access Control (AC) ==
=== AC.L2-3.1.1 – Authorized Access Control [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.1_Details|'''AC.L2-3.1.1''']] Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems).
|-
| [a] authorized users are identified. || Document || Document defining account request, approval, provisioning.
|-
| [b] processes acting on behalf of authorized users are identified. || Document || Document defining account request, approval, provisioning.
|-
| [c] devices (and other systems) authorized to connect to the system are identified. || Document || Document defining account request, approval, provisioning.
|-
| [d] system access is limited to authorized users. || Screen Share || Screen share showing login requirements are enforced. Example of an unauthorized user denied (unauthorized username entered at login).
|-
| [e] system access is limited to processes acting on behalf of authorized users. || Screen Share || Screenshot showing that service accounts are assigned to authorized users only; no rogue accounts without an authorized user are active.
|-
| [f] system access is limited to authorized devices (including other systems). || Screen Share || Screen share showing that all devices running are authorized; no rogue devices on the network.
|}

=== AC.L2-3.1.2 – Transaction & Function Control [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.2_Details|'''AC.L2-3.1.2''']] Limit information system access to the types of transactions and functions that authorized users are permitted to execute.
|-
| [a] the types of transactions and functions that authorized users are permitted to execute are defined. || Document || SSP, AUP, or IAM document that defines what authorized users can execute.
|-
| [b] system access is limited to the defined types of transactions and functions for authorized users. || Screen Share || Screenshot of security roles in AD or IAM or other directory-based identity-related services tool that shows transactions are as defined in the SSP or IAM document; privileged and non-privileged accounts need to be defined and identified in the artifact; screenshot of a non-privileged user trying to execute a privileged function.
|}

=== AC.L2-3.1.3 – Control CUI Flow ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.3_Details|'''AC.L2-3.1.3''']] Control the flow of CUI in accordance with approved authorizations.
|-
| [a] information flow control policies are defined. || Document || SSP or other document describing the control of CUI on the network.
|-
| [b] methods and enforcement mechanisms for controlling the flow of CUI are defined. || Document || Document that defines the networking devices that are on the CUI network and answers what measures are in place to control the flow. List of firewalls, border and internal layer 3 devices, IDS/IPS, DLP, that process CUI.
|-
| [c] designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified. || Artifact || Network diagram, data flow diagram, external system connection diagrams, document describing the policies for CUI on the network; listing of VLANs and subnets where CUI is authorized; document must describe source and authorized destinations.
|-
| [d] authorizations for controlling the flow of CUI are defined. || Document || Document that defines how CUI is to be controlled, such as an InfoSec plan, and/or network management plan.
|-
| [e] approved authorizations for controlling the flow of CUI are enforced. || Screen Share || Screenshots of firewall rules, ACLs, etc.
|}

=== AC.L2-3.1.4 – Separation of Duties ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.4_Details|'''AC.L2-3.1.4''']] Separate the duties of individuals to reduce the risk of malevolent activity without collusion.
|-
| [a] the duties of individuals requiring separation are defined. || Document || Document, SSP, account management policy, defining separation of duties by person or role.
|-
| [b] responsibilities for duties that require separation are assigned to separate individuals. || Screen Share || Screenshot showing that separation of duties is enforced by showing admin accounts are assigned to different people based on role.
|-
| [c] access privileges that enable individuals to exercise the duties that require separation are granted to separate individuals. || Screen Share || Screen shot showing an example such as a security manager can not log into a network device and change ACLs, or network admins can not access security logs in the SIEM tool.
|}

=== AC.L2-3.1.5 – Least Privilege ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.5_Details|'''AC.L2-3.1.5''']] Employ the principle of least privilege, including for specific security functions and privileged accounts.
|-
| [a] privileged accounts are identified. || Document || "SSP or policy (documentation) identify what is considered a privileged account."
|-
| [b] access to privileged accounts is authorized in accordance with the principle of least privilege. || Artifact || An artifact that identifies the least amount of permissions associated with different types of privileged accounts are approved.
|-
| [c] security functions are identified. || Document || "SSP or policy (documentation) identifies what is considered a security account."
|-
| [d] access to security functions is authorized in accordance with the principle of least privilege. || Artifact || Artifact(s) that identify the least amount of permissions associated with different types of security accounts are approved.
|}

=== AC.L2-3.1.6 – Non-Privileged Account Use ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.6_Details|'''AC.L2-3.1.6''']] Use non-privileged accounts or roles when accessing nonsecurity functions.
|-
| [a] nonsecurity functions are identified. || Document || SSP or account management document, AUP, that defines non-security functions.
|-
| [b] users are required to use non-privileged accounts or roles when accessing nonsecurity functions. || Screen Share || Screenshot showing that a privileged user tried to use their admin account to access a non-security function, such as a browser or email (whatever is defined in their policy) and was blocked.
|}

=== AC.L2-3.1.7 – Privileged Functions ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.7_Details|'''AC.L2-3.1.7''']] Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.
|-
| [a] privileged functions are defined. || Document || SSP or policy (documentation) that defines privileged functions.
|-
| [b] non-privileged users are defined. || Document || SSP or policy (documentation) that defines non-privileged users.
|-
| [c] non-privileged users are prevented from executing privileged functions. || Screen Share || Screen share that shows that a non-privileged user is not allowed to complete a privileged function (installing software).
|-
| [d] the execution of privileged functions is captured in audit logs. || Screen Share || Screen share that shows logs being captured of the execution of privileged functions.
|}

=== AC.L2-3.1.8 – Unsuccessful Logon Attempts ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.8_Details|'''AC.L2-3.1.8''']] Limit unsuccessful logon attempts.
|-
| [a] the means of limiting unsuccessful logon attempts is defined. || Document || SSP or policy (documentation) showing unsuccessful logon attempts settings and or policy.
|-
| [b] the defined means of limiting unsuccessful logon attempts is implemented. || Artifact || Artifact showing GPO / Policy for limiting logon attempts.
|}

=== AC.L2-3.1.9 – Privacy & Security Notices ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.9_Details|'''AC.L2-3.1.9''']] Provide privacy and security notices consistent with applicable CUI rules.
|-
| [a] privacy and security notices required by CUI-specified rules are identified, consistent, and associated with the specific CUI category. || Document || SSP or policy (documentation) showing CUI-specified rules are identified, consistent, and associated with the specific CUI category.
|-
| [b] privacy and security notices are displayed. || Artifact || Artifact that shows a consent banner or screen that a user sees as they log in to the system.
|}

=== AC.L2-3.1.10 – Session Lock ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.10_Details|'''AC.L2-3.1.10''']] Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity.
|-
| [a] the period of inactivity after which the system initiates a session lock is defined. || Document || SSP or policy (documentation) that defines the period of inactivity and when a session lock is defined.
|-
| [b] access to the system and viewing of data is prevented by initiating a session lock after the defined period of inactivity. || Artifact || Artifact that shows the setting of session lock (GPO or system policy or similar solution addressing the controls supporting centralized management and configuration of operating systems, applications, and users' settings for the working environment of user accounts and computer accounts).
|-
| [c] previously visible information is concealed via a pattern-hiding display after the defined period of inactivity. || Document || Screenshot of GPO setting and configuration settings, or similar solution addressing the controls supporting centralized management and configuration of operating systems, applications, and users' settings for the working environment of user accounts and computer accounts.
|}

=== AC.L2-3.1.11 – Session Termination ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.11_Details|'''AC.L2-3.1.11''']] Terminate (automatically) a user session after a defined condition.
|-
| [a] conditions requiring a user session to terminate are defined. || Document || SSP or policy (documentation) that defines the conditions requiring a user session to be terminated.
|-
| [b] a user session is automatically terminated after any of the defined conditions. || Screen Share || Screen share showing GPO / VPN Settings that show when a session would be terminated (Idle time, max connection time).
|}

=== AC.L2-3.1.12 – Control Remote Access ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.12_Details|'''AC.L2-3.1.12''']] Monitor and control remote access sessions.
|-
| [a] remote access sessions are permitted. || Document || SSP or policy (documentation) that defines remote access sessions.
|-
| [b] the types of permitted remote access are identified. || Document || SSP or policy (documentation) that defines remote access is permitted.
|-
| [c] remote access sessions are controlled. || Screen Share || Screen share that shows how the remote access is controlled (access session, and or groups).
|-
| [d] remote access sessions are monitored. || Screen Share || Screen share that shows how remote sessions are monitored (logs).
|}

=== AC.L2-3.1.13 – Remote Access Confidentiality ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.13_Details|'''AC.L2-3.1.13''']] Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.
|-
| [a] cryptographic mechanisms to protect the confidentiality of remote access sessions are identified. || Document || SSP or policy (documentation) that discusses the CUI rules, consistent, and associated with the specific CUI category; FIPS Cert # of appliance or application.
|-
| [b] cryptographic mechanisms to protect the confidentiality of remote access sessions are implemented. || Screen Share || Screenshot of VPN concentration that shows encryption is on and enabled (point-to-point, etc.).
|}

=== AC.L2-3.1.14 – Remote Access Routing ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.14_Details|'''AC.L2-3.1.14''']] Route remote access via managed access control points.
|-
| [a] managed access control points are identified and implemented. || Screen Share || Screen share that shows access control points (groups and/or users).
|-
| [b] remote access is routed through managed network access control points. || Screen Share || Screen share that shows access control points and how they are managed.
|}

=== AC.L2-3.1.15 – Privileged Remote Access ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.15_Details|'''AC.L2-3.1.15''']] Authorize remote execution of privileged commands and remote access to security-relevant information.
|-
| [a] privileged commands authorized for remote execution are identified. || Document || SSP or policy (documentation) that defines what is authorized to be executed remotely and how that is handled.
|-
| [b] security-relevant information authorized to be accessed remotely is identified. || Document || SSP or policy (documentation) that defines what can be accessed remotely and what procedures are implemented to allow this (RDP, jump box).
|-
| [c] the execution of the identified privileged commands via remote access is authorized. || Artifact || Screen share that shows who has access to perform privileged commands a remotely (access groups for privileged accounts).
|-
| [d] access to the identified security-relevant information via remote access is authorized. || Artifact || Screen share that shows the routing of remote access and how it is monitored and how many locations (Firewall, VPN Concentrator).
|}

=== AC.L2-3.1.16 – Wireless Access Authorization ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.16_Details|'''AC.L2-3.1.16''']] Authorize wireless access prior to allowing such connections.
|-
| [a] wireless access points are identified. || Document || SSP, network administration document.
|-
| [b] wireless access is authorized prior to allowing such connections. || Screen Share || Authorization profile(s) in Wireless Access Controller or Identity Manager (i.e. Cisco ISE).
|}

=== AC.L2-3.1.17 – Wireless Access Protection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.17_Details|'''AC.L2-3.1.17''']] Protect wireless access using authentication and encryption.
|-
| [a] wireless access to the system is protected using authentication. || Screen Share || Security page (or similar) of a Wireless Access Controller.
|-
| [b] wireless access to the system is protected using encryption. || Screen Share || Security page (or similar) of a Wireless Access Controller.
|}

=== AC.L2-3.1.18 – Mobile Device Connection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.18_Details|'''AC.L2-3.1.18''']] Control connection of mobile devices.
|-
| [a] mobile devices that process, store, or transmit CUI are identified. || Document || SSP, Mobile Device Policy.
|-
| [b] mobile device connections are authorized. || Artifact || Authorization profile(s) in Wireless Access Controller or Identity Manager (i.e. Cisco ISE).
|-
| [c] mobile device connections are monitored and logged. || Screen Share || Mobile device logs within the MDM, log intake (sources) configuration (within SIEM) showing MDM is feeding logs to the SIEM.
|}

=== AC.L2-3.1.19 – Encrypt CUI on Mobile ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.19_Details|'''AC.L2-3.1.19''']] Encrypt CUI on mobile devices and mobile computing platforms.
|-
| [a] mobile devices and mobile computing platforms that process, store, or transmit CUI are identified. || Document || SSP, Mobile Device Policy.
|-
| [b] encryption is employed to protect CUI on identified mobile devices and mobile computing platforms. || Screen Share || Security policy page in MDM showing how encryption are enforced on mobile device. If no MDM or MDM doesn't enforce encryption, then validate if the devices used are on the list of devices with native FIPS approved validation.
|}

=== AC.L2-3.1.20 – External Connections [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.20_Details|'''AC.L2-3.1.20''']] Verify and control/limit connections to and use of external information systems.
|-
| [a] connections to external systems are identified. || Document || SSP, Systems Interconnection Agreements, SLA.
|-
| [b] the use of external systems is identified. || Document || SSP, Systems Interconnection Agreements, SLA.
|-
| [c] connections to external systems are verified. || Artifact || SLA for external systems, memorandum for interconnection, information to prove that any cloud solution is at FedRAMP impact level of moderate or higher (i.e. license information, screenshot of AWS cloud dashboard, purchase order document).
|-
| [d] the use of external systems is verified. || Artifact || SLA for external systems, memorandum for interconnection, information to prove that any cloud solution is at FedRAMP impact level of moderate or higher (i.e. license information, screenshot of AWS cloud dashboard, purchase order document).
|-
| [e] connections to external systems are controlled/limited. || Screen Share || Firewall ruleset for controlling access to cloud service or external system.
|-
| [f] the use of external systems is controlled/limited. || Screen Share || Firewall ruleset for controlling access to cloud service or external system.
|}

=== AC.L2-3.1.21 – Portable Storage Use ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.21_Details|'''AC.L2-3.1.21''']] Limit use of portable storage devices on external systems.
|-
| [a] the use of portable storage devices containing CUI on external systems is identified and documented. || Document || SSP, Removable Media Policy, Acceptable Use Policy (with emphasis on portable media use).
|-
| [b] limits on the use of portable storage devices containing CUI on external systems are defined. || Document || SSP, Removable Media Policy, Acceptable Use Policy (with emphasis on portable media use).
|-
| [c] the use of portable storage devices containing CUI on external systems is limited as defined. || Document || SSP, Removable Media Policy, Acceptable Use Policy (with emphasis on portable media use).
|}

=== AC.L2-3.1.22 – Control Public Information [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AC.L2-3.1.22_Details|'''AC.L2-3.1.22''']] Control information posted or processed on publicly accessible information systems.
|-
| [a] individuals authorized to post or process information on publicly accessible systems are identified. || Document || SSP, Website Governance Plan, Information Release Document.
|-
| [b] procedures to ensure CUI is not posted or processed on publicly accessible systems are identified. || Document || SSP, Website Governance Plan, Information Release Document.
|-
| [c] a review process is in place prior to posting of any content to publicly accessible systems. || Artifact || "Information release approval process, i.e. chain of email communication from originator, approver, and final decision (may or may not include individual authorized to post);
SharePoint/electronic or paper form/ ticket system showing information flow between requestor and approver (may or may not include individual authorized to post)."
|-
| [d] content on publicly accessible systems is reviewed to ensure that it does not include CUI. || Artifact || Incident response process, web design/update/modification SOP etc.
|-
| [e] mechanisms are in place to remove and address improper posting of CUI. || Artifact || Incident response process, web design/update/modification SOP etc.
|}

== Awareness and Training (AT) ==
=== AT.L2-3.2.1 – Role-Based Risk Awareness ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AT.L2-3.2.1_Details|'''AT.L2-3.2.1''']] Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems.
|-
| [a] security risks associated with organizational activities involving CUI are identified. || Document || Policy of Security Awareness Training; Security Awareness Training Briefing.
|-
| [b] policies, standards, and procedures related to the security of the system are identified. || Document || Acceptable Use Policy, Policy/Procedures/Instruction related to the security of the system.
|-
| [c] managers, systems administrators, and users of the system are made aware of the security risks associated with their activities. || Artifact || Security Training Brief, training records.
|-
| [d] managers, systems administrators, and users of the system are made aware of the applicable policies, standards, and procedures related to the security of the system. || Artifact || Policies, standards and procedures for employees within training (completed training report).
|}

=== AT.L2-3.2.2 – Role-Based Training ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AT.L2-3.2.2_Details|'''AT.L2-3.2.2''']] Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities.|-
|-
| [a] information security-related duties, roles, and responsibilities are defined. || Document || Policy/Procedures/Instruction, Job Role Matrix, Position Descriptions, User Roles.
|-
| [b] information security-related duties, roles, and responsibilities are assigned to designated personnel. || Artifact || Screenshot of breakout of different roles/permissions assigned to individuals (i.e. ActiveDirectory); Privilege Access Agreement.
|-
| [c] personnel are adequately trained to carry out their assigned information security-related duties, roles, and responsibilities. || Artifact || Screenshot of tool and/or training specifying security specific roles, duties and responsibilities; Screenshot of required certifications (i.e. Sec+, CISSP).
|}

=== AT.L2-3.2.3 – Insider Threat Awareness ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AT.L2-3.2.3_Details|'''AT.L2-3.2.3''']] Provide security awareness training on recognizing and reporting potential indicators of insider threat.
|-
| [a] potential indicators associated with insider threats are identified. || Document || Insidert Threat Policy/Procedures/Instruction; Insider Threat Training/Briefing.
|-
| [b] security awareness training on recognizing and reporting potential indicators of insider threat is provided to managers and employees. || Artifact || Screenshot of training records showing completion of Insider Threat training, emails showing completion of Insider Threat training, Screenshot of certificate showing completion with individual's name.
|}

== Audit and Accountability (AU) ==
=== AU.L2-3.3.1 – System Auditing ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.1_Details|'''AU.L2-3.3.1''']] Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.
|-
| [a] audit logs needed (i.e., event types to be logged) to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity are specified. || Document || SSP, policy, or auditing and logging process that defines specific types of events to be logged.
|-
| [b] the content of audit records needed to support monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity is defined. || Document || SSP, policy, or auditing and logging process that defines specific content of audit records/files.
|-
| [c] audit records are created (generated). || Screen Share || Screen share of tool that shows logs are generated for all systems.
|-
| [d] audit records, once created, contain the defined content. || Screen Share || Screen share of tool that shows logs contain defined content as defined in SSP, policy, or procedures.
|-
| [e] retention requirements for audit records are defined. || Document || SSP, Polocy, or Auditing and logging process that describes how long records are kept.
|-
| [f] audit records are retained as defined. || Screen Share || Screen share of tool that shows records and audit content retained at a minimum as defined.
|}

=== AU.L2-3.3.2 – User Accountability ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.2_Details|'''AU.L2-3.3.2''']] Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions.
|-
| [a] the content of the audit records needed to support the ability to uniquely trace users to their actions is defined. || Document || SSP, policy, or process that defines actions traced back to individuals.
|-
| [b] audit records, once created, contain the defined content. || Screen Share || Screen share of tool that shows audit records traced to specific users/roles.
|}

=== AU.L2-3.3.3 – Event Review ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.3_Details|'''AU.L2-3.3.3''']] Review and update logged events.
|-
| [a] a process for determining when to review logged events is defined. || Document || SSP, policy, or documented process that shows frequency of when to review types of logged events.
|-
| [b] event types being logged are reviewed in accordance with the defined review process. || Artifact || Evidence through a documented method such as meeting minutes, CAB minutes, etc. of log sources and log events being logged at the defined frequency.
|-
| [c] event types being logged are updated based on the review. || Artifact || Evidence of implementation based on the results of the review of logged events/sources through a ticket, meeting minutes, or screen share of the tool that shows changes implemented (finetuning).
|}

=== AU.L2-3.3.4 – Audit Failure Alerting ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.4_Details|'''AU.L2-3.3.4''']] Alert in the event of an audit logging process failure.
|-
| [a] personnel or roles to be alerted in the event of an audit logging process failure are identified. || Document || SSP, policy, or procedure that shows who needs to be notified in case of an audit failure.
|-
| [b] types of audit logging process failures for which alert will be generated are defined. || Document || SSP, policy, or procedure that shows what types of failure will generate notifications.
|-
| [c] identified personnel or roles are alerted in the event of an audit logging process failure. || Artifact || Artifact such as email or ticket that shows the identified personnel were alerted of any audit/logging process failure as defined.
|}

=== AU.L2-3.3.5 – Audit Correlation ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.5_Details|'''AU.L2-3.3.5''']] Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.
|-
| [a] audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity are defined. || Document || SSP, policy, or procedure covering audit logging, monitoring, and reporting.
|-
| [b] defined audit record review, analysis, and reporting processes are correlated. || Artifact || Artifact showing an audit event and the resultant corrective action or actions to the event; this can be a Help Desk ticket, meeting notes, or a change control board items showing the event and any corrective action taken.
|}

=== AU.L2-3.3.6 – Reduction & Reporting ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.6_Details|'''AU.L2-3.3.6''']] Provide audit record reduction and report generation to support on-demand analysis and reporting.
|-
| [a] an audit record reduction capability that supports on-demand analysis is provided. || Screen Share || Screen share of the logging environment where an event can be selected and traced back to a specific device, or dashboard showing realtime event analysis.
|-
| [b] a report generation capability that supports on-demand reporting is provided. || Screen Share || Screen share showing the generation of an on demand report.
|}

=== AU.L2-3.3.7 – Authoritative Time Source ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.7_Details|'''AU.L2-3.3.7''']] Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.
|-
| [a] internal system clocks are used to generate time stamps for audit records. || Screen Share || Screen share showing the NTP settings of a windows, Unix, Linux device; a screen share showing the NTP settings of network appliances.
|-
| [b] an authoritative source with which to compare and synchronize internal system clocks is specified. || Document || SSP or policy indicating that devices need to be synched to a local authoritative time device that is synched with an authoritative time service.
|-
| [c] internal system clocks used to generate time stamps for audit records are compared to and synchronized with the specified authoritative time source. || Screen Share || Screen share showing device logging appliance time is point to the appropriate authoritative time server.
|}

=== AU.L2-3.3.8 – Audit Protection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.8_Details|'''AU.L2-3.3.8''']] Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
|-
| [a] audit information is protected from unauthorized access. || Screen Share || Screen share showing operating system permissions on the audit folders being restricted to appropriate users.
|-
| [b] audit information is protected from unauthorized modification. || Screen Share || Screen share showing operating system permissions on the audit folders being restricted to appropriate users.
|-
| [c] audit information is protected from unauthorized deletion. || Screen Share || Screen share showing operating system permissions on the audit folders being restricted to appropriate users.
|-
| [d] audit logging tools are protected from unauthorized access. || Screen Share || Artifact showing access permissions in the SIEM tool.
|-
| [e] audit logging tools are protected from unauthorized modification. || Screen Share || Artifact showing update permissions in the SIEM tool.
|-
| [f] audit logging tools are protected from unauthorized deletion. || Screen Share || Artifact showing delete permissions in the SIEM tool.
|}

=== AU.L2-3.3.9 – Audit Management ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_AU.L2-3.3.9_Details|'''AU.L2-3.3.9''']] Limit management of audit logging functionality to a subset of privileged users.
|-
| [a] a subset of privileged users granted access to manage audit logging functionality is defined. || Document || SSP or policy indicating which users or groups have access to audit logs.
|-
| [b] management of audit logging functionality is limited to the defined subset of privileged users. || Screen Share || Artifact showing SIEM or OS folder permissions (this should be limited to the assigned users or groups); artifact showing an ACL setting in SIEM tool in regards to logs.
|}

== Configuration Management (CM) ==
=== CM.L2-3.4.1 – System Baselining ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.1_Details|'''CM.L2-3.4.1''']] Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.
|-
| [a] a baseline configuration is established. || Document || Documentation showing or explaining standard imaging process (how standard images are deployed and where they are stored).
|-
| [b] the baseline configuration includes hardware, software, firmware, and documentation. || Artifact || Screenshot of repository of where images are maintained and information relating to hardware, software, and firmware.
|-
| [c] the baseline configuration is maintained (reviewed and updated) throughout the system development life cycle. || Artifact || Screenshot/evidence displaying management of baseline configurations (how often they are being managed as stated).
|-
| [d] a system inventory is established. || Document || Screenshot/evidence displaying inventory listing of approved products for use.
|-
| [e] the system inventory includes hardware, software, firmware, and documentation. || Artifact || Screeenshot/evidence displaying inventory listing of approved products and versions permitted for use.
|-
| [f] the inventory is maintained (reviewed and updated) throughout the system development life cycle. || Artifact || Screeenshot/evidence displaying management of baseline configurations (How often and are they being managed as stated.
|}

=== CM.L2-3.4.2 – Security Configuration Enforcement ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.2_Details|'''CM.L2-3.4.2''']] Establish and enforce security configuration settings for information technology products employed in organizational systems.
|-
| [a] security configuration settings for information technology products employed in the system are established and included in the baseline configuration. || Document || Documentation explaining methodology used by organization to create secure baselines (STIGs, benchmarks).
|-
| [b] security configuration settings for information technology products employed in the system are enforced. || Artifact || Evidence of tool/s used to enforce security configurations to ensure images used are free from modification unless authorized.
|}

=== CM.L2-3.4.3 – System Change Management ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.3_Details|'''CM.L2-3.4.3''']] Track, review, approve or disapprove, and log changes to organizational systems.
|-
| [a] changes to the system are tracked. || Artifact || Evidence of IT Service Management tool / process used to track system changes.
|-
| [b] changes to the system are reviewed. || Artifact || Evidence of IT Service Management tool / process used to review system changes.
|-
| [c] changes to the system are approved or disapproved. || Artifact || Evidence of IT Service Management tool / process used to approve/disapprove system changes.
|-
| [d] changes to the system are logged. || Artifact || Evidence of IT Service Management tool / process used to log system changes.
|}

=== CM.L2-3.4.4 – Security Impact Analysis ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.4_Details|'''CM.L2-3.4.4''']] Analyze the security impact of changes prior to implementation.
|-
| [a] the security impact of changes to the system is analyzed prior to implementation. || Artifact || Document explaining that security impact analysis of proposed changes to a system is conducted prior to implementation.
|}

=== CM.L2-3.4.5 – Access Restrictions for Change ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.5_Details|'''CM.L2-3.4.5''']] Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.
|-
| [a] physical access restrictions associated with changes to the system are defined. || Document || Document explaining the process of how physical access restrictions are defined for an individuals ability to make system changes.
|-
| [b] physical access restrictions associated with changes to the system are documented. || Document || Document explaining the process of how physical access restrictions are defined for an individuals ability to make system changes are documented; access request process.
|-
| [c] physical access restrictions associated with changes to the system are approved. || Artifact || Evidence of process of how physical access to systems are granted (i.e. physical access request sample).
|-
| [d] physical access restrictions associated with changes to the system are enforced. || Physical Review || Evidence of process of how physical access to systems are enforced (physical access system).
|-
| [e] logical access restrictions associated with changes to the system are defined. || Document || Document explaining the process of how logical access restrictions are defined for an individual's ability to make system changes.
|-
| [f] logical access restrictions associated with changes to the system are documented. || Document || Document explaining the process of how logical access restrictions are defined for an individual's ability to make system changes are documented.
|-
| [g] logical access restrictions associated with changes to the system are approved. || Artifact || Evidence of process of how logical access to systems are granted.
|-
| [h] logical access restrictions associated with changes to the system are enforced. || Artifact || Evidence of process of how logical access to systems are enforced.
|}

=== CM.L2-3.4.6 – Least Functionality ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.6_Details|'''CM.L2-3.4.6''']] Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.
|-
| [a] essential system capabilities are defined based on the principle of least functionality. || Document || Documentation explaining how systems are configured to utilize the principle of least functionality for designated users.
|-
| [b] the system is configured to provide only the defined essential capabilities. || Screen Share || Evidence displaying how systems are configured to utilize the principle of least functionality for designated users; disabled service settings, accepted standards for hardening (CIS benchmarks, etc.).
|}

=== CM.L2-3.4.7 – Nonessential Functionality ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.7_Details|'''CM.L2-3.4.7''']] Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.
|-
| [a] essential programs are defined. || Document || Documented essential programs specified; build documents; software center; SSP.
|-
| [b] the use of nonessential programs is defined. || Document || Documented listing of nonessential programs (whatever is NOT specified in [a]); AUP/User Agreement may identify nonessential use/programs.
|-
| [c] the use of nonessential programs is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict nonessential programs displays restrictions as defined (McAfee ePO settings, Carbon Black rules, etc.).
|-
| [d] essential functions are defined. || Document || Documented essential functions are specified.
|-
| [e] the use of nonessential functions is defined. || Document || Documented nonessential functions are specified.
|-
| [f] the use of nonessential functions is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict essential/nonessential functions displays restrictions as defined.
|-
| [g] essential ports are defined. || Document || Documented essential ports are specified.
|-
| [h] the use of nonessential ports is defined. || Document || Documented nonessential ports functions are specified.
|-
| [i] the use of nonessential ports is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict essential/nonessential ports displays restrictions as defined (FW rules; McAfee; GPO, etc.).
|-
| [j] essential protocols are defined. || Document || Documented essential protocols are specified.
|-
| [k] the use of nonessential protocols is defined. || Document || Documented nonessential protocols functions are specified.
|-
| [l] the use of nonessential protocols is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict essential/nonessential protocols displays restrictions as defined (FW rules; GPO, etc.).
|-
| [m] essential services are defined. || Document || Documented essential services specified.
|-
| [n] the use of nonessential services is defined. || Document || Documented nonessential services functions are specified.
|-
| [o] the use of nonessential services is restricted, disabled, or prevented as defined. || Screen Share || Tool used to restrict essential/nonessential services displays restrictions as defined.
|}

=== CM.L2-3.4.8 – Application Execution Policy ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.8_Details|'''CM.L2-3.4.8''']] Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.
|-
| [a] a policy specifying whether whitelisting or blacklisting is to be implemented is specified. || Document || Documentation explaining whitelisting or blacklisting process.
|-
| [b] the software allowed to execute under whitelisting or denied use under blacklisting is specified. || Document || Documentation explaining whitelisting or blacklisting process for software.
|-
| [c] whitelisting to allow the execution of authorized software or blacklisting to prevent the use of unauthorized software is implemented as specified. || Screen Share || Tool used for whitelisting or blacklisting for software shows capability of restricting/authorizing software (Carbon Black dashboard, "SW Store", web proxies, DNS Blackhole, etc.).
|}

=== CM.L2-3.4.9 – User-Installed Software ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CM.L2-3.4.9_Details|'''CM.L2-3.4.9''']] Control and monitor user-installed software.
|-
| [a] a policy for controlling the installation of software by users is established. || Document || Documented software authorization process or methodology for approval.
|-
| [b] installation of software by users is controlled based on the established policy. || Screen Share || Evidence that approval/restriction in installation of software by authorized personnel is implemented as specified (AUP, GPO, etc.).
|-
| [c] installation of software by users is monitored. || Screen Share || Evidence that installation of software by authorized personnel is monitored (SCCM groups, SW Center, etc.).
|}

== Identification and Authentication (IA) ==
=== IA.L2-3.5.1 – Identification [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.1_Details|'''IA.L2-3.5.1''']] Identify information system users, processes acting on behalf of users, or devices.
|-
| [a] system users are identified. || Document || Based on what is defined in their documentation (SSP, AUP, Policy, SOP), request to see a sample of non-privileged/privileged users in AD OU group (overlaps with 3.1.1 and 3.1.5).
|-
| [b] processes acting on behalf of users are identified. || Document || Based on what is defined in their documentation (SSP, AUP, Policy, SOP), request to see a sample of service accounts in AD OU group (overlaps with 3.1.1 and 3.1.5).
|-
| [c] devices accessing the system are identified. || Document || Based on what is defined in their documentation (SSP, AUP, Policy, SOP), request to see a sample of domain-joined workstation & servers in AD OU group (overlaps with 3.1.1 and 3.1.5). For network devices, request screen share/artifact to show how they are identified on the enterprise network.
|}

=== IA.L2-3.5.2 – Authentication [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.2_Details|'''IA.L2-3.5.2''']] Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems.
|-
| [a] the identity of each user is authenticated or verified as a prerequisite to system access. || Screen Share || If the user logs in with non-privileged account during other demoes and then a privileged account, then this should be satisfied. If screen share is unavailable, request logs to show successful and unsuccessful login by privileged and non-privilged users.
|-
| [b] the identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access. || Screen Share || Request a log that shows successful/unsuccessful service account trying to log on to company's asset.
|-
| [c] the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access. || Screen Share || Request a log that shows domain-joined workstation/server authenticating to AD (focus on the MAC/IP address/hostname).
|}

=== IA.L2-3.5.3 – Multifactor Authentication ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.3_Details|'''IA.L2-3.5.3''']] Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
|-
| [a] privileged accounts are identified. || Document || Based on what is defined in their documentation, request to see a sample of privileged users in AD OU group. Overlaps with 3.1.5. Screenshot/screen share to show implementation is enforced.
|-
| [b] multifactor authentication is implemented for local access to privileged accounts. || Screen Share || SSP, AUP, Policy, SOP that defines that MFA is needed for privileged local access.
|-
| [c] multifactor authentication is implemented for network access to privileged accounts. || Screen Share || Within the MFA implementation mechanism, show that privileged users are forced to use MFA; Screenshot/Screen share to show implementation is enforced.
|-
| [d] multifactor authentication is implemented for network access to non-privileged accounts. || Screen Share || Within the MFA implementation mechanism, show that non-privileged users are forced to use MFA; Screenshot/Screen share to show implementation is enforced.
|}

=== IA.L2-3.5.4 – Replay-Resistant Authentication ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.4_Details|'''IA.L2-3.5.4''']] Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.
|-
| [a] replay-resistant authentication mechanisms are implemented for network account access to privileged and non-privileged accounts. || Screen Share || Show the GPO setting that enforces Kerberos within AD. If MFA is used, show the implementation to enforce replay resistant techniques. For non-windows, show the technical solution to enforce replay resistant attacks.
|}

=== IA.L2-3.5.5 – Identifier Reuse ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.5_Details|'''IA.L2-3.5.5''']] Prevent reuse of identifiers for a defined period.
|-
| [a] a period within which identifiers cannot be reused is defined. || Document || SSP, policies, or SOP that defines identifier reuse.
|-
| [b] reuse of identifiers is prevented within the defined period. || Artifact || Show the GPO setting/technical solution that enforces what is defined in policy/documentation (this can be automated or manual process; screen share/artifacts can be presented to satisfy this requirement.
|}

=== IA.L2-3.5.6 – Identifier Handling ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.6_Details|'''IA.L2-3.5.6''']] Disable identifiers after a defined period of inactivity.
|-
| [a] a period of inactivity after which an identifier is disabled is defined. || Document || SSP, policy that defines the period of inactivity after which an identifier is disabled.
|-
| [b] identifiers are disabled after the defined period of inactivity. || Screen Share || Screen share AD or similar tool supporting directory-based identity-related services for disabled accounts (can be done by hand or script).
|}

=== IA.L2-3.5.7 – Password Complexity ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.7_Details|'''IA.L2-3.5.7''']] Enforce a minimum password complexity and change of characters when new passwords are created.
|-
| [a] password complexity requirements are defined. || Document || SSP, policy that defines password complexity requirements.
|-
| [b] password change of character requirements are defined. || Document || SSP, policy that defines change of character requirements are defined.
|-
| [c] minimum password complexity requirements as defined are enforced when new passwords are created. || Screen Share || Screen share of AD or similar directory-based identity-related service tool to show complexity requirements.
|-
| [d] minimum password change of character requirements as defined are enforced when new passwords are created. || Screen Share || Screen share of Group Policy configuration or similar tool providing centralized management and configuration of operating systems, applications, and users' settings to show that characters must be changed.
|}

=== IA.L2-3.5.8 – Password Reuse ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.8_Details|'''IA.L2-3.5.8''']] Prohibit password reuse for a specified number of generations.
|-
| [a] the number of generations during which a password cannot be reused is specified. || Document || SSP, policy that specifies the number of generations during which a password cannot be reused is specified.
|-
| [b] reuse of passwords is prohibited during the specified number of generations. || Screen Share || Screen share Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration to show reuse of passwords is prohibited.
|}

=== IA.L2-3.5.9 – Temporary Passwords ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.9_Details|'''IA.L2-3.5.9''']] Allow temporary password use for system logons with an immediate change to a permanent password.
|-
| [a] an immediate change to a permanent password is required when a temporary password is used for system logon. || Screen Share || Screen share of Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration to show "change password at first logon."
|}

=== IA.L2-3.5.10 – Cryptographically-Protected Passwords ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.1_Details|'''IA.L2-3.5.1''']] Store and transmit only cryptographically-protected passwords.
|-
| [a] passwords are cryptographically protected in storage. || Screen Share || Screen share Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration that Kerberos, or a similar network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner, is enabled.
|-
| [b] passwords are cryptographically protected in transit. || Screen Share || Screen share Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration that Kerberos, or a similar network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner, is enabled.
|}

=== IA.L2-3.5.11 – Obscure Feedback ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IA.L2-3.5.10_Details|'''IA.L2-3.5.10''']] Obscure feedback of authentication information.
|-
| [a] authentication information is obscured during the authentication process. || Screen Share || Screen share of Group Policy or similar tool providing centralized management and configuration of operating systems, applications, and users' settings in a directory-based identity-related service tool's configuration to show that passwords are obscured.
|}

== Incident Response (IR) ==
=== IR.L2-3.6.1 – Incident Handling ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IR.L2-3.6.1_Details|'''IR.L2-3.6.1''']] Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.
|-
| [a] an operational incident-handling capability is established. || Document || Incident Response SOP/Plan.
|-
| [b] the operational incident-handling capability includes preparation. || Document || Incident Response SOP/Plan, prior incident report, training, COOP plan.
|-
| [c] the operational incident-handling capability includes detection. || Document || Incident Response SOP/Plan; definition of tools used to detect; artifacts showing tools used; prior incident report.
|-
| [d] the operational incident-handling capability includes analysis. || Document || Incident Response SOP/Plan; Definition of tools used to analyze potential incidents; artifacts showing tools used for analysis; prior incident report.
|-
| [e] the operational incident-handling capability includes containment. || Document || Incident Response SOP/Plan; isolation/quarantine process; user training.
|-
| [f] the operational incident-handling capability includes recovery. || Document || Incident Response SOP/Plan; COOP Plan; prior incident reports, re-baselining impacted devices.
|-
| [g] the operational incident-handling capability includes user response. || Document || Incident Response SOP/Plan; user awareness training; Help Desk process.

|}

=== IR.L2-3.6.2 – Incident Reporting ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IR.L2-3.6.2_Details|'''IR.L2-3.6.2''']] Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.
|-
| [a] incidents are tracked. || Artifact || Incident Response SOP/Plan; ITSM artifact; technical implementation for incident tracking.
|-
| [b] incidents are documented. || Artifact || Incident Response SOP/Plan; ITSM artifact; technical implementation for incident tracking.
|-
| [c] authorities to whom incidents are to be reported are identified. || Document || Incident Response SOP/Plan.
|-
| [d] organizational officials to whom incidents are to be reported are identified. || Document || Incident Response SOP/Plan.
|-
| [e] identified authorities are notified of incidents. || Screen Share || Prior incident report; DIBNET login; prior email notifications.
|-
| [f] identified organizational officials are notified of incidents. || Artifact || Prior incident report; prior email notifications; tabletop exercises.
|}

=== IR.L2-3.6.3 – Incident Response Testing ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_IR.L2-3.6.3_Details|'''IR.L2-3.6.3''']] Test the organizational incident response capability.
|-
| [a] the incident response capability is tested. || Artifact || Incident response table top/scheduled or unscheduled test or penetration test.
|}

== Maintenance (MA) ==
=== MA.L2-3.7.1 – Perform Maintenance ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.1_Details|'''MA.L2-3.7.1''']] Perform maintenance on organizational systems.
|-
| [a] system maintenance is performed. || Artifact || Establish typical maintenance activities (HVAC, UPS, power distribution, generators, copier maintenance) that are performed; maintenance agreements or contracts detailing these types of activities are acceptable; interview responses should be considered. This requirement should not be confused with 3.14.1 - report, remediate, and correct system flaws in a timely manner (patch management).
|}

=== MA.L2-3.7.2 – System Maintenance Control ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.2_Details|'''MA.L2-3.7.2''']] Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance.
|-
| [a] tools used to conduct system maintenance are controlled. || Artifact || Tools may largely depend on the assessed environment; discussion examples include network diagnostic and monitoring tools (including hardware and software); artifacts could demonstrate secured locations/areas for these tools (photos) or checkout sheets/rosters (documents) depicting responsible personnel and the dates/times of checkout.
|-
| [b] techniques used to conduct system maintenance are controlled. || Artifact || Processes for scheduling, performing, documenting, reviewing, approving, and monitoring maintenance and repairs for the information system.
|-
| [c] mechanisms used to conduct system maintenance are controlled. || Artifact || Processes for scheduling, performing, documenting, reviewing, approving, and monitoring maintenance and repairs for the information system.
|-
| [d] personnel used to conduct system maintenance are controlled. || Physical Review || Screenshot of who is authorized to conduct maintenance; maintenance personnel training program.
|}

=== MA.L2-3.7.3 – Equipment Sanitization ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.3_Details|'''MA.L2-3.7.3''']] Ensure equipment removed for off-site maintenance is sanitized of any CUI.
|-
| [a] equipment to be removed from organizational spaces for off-site maintenance is sanitized of any CUI. || Artifact || Document or artifact; record if equipment sanitized; categories of sanitization/destruction defined; sanitization procedural document.
|}

=== MA.L2-3.7.4 – Media Inspection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.4_Details|'''MA.L2-3.7.4''']] Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems.
|-
| [a] media containing diagnostic and test programs are checked for malicious code before being used in organizational systems that process, store, or transmit CUI. || Artifact || Screenshot of diagnostic/test program being used (such as Symantec and McAfee on access scans…).
|}

=== MA.L2-3.7.5 – Nonlocal Maintenance ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.5_Details|'''MA.L2-3.7.5''']] Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete.
|-
| [a] multifactor authentication is used to establish nonlocal maintenance sessions via external network connections. || Screen Share || Describe MFA used to remote from external service to organizational systems for maintenance and screenshot of MFA (3.5.3)(points associated with admin).
|-
| [b] nonlocal maintenance sessions established via external network connections are terminated when nonlocal maintenance is complete. || Screen Share || Screenshot VPN session timeout.
|}

=== MA.L2-3.7.6 – Maintenance Personnel ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MA.L2-3.7.6_Details|'''MA.L2-3.7.6''']] Supervise the maintenance activities of maintenance personnel without required access authorization.
|-
| [a] maintenance personnel without required access authorization are supervised during maintenance activities. || Document || System maintenance policy; list of authorized personnel; maintenance records or, contracts/SLAs; WebEx.
|}

== Media Protection (MP) ==
=== MP.L2-3.8.1 – Media Protection ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.1_Details|'''MP.L2-3.8.1''']] Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital.
|-
| [a] paper media containing CUI is physically controlled. || Document || Policy showing CUI paper media is controlled; artifact showing who has access; artifacts/records of inventories conducted; media check out procedures (i.e. file cabinets, encryption, password protection).
|-
| [b] digital media containing CUI is physically controlled. || Document || Policy showing CUI digital media is controlled; artifact showing who has access; artifacts/records of inventories conducted; media check out procedures (i.e. file cabinets, external drives, USBs, encryption, password protection).
|-
| [c] paper media containing CUI is securely stored. || Physical Review || Check out/sign out sheets; possible photo of storage container/video walk through of storage area; badge reader logs or access lists for keys for secured areas; interview response considered (i.e. file cabinets, encryption, password protection).
|-
| [d] digital media containing CUI is securely stored. || Physical Review || Check out/sign out sheets; possible photo of storage container/video walk through of storage area; badge reader logs or access lists for keys for secured areas; interview response considered (i.e. file cabinets, external drives, USBs, encryption, password protection).
|}

=== MP.L2-3.8.2 – Media Access ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.2_Details|'''MP.L2-3.8.2''']] Limit access to CUI on system media to authorized users.
|-
| [a] access to CUI on system media is limited to authorized users. || Artifact || Document describing how CUI is limited AND artifact showing principle of least access is implemented.
|}

=== MP.L2-3.8.3 – Media Disposal [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.3_Details|'''MP.L2-3.8.3''']] Sanitize or destroy information system media containing Federal Contract Information before disposal or release for reuse.
|-
| [a] system media containing CUI is sanitized or destroyed before disposal. || Document || Policy or artifact of media destruction logs; certificates of destruction; SLAs or contracts.
|-
| [b] system media containing CUI is sanitized before it is released for reuse. || Document || Policy or artifact describing method to sanitize, software used (i.e. DoD Wipe, ShredIT and Iron Mountain; Blancco; GDisk, DBAN).
|}

=== MP.L2-3.8.4 – Media Markings ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.4_Details|'''MP.L2-3.8.4''']] Mark media with necessary CUI markings and distribution limitations.
|-
| [a] media containing CUI is marked with applicable CUI markings. || Physical Review || Document or artifact showing CUI markings (i.e. labeling standards ).
|-
| [b] media containing CUI is marked with distribution limitations. || Physical Review || Document or artifact showing distro limitations (i.e. labeling standards ).
|}

=== MP.L2-3.8.5 – Media Accountability ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.5_Details|'''MP.L2-3.8.5''']] Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas.
|-
| [a] access to media containing CUI is controlled. || Document || Policy, artifact of audit logs showing tracking, Access Control Lists, records of transport activities (i.e. USB drives, CDs, chain of custody.
|-
| [b] accountability for media containing CUI is maintained during transport outside of controlled areas. || Artifact || Artifact of audit logs showing tracking, Access Control Lists, records of transport activities (i.e. USB drives, CDs; chain of custody.
|}

=== MP.L2-3.8.6 – Portable Storage Encryption ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.6_Details|'''MP.L2-3.8.6''']] Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards.
|-
| [a] the confidentiality of CUI stored on digital media is protected during transport using cryptographic mechanisms or alternative physical safeguards. || Artifact || Artifact showing crypto mechanisms used to protect (are they FIPS 140-2 [13.11]); artifact showing what alternative physical safeguards are in place (i.e. encryption; BitLocker; McAfee ).
|}

=== MP.L2-3.8.7 – Removable Media ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.7_Details|'''MP.L2-3.8.7''']] Control the use of removable media on system components.
|-
| [a] the use of removable media on system components is controlled. || Artifact || Policy showing if removable media is allowed; writable removable media is restricted; tracking artifacts; what tools are used (i.e. Carbon Black, Crowd Strike, GPO, Zoho Desktop Central); procedure/process describing what happens if it is lost; what mechanisms are in place to control/restrict removable media (i.e. Active Directory Groups and Group Policy artifact showing restriction).
|}

=== MP.L2-3.8.8 – Shared Media ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.8_Details|'''MP.L2-3.8.8''']] Prohibit the use of portable storage devices when such devices have no identifiable owner.ASSESSMENT OBJECTIVES'''
|-
| [a] the use of portable storage devices is prohibited when such devices have no identifiable owner. || Artifact || Policy and/or artifact showing company stance on portable storage devices if there is no owner (are personal USB devices allowed or are they company-issued; artifact showing alerts if device is connected to network (i.e. external HDD, Carbon Black, Crowd Strike, GPO, Zoho Desktop Central.
|}

=== MP.L2-3.8.9 – Protect Backups ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_MP.L2-3.8.9_Details|'''MP.L2-3.8.9''']] Protect the confidentiality of backup CUI at storage locations.
|-
| [a] the confidentiality of backup CUI is protected at storage locations. || Artifact || Policy on system backups; artifact showing media labeling; artifact showing encyption (is it FIPS 140-2 [13.11]); Access Control List artifact (i.e. backup tapes, Tivoli Storage Manager).
|}

== Personnel Security (PS) ==
=== PS.L2-3.9.1 – Screen Individuals ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PS.L2-3.9.1_Details|'''PS.L2-3.9.1''']] Screen individuals prior to authorizing access to organizational systems containing CUI.
|-
| [a] individuals are screened prior to authorizing access to organizational systems containing CUI. || Artifact || Screenshot of records of screened personnel/background checks.
|}

=== PS.L2-3.9.2 – Personnel Actions ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PS.L2-3.9.2_Details|'''PS.L2-3.9.2''']] Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers.
|-
| [a] a policy and/or process for terminating system access and any credentials coincident with personnel actions is established. || Document || Personnel security policy/procedures/instruction; Access control policy/procedure/instruction.
|-
| [b] system access and credentials are terminated consistent with personnel actions such as termination or transfer. || Artifact || Screenshot of records of personnel transfer and termination actions.
|-
| [c] the system is protected during and after personnel transfer actions. || Artifact || Completed outprocessing checklist.
|}

== Physical Protection (PE) ==
=== PE.L2-3.10.1 – Limit Physical Access [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.1_Details|'''PE.L2-3.10.1''']] Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals.
|-
| [a] authorized individuals allowed physical access are identified. || Artifact || Authorized personnel (names) access list.
|-
| [b] physical access to organizational systems is limited to authorized individuals. || Physical Review || Badge reader logs, audit logs, and/or card swipe test.
|-
| [c] physical access to equipment is limited to authorized individuals. || Physical Review || Badge reader logs, audit logs, and/or card swipe test.
|-
| [d] physical access to operating environments is limited to authorized. || Physical Review || Badge reader logs, audit logs, and/or card swipe test.
|}

=== PE.L2-3.10.2 – Monitor Facility ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.2_Details|'''PE.L2-3.10.2''']] Protect and monitor the physical facility and support infrastructure for organizational systems.
|-
| [a] the physical facility where organizational systems reside is protected. || Physical Review || Physical security measures and barriers into the physical facility (cameras/locks/gates/guards, etc.).
|-
| [b] the support infrastructure for organizational systems is protected. || Physical Review || Physical barriers to entries into computer spaces, server rooms, etc.
|-
| [c] the physical facility where organizational systems reside is monitored. || Physical Review || Audit logs/how the physical facility is being monitored (cameras/access system/guards, etc.).
|-
| [d] the support infrastructure for organizational systems is monitored. || Physical Review || Audit logs/how the physical facility is being monitored (cameras/access system/guards, etc.).
|}

=== PE.L2-3.10.3 – Escort Visitors [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.3_Details|'''PE.L2-3.10.3''']] Escort visitors and monitor visitor activity.
|-
| [a] visitors are escorted. || Physical Review || Policy/procedures/instruction on methodology for handling non-authorized personnel (entry to exit).
|-
| [b] visitor activity is monitored. || Physical Review || Policy/procedures/instructio on methodology for handling non-authorized personnel (entry to exit).
|}

=== PE.L2-3.10.4 – Physical Access Logs [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.4_Details|'''PE.L2-3.10.4''']] Maintain audit logs of physical access.
|-
| [a] audit logs of physical access are maintained. || Artifact || Log or report from badging system.
|}

=== PE.L2-3.10.5 – Manage Physical Access [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.5_Details|'''PE.L2-3.10.5''']] Control and manage physical access devices.
|-
| [a] physical access devices are identified. || Document || Physical access control systems description, guard force contract/policy, key locks, logical systems specifications, etc.
|-
| [b] physical access devices are controlled. || Physical Review || Inventory records of physical access control devices (e.g. keys, locks, card readers, locks, etc.).
|-
| [c] physical access devices are managed. || Physical Review || List of security safeguards controlling access to the facility (e.g. cameras, monitoring by guards, isolation of IT systems equiment and or system components).
|}

=== PE.L2-3.10.6 – Alternative Work Sites ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_PE.L2-3.10.6_Details|'''PE.L2-3.10.6''']] Enforce safeguarding measures for CUI at alternate work sites.
|-
| [a] safeguarding measures for CUI are defined for alternate work sites. || Document || Telework agreement, Acceptable Use Policy and SOP for alternate work locations; user security training validation which includes physical/logical/technical protections of system at alternate work sites.
|-
| [b] safeguarding measures for CUI are enforced for alternate work sites. || Artifact || Monitoring/audit log of user activity and logical/physical/technical mechanisms in place to preclude unauthorized activity (telework agreement , AUP?).
|}

== Risk Assessment (RA) ==
=== RA.L2-3.11.1 – Risk Assessments ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_RA.L2-3.11.1_Details|'''RA.L2-3.11.1''']] Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI.
|-
| [a] the frequency to assess risk to organizational operations, organizational assets, and individuals is defined. || Document || Risk assessment policy.
|-
| [b] risk to organizational operations, organizational assets, and individuals resulting from the operation of an organizational system that processes, stores, or transmits CUI is assessed with the defined frequency. || Artifact || Copy of last risk assessment done within defined frequency.
|}

=== RA.L2-3.11.2 – Vulnerability Scan ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_RA.L2-3.11.2_Details|'''RA.L2-3.11.2''']] Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
|-
| [a] the frequency to scan for vulnerabilities in organizational systems and applications is defined. || Document || Policy/procedures/instruction addressing vulnerability scanning records.
|-
| [b] vulnerability scans are performed on organizational systems with the defined frequency. || Screen Share || System configuration settings of vulnerability scanning scheduling and vulnerability scan results of systems within defined frequency.
|-
| [c] vulnerability scans are performed on applications with the defined frequency. || Screen Share || System configuration settings of vulnerability scanning scheduling and vulnerability scan results of applications within defined frequency.
|-
| [d] vulnerability scans are performed on organizational systems when new vulnerabilities are identified. || Screen Share || View signatures in scanning tool/ad hoc scan performed as a result.
|-
| [e] vulnerability scans are performed on applications when new vulnerabilities are identified. || Screen Share || View signatures in scanning tool/ad hoc scan performed as a result.
|}

=== RA.L2-3.11.3 – Vulnerability Remediation ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_RA.L2-3.11.3_Details|'''RA.L2-3.11.3''']] Remediate vulnerabilities in accordance with risk assessments.
|-
| [a] vulnerabilities are identified. || Artifact || Scan results showing vulnerabilities identified.
|-
| [b] vulnerabilities are remediated in accordance with risk assessments. || Artifact || Screenshot/document of scan results of remediated vulnerabilities in accordance to risk assessments.
|}

== Security Assessment (CA) ==
=== CA.L2-3.12.1 – Security Control Assessment ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CA.L2-3.12.1_Details|'''CA.L2-3.12.1''']] Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.
|-
| [a] the frequency of security control assessments is defined. || Document || SSP.
|-
| [b] security controls are assessed with the defined frequency to determine if the controls are effective in their application. || Artifact || Copy of last security control assessment done within defined frequency.
|}

=== CA.L2-3.12.2 – Operational Plan of Action ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CA.L2-3.12.2_Details|'''CA.L2-3.12.2''']] Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.
|-
| [a] deficiencies and vulnerabilities to be addressed by the plan of action are identified. || Artifact || Plan of Action (POA).
|-
| [b] a plan of action is developed to correct identified deficiencies and reduce or eliminate identified vulnerabilities. || Artifact || Plan of Action (POA).
|-
| [c] the plan of action is implemented to correct identified deficiencies and reduce or eliminate identified vulnerabilities. || Artifact || Plan of Action (POA)/previously completed POAs.
|}

=== CA.L2-3.12.3 – Security Control Monitoring ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CA.L2-3.12.3_Details|'''CA.L2-3.12.3''']] Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.
|-
| [a] security controls are monitored on an ongoing basis to ensure the continued effectiveness of those controls. || Artifact || Collection of risk assessment results, internal or third-party audits/security assessments and/or continuous monitoring reports/alerts (SIEM tool, etc.).
|}

=== CA.L2-3.12.4 – System Security Plan ====
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_CA.L2-3.12.4_Details|'''CA.L2-3.12.4''']] Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.
|-
| [a] a system security plan is developed. || Document || SSP.
|-
| [b] the system boundary is described and documented in the system security plan. || Document || SSP and any supporting documentation.
|-
| [c] the system environment of operation is described and documented in the system security plan. || Document || SSP and any supporting documentation.
|-
| [d] the security requirements identified and approved by the designated authority as non-applicable are identified. || Document || SSP and required adjudication from DoD CIO.
|-
| [e] the method of security requirement implementation is described and documented in the system security plan. || Document || SSP and any supporting documentation.
|-
| [f] the relationship with or connection to other systems is described and documented in the system security plan. || Document || SSP and any supporting documentation.
|-
| [g] the frequency to update the system security plan is defined. || Document || SSP.
|-
| [h] system security plan is updated with the defined frequency. || Document || SSP/any previous versions.
|}

== System and Communications Protection (SC) ==
=== SC.L2-3.13.1 – Boundary Protection [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.1_Details|'''SC.L2-3.13.1''']] Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems.
|-
| [a] the external system boundary is defined. || Document || SSP, network diagrams, CUI flow, cloud provider FedRAMP Moderate.
|-
| [b] key internal system boundaries are defined. || Document || SSP, network diagrams, CUI flow.
|-
| [c] communications are monitored at the external system boundary. || Screen Share || SSP, logging server, boundary device configurations, monitoring policy.
|-
| [d] communications are monitored at key internal boundaries. || Screen Share || SSP, logging server, boundary device configurations, monitoring policy.
|-
| [e] communications are controlled at the external system boundary. || Screen Share || SSP, boundary device configurations, ACL, subnets, DMZ.
|-
| [f] communications are controlled at key internal boundaries. || Screen Share || SSP, boundary device configurations, ACL, subnets.
|-
| [g] communications are protected at the external system boundary. || Screen Share || Configurations for IPS/IDS, email gateway, VLAN, proxy, firewall, malware protection, DNS, TSL.
|-
| [h] communications are protected at key internal boundaries. || Screen Share || Configurations for IPS/IDS, VLAN, firewall, malware protection, SSL.
|}

=== SC.L2-3.13.2 – Security Engineering ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.2_Details|'''SC.L2-3.13.2''']] Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.
|-
| [a] architectural designs that promote effective information security are identified. || Document || SSP, config management policy, network diagram, CCB minutes, enterprise architecture process.
|-
| [b] software development techniques that promote effective information security are identified. || Document || SSP, config management policy, SDLC, CCB minutes.
|-
| [c] systems engineering principles that promote effective information security are identified. || Document || SSP, config management policy, CCB minutes, security architecture engineering.
|-
| [d] identified architectural designs that promote effective information security are employed. || Artifact || CCB minutes, Network diagrams and configurations, Project Plans.
|-
| [e] identified software development techniques that promote effective information security are employed. || Artifact || CCB minutes, SDLC, code scanner results, code management tracking.
|-
| [f] identified systems engineering principles that promote effective information security are employed. || Artifact || CCB minutes, configuration management, ITSM, patch management, lifecycle replacement processes.
|}

=== SC.L2-3.13.3 – Role Separation ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.3_Details|'''SC.L2-3.13.3''']] Separate user functionality from system management functionality.
|-
| [a] user functionality is identified. || Document || SSP, AUP.
|-
| [b] system management functionality is identified. || Document || SSP, Privileged Account Agreement.
|-
| [c] user functionality is separated from system management functionality. || Screen Share || Active Directory, Jump Boxes, GPO, VM, RDP.
|}

=== SC.L2-3.13.4 – Shared Resource Control ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.4_Details|'''SC.L2-3.13.4''']] Prevent unauthorized and unintended information transfer via shared system resources.
|-
| [a] unauthorized and unintended information transfer via shared system resources is prevented. || Screen Share || SSP, OS configurations, Linux containers, system/media reuse policies, certificate management policies, media destruction policies, printer configs, VDI configuration.
|}

=== SC.L2-3.13.5 – Public-Access System Separation [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.5_Details|'''SC.L2-3.13.5''']] Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
|-
| [a] publicly accessible system components are identified. || Document || SSP, network diagram, DMZ inventory/roles.
|-
| [b] subnetworks for publicly accessible system components are physically or logically separated from internal networks. || Artifact || Network diagram, IPAM, VLAN, DHCP, DMZ.
|}

=== SC.L2-3.13.6 – Network Communication by Exception ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.6_Details|'''SC.L2-3.13.6''']] Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).
|-
| [a] network communications traffic is denied by default. || Screen Share || Host and network firewall rules, SIEM logs, hit counts.
|-
| [b] network communications traffic is allowed by exception. || Screen Share || Host and network firewall rules, SIEM logs, hit counts.
|}

=== SC.L2-3.13.7 – Split Tunneling ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.7_Details|'''SC.L2-3.13.7''']] Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling).
|-
| [a] remote devices are prevented from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks (i.e., split tunneling). || Screen Share || VPN appliance/server configuration, endpoint VPN software configuration.
|}

=== SC.L2-3.13.8 – Data in Transit ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.8_Details|'''SC.L2-3.13.8''']] Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.
|-
| [a] cryptographic mechanisms intended to prevent unauthorized disclosure of CUI are identified. || Document || SSP, PKI policies, configuration processes, config management, email attachment encryption policy, removable media policy, data at rest policy.
|-
| [b] alternative physical safeguards intended to prevent unauthorized disclosure of CUI are identified. || Document || SSP, physical security policy.
|-
| [c] either cryptographic mechanisms or alternative physical safeguards are implemented to prevent unauthorized disclosure of CUI during transmission. || Screen Share || TLS settings, SSL settings, VPN/Wireless Access Points/Mobile Devices cryptographic settings, ODBC connector settings, SAN configuration, IPSec/MPLS, backup configuration, physical security.
|}

=== SC.L2-3.13.9 – Connections Termination ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.9_Details|'''SC.L2-3.13.9''']] Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity.
|-
| [a] a period of inactivity to terminate network connections associated with communications sessions is defined. || Document || SSP, network communications policy.
|-
| [b] network connections associated with communications sessions are terminated at the end of the sessions. || Screen Share || VPN appliance/server logs, VPN configurations, web server configurations, firewall connection settings.
|-
| [c] network connections associated with communications sessions are terminated after the defined period of inactivity. || Screen Share || VPN appliance/server logs, VPN configurations, web server configurations, frewall connection settings.
|}

=== SC.L2-3.13.10 – Key Management ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.10_Details|'''SC.L2-3.13.10''']] Establish and manage cryptographic keys for cryptography employed in organizational systems.
|-
| [a] cryptographic keys are established whenever cryptography is employed. || Artifact || SSP, PKI/certificate management policy, configuration management.
|-
| [b] cryptographic keys are managed whenever cryptography is employed. || Artifact || SSP, PKI/certificate management policy, configuration management, access control policy.
|}

=== SC.L2-3.13.11 – CUI Encryption ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.11_Details|'''SC.L2-3.13.11''']] Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.
|-
| [a] FIPS-validated cryptography is employed to protect the confidentiality of CUI. || Screen Share || VPN, wireless, mobile devices, client certificates, server certificates, disk encryption, Outlook plugin, external mail, backup media, ePO server, removable storage, SAN, file compression; look for FIPS mode enabled on appliances.
|}

=== SC.L2-3.13.12 – Collaborative Device Control ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.12_Details|'''SC.L2-3.13.12''']] Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device.
|-
| [a] collaborative computing devices are identified. || Document || SSP, network diagrams.
|-
| [b] collaborative computing devices provide indication to users of devices in use. || Physical Review || Physical inspection of device.
|-
| [c] remote activation of collaborative computing devices is prohibited. || Screen Share || Collaboration device configuration/console.
|}

=== SC.L2-3.13.13 – Mobile Code ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.13_Details|'''SC.L2-3.13.13''']] Control and monitor the use of mobile code.
|-
| [a] use of mobile code is controlled. || Screen Share || GPO settings, malware protection, software agent configurations, software development policies, code scanners, MDM configuration, firewall/secure web gateway/proxy config.
|-
| [b] use of mobile code is monitored. || Screen Share || SIEM/console monitoring.
|}

=== SC.L2-3.13.14 – Voice over Internet Protocol ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.14_Details|'''SC.L2-3.13.14''']] Control and monitor the use of Voice over Internet Protocol (VoIP) technologies.
|-
| [a] use of Voice over Internet Protocol (VoIP) technologies is controlled. || Artifact || VLAN, ACL, firewall config, VoIP gateway/condenser configuration.
|-
| [b] use of Voice over Internet Protocol (VoIP) technologies is monitored. || Artifact || SIEM/VoIP console monitoring, session border controller.
|}

=== SC.L2-3.13.15 – Communications Authenticity ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.15_Details|'''SC.L2-3.13.15''']] Protect the authenticity of communications sessions.
|-
| [a] the authenticity of communications sessions is protected. || Screen Share || SSL, TLS, SMB3, SFTP, IPSec, SSH, Kerberos configs, MPLS, Network Access Control.
|}

=== SC.L2-3.13.16 – Data at Rest ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SC.L2-3.13.16_Details|'''SC.L2-3.13.16''']] Protect the confidentiality of CUI at rest.
|-
| [a] the confidentiality of CUI at rest is protected. || Artifact || Full disk encryption, removable media encryption, SAN encryption, digital backups, mobile device encryption, third party offsite backup storage, cloud virtualization encryption, physical media storage policies.
|}

== System and Information Integrity (SI) ==
=== SI.L2-3.14.1 – Flaw Remediation [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.1_Details|'''SI.L2-3.14.1''']] Identify, report, and correct information and information system flaws in a timely manner.
|-
| [a] the time within which to identify system flaws is specified. || Document || SSP, patch management policy.
|-
| [b] system flaws are identified within the specified time frame. || Screen Share || Vulnerability management scanner output and scan policy configuration.
|-
| [c] the time within which to report system flaws is specified. || Document || SSP, patch management policy.
|-
| [d] system flaws are reported within the specified time frame. || Screen Share || ITSM/trouble tickets, vulnerability management scanner output.
|-
| [e] the time within which to correct system flaws is specified. || Document || SSP, patch management policy.
|-
| [f] system flaws are corrected within the specified time frame. || Screen Share || Vulnerability management scanner output and scan policy configuration.
|}

=== SI.L2-3.14.2 – Malicious Code ProTection [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.2_Details|'''SI.L2-3.14.2''']] Provide protection from malicious code at appropriate locations within organizational information systems.
|-
| [a] designated locations for malicious code protection are identified. || Document || SSP, system protection policy, network diagrams, security architecture documents.
|-
| [b] protection from malicious code at designated locations is provided. || Screen Share || Endpoint security settings, email/web proxy gateways, firewall, IPS sensor, MDM configuration, Network Access Control.
|}

=== SI.L2-3.14.3 – Security Alerts & Advisories ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.3_Details|'''SI.L2-3.14.3''']] Monitor system security alerts and advisories and take action in response.
|-
| [a] response actions to system security alerts and advisories are identified. || Document || SSP, vulnerability management policy, Incident Response Plan.
|-
| [b] system security alerts and advisories are monitored. || Artifact || Threat intelligence subscriptions, email advisories.
|-
| [c] actions in response to system security alerts and advisories are taken. || Artifact || ITSM/trouble tickets, user notifications, updates to firewall/IPS, etc.
|}

=== SI.L2-3.14.4 – Update Malicious Code Protection [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.4_Details|'''SI.L2-3.14.4''']] Update malicious code protection mechanisms when new releases are available.
|-
| [a] malicious code protection mechanisms are updated when new releases are available. || Screen Share || Antivirus console dashboard, firewall AV, Email gateway signatures,proxy, IPS updates.
|}

=== SI.L2-3.14.5 – System & File Scanning [CUI Data] ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.5_Details|'''SI.L2-3.14.5''']] Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed.
|-
| [a] the frequency for malicious code scans is defined. || Document || SSP, vulnerability management policy.
|-
| [b] malicious code scans are performed with the defined frequency. || Screen Share || Consoles for AV (endpoints, servers, and file shares), firewall, email gateway, proxy, IPS, MDM configurations.
|-
| [c] real-time malicious code scans of files from external sources as files are downloaded, opened, or executed are performed. || Screen Share || Consoles for AV (endpoints, servers, and file shares), firewall, email gateway, proxy, IPS, MDM configurations.
|}

=== SI.L2-3.14.6 – Monitor Communications for Attacks ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.6_Details|'''SI.L2-3.14.6''']] Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.
|-
| [a] the system is monitored to detect attacks and indicators of potential attacks. || Screen Share || Firewall, IPS, endpoint protection, SIEM alerts and reports.
|-
| [b] inbound communications traffic is monitored to detect attacks and indicators of potential attacks. || Screen Share || Firewall, IPS, endpoint protection, SIEM alerts and reports.
|-
| [c] outbound communications traffic is monitored to detect attacks and indicators of potential attacks. || Screen Share || Firewall, IPS, endpoint protection, SIEM alerts and reports.
|}

=== SI.L2-3.14.7 – Identify Unauthorized Use ===
{| class="wikitable"
! style="width: 35%"| '''Assessment Objectives'''
! style="width: 15%"| '''Collection Approach'''
! style="width: 50%"| '''Evidence Examples'''
|-
| colspan="3" | [[Practice_SI.L2-3.14.7_Details|'''SI.L2-3.14.7''']] Identify unauthorized use of organizational systems.
|-
| [a] authorized use of the system is defined. || Document || AUP, SSP.
|-
| [b] unauthorized use of the system is identified. || Artifact || SIEM logs, endpoint protection console, IPS, Firewall.
|}