nist-800-53

• NIST SP 800-53 Rev. 5 provides security and privacy controls for information systems and organizations developed under FISMA statutory authority.
  The publication establishes minimum requirements for federal information systems' security and is developed by NIST under Federal Information Security Modernization Act responsibilities, though it does not apply to national security systems without express federal approval.
• The publication was released in September 2020 and is available free of charge, with updates as of 12-10-2020.
  It is distributed through a DOI link and represents the current revision of NIST's foundational security and privacy control framework.
• Organizations are encouraged to use this publication voluntarily; it is not subject to copyright in the United States but attribution to NIST is appreciated.
  While mandatory for federal agencies, nongovernmental organizations may adopt the controls and guidance on a voluntary basis.
• This publication is consistent with OMB Circular A-130 and does not contradict standards made mandatory by the Secretary of Commerce.
  The guidance aligns with existing federal policy and does not supersede authorities of the Secretary of Commerce, OMB Director, or other federal officials.

Source: Pages 1-3

• NIST SP 800-53 provides a catalog of security and privacy controls designed to protect organizational operations, assets, individuals, and the Nation from threats including hostile attacks, human errors, natural disasters, and privacy risks.
  The controls serve as a comprehensive tool for defending against a diverse range of threats and risks that organizations face.
• The controls are flexible, customizable, and implemented through an organization-wide risk management process.
  This approach allows organizations to tailor controls to their specific context rather than applying a one-size-fits-all solution.
• The controls address requirements derived from mission and business needs, laws, executive orders, directives, regulations, policies, standards, and guidelines.
  The catalog draws from multiple authoritative sources to ensure comprehensive coverage of compliance obligations.
• The control catalog addresses both functionality and assurance perspectives to ensure trustworthiness of information technology products and systems.
  Functionality refers to the strength of functions and mechanisms, while assurance refers to confidence in the security or privacy capability provided.

Source: Page 4

• NIST SP 800-53 Revision 5 is a comprehensive publication providing security and privacy controls for information systems and organizations across federal, state, local, and tribal governments, and private sector entities.
  The publication addresses safeguarding measures for diverse computing platforms including general purpose systems, cyber-physical systems, cloud systems, mobile systems, industrial control systems, and IoT devices to protect organizational operations and individual privacy.
• The publication was developed by a Joint Task Force Interagency Working Group comprising representatives from civil, defense, and intelligence communities in collaboration with multiple federal agencies.
  Contributors included the Department of Defense, Office of the Director of National Intelligence, Committee on National Security Systems, Federal CIO Council, Federal CISO Council, and Federal Privacy Council, ensuring broad organizational input.
• A Risk Management Framework (RMF) has been established as a common foundation for managing security and privacy risks across the Federal Government.
  The RMF provides cost-effective, flexible, and consistent ways to manage risk and facilitates reciprocal acceptance of security and privacy control assessment evidence and authorization decisions among agencies.
• Control baselines previously included in SP 800-53 have been relocated to NIST SP 800-53B to separate control selection processes from the controls themselves.
  This change allows the controls to be used by diverse communities including systems engineers, security architects, software developers, enterprise architects, and mission or business owners without prescribing specific baseline selections.
• Revision 5 integrates information security and privacy controls into a single consolidated control catalog while introducing a new supply chain risk management control family.
  Controls in System and Services Acquisition and Supply Chain Risk Management families address developer-directed requirements for both internal organizational development and external contracting and acquisition processes.
• The publication emphasizes trustworthiness, resilience, and penetration resistance to address urgent national security needs regarding critical infrastructure vulnerabilities.
  Objectives include making information systems more resistant to attacks, limiting damage when attacks occur, ensuring cyber-resilience and survivability, and protecting individual privacy across all organizational sectors.

Source: Keywords section, pages 4-18

• The Errata section documents corrections, clarifications, and minor changes incorporated into NIST SP 800-53 Revision 5 as of December 10, 2020.
  These updates are either editorial (such as formatting or wording improvements) or substantive (changes that affect meaning or technical content). Additional issues and corrections will be posted as they are identified on the SP 800-53 Revision 5 publication details page.
• The majority of errata changes are editorial in nature, including standardization of capitalization, punctuation, and reference formatting across control descriptions.
  Examples include changing 'security or privacy incidents' to 'security incidents or breaches' throughout multiple controls, standardizing level descriptors to title case (Organization-level; Mission/business process-level; System-level), and updating citation formats from '[OMB A-130, Appendix II]' to '[OMB A-130]'.
• Substantive changes primarily affect technical control discussions, particularly in network security and supply chain areas.
  Notable substantive updates include clarifications on Border Gateway Protocol (BGP) routing protection in control SC-7(4), addition of references to source address validation techniques in SP 800-189, and changes to control titles like renaming IR-10 from 'Incident Analysis' to 'Integrated Information Security Analysis Team'.
• References and related controls were updated throughout the document to reflect current publications and correct cross-references.
  Updates include adding new references such as SP 800-137A for security assessment programs, SP 800-181 for workforce frameworks, and correcting control relationship citations (for example, changing IA-5(11) reference from 'IA-2(1)(2)' to 'IA-2(1) and IA-2(2)').
• Glossary and acronym sections were expanded to include 17 new acronyms and updated definitions to align with changes in control text.
  New acronyms include BGP, CAC, FICAM, IEEE, ISAC, ISAO, and others. Glossary entries for supply chain terms were also corrected by removing obsolete references.

Source: Pages 19-27

• Security controls are safeguards employed to protect the confidentiality, integrity, and availability of systems and information, while privacy controls manage privacy risks and ensure compliance with privacy requirements.
  Both types of controls are selected and implemented to satisfy requirements derived from laws, executive orders, directives, regulations, policies, standards, and mission needs.
• Modern information systems encompass diverse computing platforms including industrial control systems, cyber-physical systems, medical devices, and mobile devices, all sharing a common foundation of complex hardware, software, and firmware.
  These varied platforms support essential mission and business functions of organizations across different sectors.
• Organizations must answer three key questions when addressing information security and privacy controls: what controls are needed, whether selected controls have been implemented, and what level of assurance exists that controls are effective.
  These questions must be addressed within the context of a risk management process that identifies, assesses, responds to, and monitors security and privacy risks on an ongoing basis.
• The control catalog in this publication functions as a toolbox of safeguards, countermeasures, techniques, and processes to respond to security and privacy risks.
  Controls are employed as part of a well-defined risk management process that supports organizational information security and privacy programs.
• Responsible officials must understand the security and privacy risks that could adversely affect organizational operations, assets, individuals, other organizations, and the Nation.
  Officials must also understand the current status of their security and privacy programs and the controls planned or in place to make informed judgments and investments in response to identified risks.

Source: Section: INTRODUCTION, pages 28-29

• NIST SP 800-53 establishes security and privacy controls applicable to any organization or system that processes, stores, or transmits information.
  The controls are designed to be broadly applicable across different types of organizations and information systems, providing a comprehensive catalog for managing security and privacy risks.
• Implementation of these controls is mandatory for federal information systems under the Federal Information Security Modernization Act (FISMA) and OMB Circular A-130.
  Federal agencies and contractors operating federal information systems must implement minimum controls to protect federal information in accordance with these legal requirements.
• The publication provides a common lexicon and comprehensive control catalog to help organizations identify needed security and privacy controls and satisfy multiple compliance requirements.
  NIST 800-53 supports organizations in meeting FISMA, Privacy Act, OMB policies, and FIPS standards while improving communication about security and privacy concepts across organizations.
• The controls are independent of the control selection process, which can be guided by various frameworks including the Risk Management Framework, Cybersecurity Framework, or Privacy Framework.
  Organizations can choose their own risk-based selection methodology based on mission needs, threats, vulnerabilities, and compliance requirements while using the same control catalog.

Source: Section 1.1, pages 29-30

• NIST SP 800-53 is designed for a broad audience with diverse roles across system oversight, development, operations, assessment, and external partners.
  The publication serves individuals with system, information security, privacy, or risk management responsibilities at multiple organizational levels, as well as commercial entities producing security and privacy technologies.
• Target users include authorizing officials, chief information officers, and senior agency officials responsible for security and privacy oversight.
  These roles represent executive and strategic leadership responsible for governance and accountability of security and privacy controls.
• System development professionals including mission owners, program managers, system engineers, and security or privacy engineers are key users.
  These individuals design and integrate systems with security and privacy requirements in mind from the outset.
• Operational roles including system owners, information stewards, system administrators, and security or privacy officers implement and maintain controls day-to-day.
  These individuals ensure controls function effectively in live environments and manage ongoing compliance.
• Assessment and monitoring professionals including auditors, control assessors, evaluators, and analysts use the publication to evaluate control effectiveness.
  These roles verify that implemented controls meet requirements and identify gaps or deficiencies.
• Commercial entities producing components, technologies, and services supporting security or privacy are part of the intended audience.
  Industry partners use the publication to align their offerings with NIST control frameworks and standards.

Source: Section 1.2, page 30

• Managing security and privacy risks requires well-defined requirements, trustworthy system components, rigorous planning and development lifecycle management, application of security and privacy engineering principles, documented and integrated practices, and continuous monitoring of control effectiveness.
  This foundational requirement establishes that risk management is not a single activity but a comprehensive approach spanning system design, development, deployment, and ongoing operations across an organization.
• Organizations must continuously assess security and privacy risks to organizational operations, assets, individuals, other organizations, and the Nation from multiple sources including mission planning, system deployment, and ongoing operations.
  Realistic risk assessment requires understanding specific vulnerabilities in systems and organizations, the likelihood and potential impact of threats exploiting those vulnerabilities, and privacy risks from processing personally identifiable information.
• Security and privacy requirements must be satisfied with knowledge of the organizational risk management strategy, which considers cost, schedule, performance, and supply chain issues across the system lifecycle from design through disposal.
  A risk management process is then applied on an ongoing basis to address organizational concerns and ensure that control selection aligns with strategic priorities and constraints.
• Organizations have responsibility to select appropriate security and privacy controls, implement them correctly, and demonstrate their effectiveness in satisfying stated security and privacy requirements.
  Controls from the catalog can address traditional and advanced persistent threats and privacy risks in varied operational, environmental, and technical scenarios, and can be tailored to develop specialized baselines or overlays for unique missions or business applications.
• Risk assessments inform the control selection process, which results in an agreed-upon set of controls addressing specific mission or business needs consistent with organizational risk tolerance while preserving agility and flexibility.
  This selection process must accommodate increasingly sophisticated threats, changing missions and business requirements, rapidly evolving technologies, complex supply chains, and diverse operational environments.

Source: Section 1.3, pages 30-31

• NIST SP 800-53 defines controls that satisfy diverse security and privacy requirements while remaining consistent with and complementary to other recognized national and international standards.
  The controls are designed to be broadly applicable and technically sound, drawing from multiple sectors and standards organizations to ensure relevance across different domains.
• The publication incorporates requirements and controls from manufacturing, defense, financial, healthcare, transportation, energy, intelligence, industrial control, and audit communities.
  This multi-sector approach ensures the controls address the needs of diverse organizational types and operational environments.
• The controls are used by the national security community through publications such as CNSS Instruction No. 1253 to provide guidance specific to national security systems.
  This demonstrates the publication's role as a foundation for more specialized guidance in the national security domain.
• The controls have been mapped to international standards to maximize usability and applicability.
  This mapping facilitates adoption and implementation across organizations that must comply with multiple international standards frameworks.

Source: Section 1.4, page 32

• Security and privacy controls in NIST SP 800-53 are periodically reviewed and revised to reflect experience, changing laws, regulations, emerging threats, and new technologies.
  The controls represent current state-of-the-practice protection measures and must adapt to legal changes, regulatory updates, new vulnerabilities, evolving attack methods, and technological advances.
• The control catalog undergoes continuous change through withdrawal, revision, and addition of controls over time.
  This dynamic approach ensures the catalog remains current and relevant to organizational security and privacy needs.
• Proposed modifications to controls must pass through a rigorous and transparent public review process to gather feedback and build consensus.
  This structured review process balances the need for change with the need for stability, resulting in a technically sound, flexible, and stable set of controls.

Source: Section 1.5, page 32

• Chapter Two explains fundamental concepts of security and privacy controls including their structure, organization, implementation approaches, and relationships.
  Chapter Two covers how controls are structured, organized in the consolidated catalog, can be implemented in different ways, and how security and privacy controls relate to each other and to trustworthiness and assurance.
• Chapter Three provides a consolidated catalog of security and privacy controls with explanation, implementation guidance, and references for each control.
  Each control in Chapter Three includes a discussion section explaining its purpose, useful information for implementation and assessment, a list of related controls showing dependencies, and references to supporting publications.
• The publication includes supporting materials such as References, Glossary, Acronyms, and Control Summaries for additional information on using security and privacy controls.
  These supplementary sections at the end of the document provide reference information and summaries to help organizations understand and apply the controls described in the publication.

Source: Section 1.6, pages 32-33

• This chapter covers the fundamental concepts that underpin security and privacy controls and their role in building trustworthy systems.
  The chapter addresses how controls are structured, organized, and implemented, as well as their relationship to requirements and their effects on system security and resilience.

Source: Section: THE FUNDAMENTALS, page 34

• Requirements are information security and privacy obligations imposed on organizations by laws, policies, regulations, standards, and risk assessments that determine necessary system characteristics.
  Requirements derive from multiple sources including federal policies like OMB A-130, and encompass both legal obligations and broader stakeholder protection needs that shape what security and privacy capabilities a system must have.
• Organizations categorize requirements into capability requirements, specification requirements, and statement of work requirements depending on their role in the system development life cycle.
  Capability requirements describe needed system capabilities; specification requirements detail hardware, software, and firmware implementations that can be assessed; and statement of work requirements specify actions to perform operationally or during development.
• Controls are descriptions of safeguards and protection capabilities selected and implemented to satisfy system requirements and achieve organizational security and privacy objectives.
  Controls can be administrative, technical, or physical in nature, and may require derived requirements or instantiated parameter values to provide appropriate implementation detail within the system development life cycle.
• The relationship between requirements and controls is that requirements establish what protection is needed while controls specify how that protection is achieved.
  Organizations select and implement controls in response to requirements; controls may necessitate additional specification through derived requirements or control parameter values to guide detailed implementation.

Source: Section 2.1, page 34

• Controls are organized into 20 families identified by two-character codes, each containing related controls addressing a specific security or privacy topic.
  Examples include AC for Access Control, PE for Physical and Environmental Protection, and IA for Identification and Authentication. This organization enables systematic selection and specification of controls in security planning.
• Each control family contains base controls and control enhancements, where enhancements add functionality, specificity, or strength to their base control.
  Control enhancements require selection of the base control and are used when systems require greater protection than the base control alone provides, determined through risk assessment and organizational needs.
• A complete control structure includes a base control section, discussion section, related controls section, control enhancements section, and references section.
  The control section prescribes the security capability; the discussion provides context and considerations; related controls identify supporting or impacting controls; enhancements supplement the base; and references point to applicable laws and guidance.
• Organizations can customize controls through assignment operations that allow complete flexibility in parameter values and selection operations that limit values to a provided list.
  These tailoring mechanisms let organizations define specific values for control parameters based on laws, regulations, policies, mission needs, and risk assessment. Once specified, the values become part of the control statement used for effectiveness assessment.
• Iteration and refinement provide additional flexibility beyond assignment and selection, allowing controls to be applied multiple times with different values or scoped appropriately to different situations.
  Iteration enables applying a control in different contexts with different parameters; refinement adds implementation detail or narrows scope. Together with assignment and selection, these mechanisms allow organizations to satisfy security and privacy requirements across organizational, mission, and system levels.
• The alphabetical arrangement of families and numerical ordering of controls within families does not indicate priority, importance, or implementation sequence.
  This ordering merely reflects the historical sequence in which controls were added to the catalog and helps with navigation and reference.
• Organizations designate responsibility for control development, implementation, assessment, and monitoring and have flexibility to implement controls in any manner satisfying mission needs within legal and regulatory constraints.
  This flexibility ensures that control implementation aligns with organizational context while meeting required security and privacy objectives.

Source: Section 2.2, pages 35-37

• There are three control implementation approaches: common (inheritable), system-specific, and hybrid.
  Each approach defines the scope of applicability, shared nature, and responsibility for control development, implementation, assessment, and authorization, helping organizations select and implement controls effectively.
• Common controls are controls whose implementation results in a capability that multiple systems or programs can inherit from an internal or external entity other than the system owner.
  Common controls can be inherited from mission or business lines, organizations, enclaves, environments of operation, sites, or other systems. Many physical, environmental, personnel security, and incident response controls are good candidates for common status.
• Common controls enable cost amortization and risk of single point of failure.
  The cost of development, implementation, assessment, authorization, and monitoring can be spread across multiple systems and organizational elements, but implementing common controls introduces the risk that a single failure affects all inheriting systems.
• System-specific controls are the primary responsibility of the system owner and authorizing official for that system.
  These controls are implemented when not designated as common, though they may introduce interoperability risks if not aligned with common controls.
• Hybrid controls split responsibilities between a common (inheritable) part and a system-specific part.
  For example, an organization may provide a predefined contingency plan template as the common part while individual system owners tailor it for their specific needs. The common control provider manages the common part and the system owner manages the system-specific part.
• The appropriate control implementation approach is context-dependent and cannot be determined solely from the control's language.
  Identifying the correct approach early in the system development life cycle enables significant cost savings and consistent application organization-wide, and requires coordination between the control provider and inheriting entities.
• Inheriting entities must examine control parameters such as assignments and selections to verify a common control adequately mitigates their specific risks.
  Controls with the same identifiers are not necessarily identical or equally effective for different systems; parameter customization is essential to ensure inherited controls meet individual system needs.

Source: Section 2.3, pages 38-39

• Security controls protect information systems from unauthorized access, use, disclosure, disruption, modification, or destruction to ensure confidentiality, integrity, and availability.
  Federal information security programs also manage security risk and ensure compliance with applicable security requirements.
• Privacy controls manage risks to individuals associated with the processing of PII, including creation, collection, use, processing, storage, maintenance, dissemination, disclosure, and disposal.
  Federal privacy programs ensure compliance with applicable privacy requirements.
• When a system processes PII, information security and privacy programs share responsibility for managing security risks to that PII.
  Due to this overlap, the controls selected to manage security risks are generally the same regardless of whether they are designated as security or privacy controls.
• Control implementation may affect both security and privacy program objectives, and control discussion sections highlight specific considerations for each discipline.
  These considerations help organizations determine the most effective implementation method, though the listed considerations are not exhaustive.
• Close collaboration between information security and privacy programs is necessary to select and implement appropriate controls for systems processing PII.
  Organizations must promote and institutionalize this collaboration to ensure both security and privacy objectives are met and risks are appropriately managed.

Source: Section 2.4, pages 40-41

• Trustworthiness means a system, component, or service is worthy of being trusted to fulfill its required functions across attributes such as reliability, dependability, performance, resilience, safety, security, privacy, and survivability.
  Trustworthiness requirements must be complete, well-defined, and accurately assessable to be meaningful in organizational risk management strategies.
• Functionality refers to the security and privacy features, functions, mechanisms, services, procedures, and architectures implemented within systems and their operating environments.
  Functionality is what the system does and how it operates to support security and privacy objectives.
• Assurance is the measure of confidence that system functionality is implemented correctly, operating as intended, and producing desired outcomes while accurately mediating and enforcing security and privacy policies.
  Assurance answers whether the system actually does what it is supposed to do with respect to meeting security and privacy requirements.
• Security and privacy controls address both functionality and assurance, with some controls focusing primarily on functionality, others on assurance, and some supporting both.
  Different controls serve different purposes in establishing trustworthy systems.
• Assurance can be enhanced through techniques that increase discipline in system architecture, software design, specifications, code style, and configuration management.
  Simplifying and narrowing analysis through rigorous development practices improves the ability to demonstrate that systems will behave as expected.
• Organizations should select assurance-related controls to define system development activities, generate evidence about system functionality and behavior, and trace that evidence to system elements.
  This evidence collection supports obtaining confidence that the system satisfies stated security and privacy requirements.
• During control selection and implementation, organizations must consider what evidence and documentation will be needed for current and future control assessments.
  Evidence supports assessments that determine whether controls are correctly implemented and operating as intended, informing risk-based decisions by senior leaders.

Source: Section 2.5, pages 41-42

• The control catalog provides protective measures designed to facilitate risk management and compliance with federal laws, regulations, and standards.
  The controls serve as a comprehensive set of safeguards for systems, organizations, and individuals to manage security and privacy risks while meeting applicable legal and policy requirements.
• Controls are policy-, technology-, and sector-neutral in focus but require understanding of specific contexts to ensure relevant implementation.
  While controls target fundamental protective measures across the information life cycle regardless of technology, organizations must analyze each control for applicability to their specific technologies, environments, and business functions during implementation.
• Withdrawn controls are retained in the catalog notation for historical purposes rather than being renumbered to maintain stability in security plans.
  Controls may be withdrawn when their function is incorporated into another control, they are redundant, or deemed no longer necessary or effective, but their historical record is preserved.
• New controls are regularly developed based on threat intelligence, adversary tactics, emerging risks, and changes in legal or regulatory requirements.
  The control catalog evolves through systematic revision cycles that balance the need for stability with responsiveness to changing technologies, threats, and requirements to adjust the level of security and privacy protection over time.

Source: Pages 43-44, THE CONTROLS section

• Access control policies must address purpose, scope, roles, responsibilities, management commitment, coordination among entities, and compliance while remaining consistent with applicable laws, regulations, and standards.
  AC-1 requires organizations to develop, document, and disseminate access control policies at organization, mission/business process, or system levels. Policies must be reviewed and updated following defined frequencies and triggering events such as assessment findings, incidents, or changes in laws and regulations.
• Account management requires identifying and documenting allowed and prohibited account types, assigning account managers, and establishing approval processes for account creation with regular compliance reviews.
  AC-2 mandates defining account types (individual, shared, group, system, guest, temporary, emergency, developer, service), requiring prerequisites for group and role membership, and monitoring account usage. Organizations should restrict high-risk account types and disable accounts when no longer needed or when users are terminated.
• Access enforcement mechanisms must implement approved authorization policies at system, application, and service levels to control logical access between subjects (users/processes) and objects (devices, files, records).
  AC-3 establishes that access control policies regulate who accesses what information and enforce these decisions through mechanisms that prevent unauthorized access. Different policy models exist including mandatory access control (MAC), discretionary access control (DAC), role-based access control (RBAC), and attribute-based access control (ABAC).
• Information flow control regulates where information travels within and between systems based on organization-defined policies, independent of who is accessing the information.
  AC-4 addresses controlling information movement through mechanisms like boundary protection devices, packet filtering, and content filtering. Flow control can be enforced using security attributes, protected processing domains, hardware-based one-way flows, and policy filters that block, strip, modify, or quarantine data that violates policies.
• Separation of duties divides mission and business functions, support functions, and security-relevant functions among different individuals or roles to prevent abuse of authorized privileges.
  AC-5 requires identifying and documenting duties requiring separation and defining system access authorizations to support these separations. This applies across multiple systems and domains to prevent individuals from having conflicting security roles such as both administering access control and audit functions.
• Least privilege limits user and process access to the minimum necessary to accomplish assigned organizational tasks, reducing attack surfaces and risk from misuse.
  AC-6 applies least privilege to specific duties, system processes, development, implementation, and operations. Organizations create additional processes, roles, and accounts as needed. Enhancements include restricting privileged accounts to specific personnel, requiring use of non-privileged accounts for non-security functions, and periodic review of assigned privileges.
• Systems must enforce limits on consecutive invalid logon attempts and automatically lock accounts or delay subsequent login prompts when maximum attempts are exceeded.
  AC-7 requires organizations to define the number of failed attempts allowed within a time period and the automatic response (account lock, temporary delay, or administrative notification). Automatic lockouts are typically temporary to prevent denial of service, and alternative authentication factors or CAPTCHA may be required.
• System use notifications must be displayed before access is granted, informing users that they are accessing a government system subject to monitoring, recording, and audit with unauthorized use prohibited.
  AC-8 requires notification banners on logon screens that users must acknowledge before proceeding. For public systems, information about authorized uses and limitations on monitoring should be displayed. Notifications should be in appropriate languages based on user demographics.
• Users must be notified upon successful logon of the date and time of their last successful logon, with optional additional information about unsuccessful attempts or account changes.
  AC-9 supports user awareness of account access by displaying previous logon information. Enhancements allow notification of unsuccessful logon attempts since the last successful logon or changes to account security characteristics, helping users detect unauthorized access.
• Organizations must limit the number of concurrent sessions for each account or account type to prevent misuse and ensure session control.
  AC-10 allows organizations to define maximum concurrent sessions globally, by account type, or by individual account. This addresses system administrators or sensitive domain users but does not restrict a single user from accessing the system through multiple accounts.
• Device lock prevents further system access after a defined period of inactivity or upon user request and must require authentication procedures to restore access.
  AC-11 addresses temporary absence scenarios where users do not want to fully log out. Device locks can be initiated automatically after inactivity or manually by the user. The lock is retained until established identification and authentication procedures reestablish access.
• Sessions must be automatically terminated based on organization-defined conditions such as inactivity periods, incident responses, or time-of-day restrictions.
  AC-12 differs from network disconnection in that it terminates user-initiated logical sessions while potentially maintaining network connections. Organizations can provide logout capabilities and timeout warning messages to enhance usability.
• Organizations must identify and document user actions that can be performed without identification or authentication, such as on public websites, and provide supporting rationale.
  AC-14 allows limited unauthenticated access for public systems and specific scenarios. Any bypass of authentication must be documented in the security plan with justified rationale for why those actions do not require authentication.
• Security and privacy attributes must be associated with information in storage, in process, and in transmission, maintained with integrity, and reviewed for applicability.
  AC-16 establishes that attributes (metadata such as classification, impact level, handling restrictions) enable automated policy enforcement. Attributes can be dynamically associated, changed by authorized individuals, maintained by systems, and must have consistent interpretation across distributed components.
• Remote access must be restricted through documented usage restrictions, configuration requirements, and specific authorization for each remote access type.
  AC-17 requires that organizations authorize remote access types (dial-up, broadband, wireless) with cryptographic protection (VPNs, TLS) for confidentiality and integrity. Remote access should be monitored, privileged commands restricted, and mechanisms available to disconnect access within defined timeframes.
• Wireless access must be configured with documented requirements, connection requirements, and implementation guidance, with each wireless access type authorized prior to use.
  AC-18 addresses wireless technologies including 802.11, Bluetooth, and packet radio. Strong authentication and encryption are required; wireless capabilities should be disabled when not needed; users authorized to configure wireless should be explicitly identified.
• Mobile devices require established configuration and connection requirements with implementation guidance, and each type of mobile device access must be authorized before connection.
  AC-19 defines mobile devices as small, portable, battery-powered computing devices. Organizations must establish restrictions for use outside controlled areas, require device identification and authentication, implement protective software, and may restrict classified information processing on unclassified mobile devices.
• Organizations must establish terms and conditions for use of external systems or prohibit their use entirely, with restrictions varying based on trust relationships with system owners.
  AC-20 addresses systems not owned or controlled by the organization (personally owned devices, contractor systems, other organizations' systems). Organizations must verify implementation of required controls or retain approved agreements; may restrict portable storage use or non-organizationally owned systems.
• Authorized users must be able to determine if sharing partners' access authorizations match information's access restrictions, with automated mechanisms assisting sharing and collaboration decisions.
  AC-21 enables informed information sharing by comparing sharing partner authorizations against information restrictions. Automated mechanisms enforce sharing decisions based on access control policies and information attributes such as confidentiality, data type, or special access requirements.
• Individuals authorized to make information publicly accessible must receive training and perform reviews to ensure nonpublic information is not posted or disclosed.
  AC-22 requires designating authorized personnel, training them on what constitutes nonpublic information, reviewing content before posting and periodically thereafter to detect and remove improper disclosures of protected or proprietary information.
• Organizations must employ data mining prevention and detection techniques for database objects to protect sensitive information and personally identifiable information from unauthorized analytical extraction.
  AC-23 addresses techniques such as limiting query frequency and types, applying differential privacy or homomorphic encryption, and notifying personnel of atypical database queries. Data mining protection focuses on preventing extraction of patterns from stored data that could reveal sensitive correlations.
• Access control decisions must be applied to each access request prior to access enforcement through either established procedures or implemented mechanisms.
  AC-24 distinguishes between making access control decisions (authorization) and enforcing them, which may be performed by different system entities. Authorization information must be securely transmitted if decisions and enforcement are separated, potentially including security and privacy attributes.
• A reference monitor must be implemented for access control policies with properties of being tamperproof, always invoked, and small enough to be completely analyzed and tested.
  AC-25 establishes the reference monitor as a critical operating system component enforcing access control policies over all subjects and objects. The three key properties prevent compromise, bypass, and ensure completeness of verification that the mechanism enforces the security policy correctly.
• Dual authorization (two-person control) may be required for privileged commands and security-relevant actions to reduce insider threat risks, with consideration for operational necessity.
  AC-3(2) enables organizations to require approval of two authorized individuals for sensitive operations. To reduce collusion risk, organizations may rotate dual authorization duties and consider exceptions for public or environmental safety scenarios requiring immediate response.
• Mandatory access control policies must uniformly prevent subjects from passing information to unauthorized recipients, granting privileges to others, or changing security attributes without policy authorization.
  AC-3(3) defines nondiscretionary access control that constrains subject actions based on system-wide policy. Examples include Bell-LaPadula (protecting confidentiality) and Biba (protecting integrity) policies that take precedence over discretionary controls.
• Role-based access control simplifies privilege administration by organizing permissions into defined roles that users inherit when assigned, though roles must align with actual job functions to avoid excessive privileges.
  AC-3(7) enables organizations to define roles based on job functions and assign authorizations to roles rather than individuals. This reduces administrative burden but can increase risk if roles provide unnecessary access beyond mission needs.
• Attribute-based access control restricts system access based on specified organizational, action, environmental, and resource attributes, enabling dynamic and fine-grained access decisions.
  AC-3(13) allows organizations to create rules based on attributes like job function, action types (read/write/delete), time of day, location, and resource classification. Attributes can be dynamically granted and can be implemented with mandatory or discretionary controls.
• Information sharing decisions must be based on verification that receiving parties have appropriate access authorizations and that information restrictions are compatible with their clearances or permissions.
  AC-21 requires matching sharing partner access levels against information protection requirements. Automated tools help users make decisions by comparing authorization levels and information attributes before sharing.
• Protected processing domains use domain and type enforcement to control information flows by assigning system processes to domains, identifying information by types, and allowing only defined accesses between domains.
  AC-4(2) implements protected processing spaces with controlled interactions between domains, enabling separation of information flows. This complements information flow control policies by providing architectural isolation mechanisms.
• Dynamic information flow control allows enforcement of information flow policies based on changing conditions, threat environment changes, or mission-related considerations rather than static rules.
  AC-4(3) enables organizations to adapt flow control policies dynamically in response to operational changes or security incidents. This provides flexibility to modify allowed flows based on real-time risk tolerance and threat assessments.
• Content filtering mechanisms must identify and prevent transfer of unsanctioned information including malicious code, inappropriately releasable content, or executable code that could harm destination systems.
  AC-4(15) requires examination of information for prohibited content prior to cross-domain transfer. Filtering decisions must align with organization-defined security and privacy policies that define what constitutes unsanctioned information.
• Domain authentication uniquely identifies and authenticates source and destination points for information transfers at organization, system, application, service, or individual levels to enable forensic reconstruction.
  AC-4(17) enables attribution of information flows which supports forensic analysis, policy compliance, and personally identifiable information lineage tracking. System labels must distinguish among different organizations, systems, and individuals involved in information processing.
• Privileged user accounts must be established and administered according to either role-based or attribute-based schemes with monitoring of role/attribute assignments and revocation when no longer appropriate.
  AC-2(7) establishes additional scrutiny for privileged roles (key management, system administration, database administration). Organizations must monitor assignments and promptly revoke privileges when security needs change.
• Temporary and emergency accounts are intended for short-term use with organizations establishing temporary accounts through normal procedures and emergency accounts in response to crises with potential approval process bypasses.
  AC-2 discusses that emergency accounts differ from infrequently-used accounts (accounts of last resort) which remain available. Temporary and emergency accounts should be automatically disabled or removed after organization-defined periods.
• Dynamic privilege management allows runtime access control decisions that change user privileges based on factors such as time of day, job function changes, or system emergencies without requiring session termination.
  AC-2(6) enables organizations to adjust user privileges immediately in response to changing circumstances rather than requiring users to log out and back in. This includes immediate privilege revocation and adjustment of encryption keys used for communications.
• Automated account management mechanisms can support creation, modification, disabling, and removal of accounts with notifications to account managers and auditing of all account management actions.
  AC-2(1) and AC-2(4) enable organizations to implement account lifecycle management through automated systems while maintaining audit trails of all account changes.
• Biometric logon attempts must be limited to an organization-defined number to account for probabilistic nature of biometrics and factors like matching performance and presentation attack detection.
  AC-7(3) recognizes that biometric authentication is probabilistic and may fail legitimately. Organizations must select appropriate attempt limits considering matching performance factors specific to their environment.
• Alternate authentication factors may be allowed after primary authentication failures to improve availability while maintaining security through enforcement of limits on alternate factor attempts.
  AC-7(4) enables users inadvertently locked out by failed primary authentication attempts to use alternative factors to regain access, supporting the availability objective.
• Account monitoring for atypical usage must assess and document privacy risks since data collected to identify unusual behavior may reveal previously unknown information about individuals.
  AC-2(12) requires organizations to evaluate privacy impacts of account monitoring and align monitoring practices with privacy program plans and impact assessments.
• High-risk individuals requiring account disablement must trigger close coordination among system administrators, legal staff, human resource managers, and authorizing officials.
  AC-2(13) applies to individuals for whom evidence indicates intention to cause harm or through whom adversaries would cause harm. Account disablement should occur within organization-defined timeframes of risk discovery.
• Inactivity logout requires users to take physical action to log out when expecting inactivity longer than defined periods, differing from automatic enforcement addressed by AC-11.
  AC-2(5) distinguishes behavior-based inactivity logout requiring user action from automatic device lock. Organizations must define expected inactivity periods and communicate logout expectations to users.
• Dynamic account creation and activation relies on trust relationships and business rules established with authorities to validate related authorizations and privileges at runtime for previously unknown entities.
  AC-2(8) supports scenarios where accounts must be created dynamically for entities not known in advance, requiring pre-established mechanisms to validate authorization and establish appropriate privilege levels.
• Shared and group account usage must meet organization-defined conditions recognizing the increased risk due to lack of accountability compared to individual accounts.
  AC-2(9) allows organizations to prohibit shared/group accounts or restrict them to specific circumstances with additional compensating controls to address accountability concerns.
• Usage conditions enforcement helps enforce least privilege, increase user accountability, and enable monitoring by restricting account usage to specific days, times, durations, or locations.
  AC-2(11) allows organizations to specify when and how accounts can be used, with violations triggering alerts. This enables detection of suspicious account usage patterns.
• Controlled release of information to external systems requires verification that receiving systems provide adequate controls and validation of information appropriateness before transfer.
  AC-3(9) ensures information protection extends beyond system boundaries. External assessments or agreements may verify control adequacy when organizations cannot directly assess external system protections.
• Audited override of access control mechanisms allows emergency access under defined conditions by specific roles with all override actions recorded in audit logs.
  AC-3(10) provides capability for emergency access when threats to life or mission-critical functions require immediate override, with comprehensive auditing enabling subsequent review and compliance verification.
• Restricting access to specific information types provides flexibility to control access to particular data within larger repositories rather than requiring all-or-nothing database access.
  AC-3(11) enables role-based access to specific information types (personally identifiable information subsets, cryptographic keys, authentication data) within databases, improving granularity of access control.
• Applications must assert required system access during installation with enforcement mechanisms preventing unauthorized access and approvals required for post-installation access changes.
  AC-3(12) addresses application permissions to access system features (contacts, GPS, cameras, networks). Organizations must establish approval processes for requested application permissions before installation.
• Access authorization information must be transmitted securely using cryptographic mechanisms between systems making authorization decisions and systems enforcing access control decisions.
  AC-24(1) applies when authorization and enforcement are implemented by different system entities. Secure transmission prevents alteration, spoofing, or compromise of authorization information in transit.
• Access control decisions can be made without user or process identity information to preserve privacy using only security or privacy attributes, enabling anonymous access scenarios.
  AC-24(2) addresses situations where user identity is unnecessary for access decisions or where privacy is paramount. MAC, RBAC, ABAC, and label-based policies may not require user identity as an attribute.
• Metadata validation must be applied when transferring information between security domains to ensure metadata integrity and appropriate binding to data payloads before accepting transferred information.
  AC-4(19) recognizes that metadata describing information characteristics must be protected alongside data to ensure policy enforcement remains valid. Organizations must distinguish between metadata and data payloads based on their security model.
• Data type identifiers beyond filenames must be used when transferring between security domains to validate information based on file signatures, tokens, and content validation against specifications.
  AC-4(12) prevents evasion through filename spoofing by validating data type through multiple mechanisms including internal file signatures and content validation against type specifications.
• Information decomposition breaks transfers into policy-relevant subcomponents for submission to filter and enforcement mechanisms, facilitating decisions on source, destination, classification, and attachments.
  AC-4(13) enables more granular policy enforcement by separating information into components that can be individually evaluated and filtered based on their security or privacy characteristics.
• One-way information flows implemented through hardware mechanisms prevent data export from higher-impact or classified domains while permitting import from lower-impact unclassified domains.
  AC-4(7) provides architectural solutions for one-directional flow control using data diodes or unidirectional security gateways, ensuring technical assurance of flow directionality.
• Content filtering solutions must provide redundant and independent filtering mechanisms to eliminate single points of failure, with independence defined as different code bases and vendor implementations.
  AC-4(27) addresses resilience by requiring multiple filtering implementations for the same data type using different vendors' libraries and implementations to prevent a single filter failure from compromising security.
• Linear content filter pipelines with discretionary and mandatory access controls ensure filter processes are non-bypassable and always invoked for all data transfers.
  AC-4(28) prevents bypass vulnerabilities through architectural design ensuring sequential filtering with enforcement mechanisms preventing alternate paths around the pipeline.
• Encryption techniques including differential privacy and homomorphic encryption can be applied to protect information from data mining while maintaining analytical capability.
  AC-23 discussion addresses privacy-preserving techniques that enable authorized analysis while preventing unauthorized data mining that could extract sensitive correlations.
• Information flow control policies and filters must handle both structured data (with defined data structures enabling rule-based inspection) and unstructured data (bitmap objects, text, video, audio).
  AC-4(8) discusses that security policy filters addressing data content must handle both structured formats with definable rules and unstructured formats requiring different filtering approaches.
• Processing requirements between filter pipelines must include minimal complexity and functionality with validation of filtering metadata and assurance content has successfully completed filtering before transfer.
  AC-4(32) ensures processes transferring between filters do not re-filter content, validate metadata integrity, confirm content has passed all required filters, and transfer content to destination pipelines.
• Data sanitization minimizes delivery of malicious content, command and control exploitation, malicious code augmentation, steganography, and spillage of sensitive information according to defined policy.
  AC-4(25) applies sanitization through removal, destruction, redaction, masking, permutation, or alteration of non-releasable information when transferring between security domains.
• Content filtering actions and results must be recorded and audited to track individual messages, ensure correct filter actions, and troubleshoot filtering failures or policy violations.
  AC-4(26) enables review of filtering decisions supporting compliance verification, troubleshooting of legitimate content rejections, and detection of filter circumvention attempts.
• Filter orchestration engines coordinate sequencing of content filtering activities to ensure mechanisms complete execution without errors and actions occur in correct order per policy.
  AC-4(29) implements oversight of filter execution ensuring filters process data in correct sequence and complete successfully, with filters reporting completion status and compliance with policies.
• Embedded data types within other data types must be limited considering embedding levels and filtering tool capabilities to maintain flow control effectiveness.
  AC-4(5) prevents evasion where files embedded within other files or multi-level compression/archiving reduces filtering effectiveness.
• Security policy filters must be enabled, disabled, and configured by privileged administrators to accommodate approved data types and support different policy requirements.
  AC-4(10) and AC-4(11) enable administrators to customize filters for specific data flows based on type, source, destination, and security domain requirements while maintaining policy compliance.
• Failed content that does not pass filtering checks must not be transferred to receiving domains as transfer would corrupt systems and violate information flow policies.
  AC-4(31) prevents transfer of compromised or policy-violating information that failed filtering checks, maintaining integrity of receiving system.
• Multiple filtering processes reduce single points of failure and increase resilience of content filtering mechanisms against bypass or failure.
  AC-4(30) implements defense-in-depth through multiple independent processes implementing filtering to improve overall system reliability.
• Information flow control policies must apply to control plane traffic such as routing and domain name service communications in addition to user data flows.
  AC-4 discussion clarifies that information flow enforcement extends to network control information that could affect system behavior and policy enforcement.
• Privileged accounts must be restricted to specific personnel or roles to prevent day-to-day users from accessing privileged information or performing privileged functions.
  AC-6(5) limits privileged accounts such as system administrator to designated individuals, though organizations may differentiate between local and domain account privileges.
• Non-organizational users including contractors, guest researchers, and detailed personnel must be prohibited from privileged system access, with policies defining equivalent employee status.
  AC-6(6) prevents external parties from obtaining privileged access; organizational policies define criteria for granting equivalent status to non-employees before allowing any privileged access.
• Privileged function usage must be logged and analyzed to detect misuse by authorized users or unauthorized users with compromised accounts, supporting insider threat and advanced persistent threat detection.
  AC-6(9) enables post-incident analysis and real-time detection of suspicious privileged operations. Audit logs must capture execution details enabling investigation of privilege misuse.
• Software must not execute at privilege levels higher than assigned to the user executing the software, preventing elevation of privilege through application functionality.
  AC-6(8) prevents applications from granting users unintended elevated privileges through their execution. Organizations must verify software does not request or require privileges exceeding user assignments.
• Non-privileged users must be prevented from executing privileged functions including circumventing security controls, disabling protections, or administering cryptographic keys.
  AC-6(10) enforces separation between privileged and non-privileged operations through access control mechanisms (AC-3), preventing privilege escalation through privileged function execution.
• Network access to privileged commands must be restricted to documented compelling operational needs, with rationale documented in the security plan.
  AC-6(3) distinguishes between local and remote access to privileged commands, recognizing additional risks from network access and requiring documented justification for network-based privileged command access.
• Separate processing domains enable finer-grained privilege allocation through virtualization, physical separation, or domain separation mechanisms preventing privilege mixing across domains.
  AC-6(4) allows organizations to restrict elevated privileges within virtual machines or physical domains while limiting privileges on shared resources.
• Periodic review of user privileges must validate continued need for assigned privileges and reassign or remove privileges no longer justified by organizational mission and business needs.
  AC-6(7) ensures privilege creep does not occur; organizations must establish review frequency and processes for removing unnecessary or obsolete privileges.
• Authorized access to privileged functions and security-relevant information must be granted only to designated individuals or roles responsible for security functions.
  AC-6(1) restricts access to security administration functions like account creation, access configuration, and audit parameter definition to qualified security personnel.
• Non-privileged accounts must be used when privileged users access non-security functions to limit exposure from privilege misuse during routine work.
  AC-6(2) reduces insider threat risk by requiring security administrators to use standard user accounts for non-security work, limiting potential privilege abuse scope.
• Inactivity logout triggered at defined periods must be enforced through behavior-based policies where users take physical action to log out rather than automatic enforcement.
  AC-2(5) recognizes user-initiated logout differs from automatic device lock (AC-11), requiring users to make conscious decision to log out when expecting extended absence.
• Previous logon notification must provide date and time of last successful logon to help users detect unauthorized access indicating account compromise.
  AC-9 supports user-based security monitoring by enabling users to recognize logon activity inconsistent with their actual access patterns.
• Notification of unsuccessful logon attempts since last successful logon helps users identify if account compromise or brute-force attacks are occurring.
  AC-9(1) provides information supporting user awareness of potential unauthorized access attempts or account compromise.
• Notification of successful and unsuccessful logons during specified time periods enables users to identify unusual access patterns affecting their accounts.
  AC-9(2) extends monitoring timeframe to show accumulated access activity, supporting user awareness of potential compromises or unusual access patterns.
• Account change notifications must alert users to security-related characteristic modifications such as permission changes or role assignments made without authorization.
  AC-9(3) enables users to detect unauthorized account modifications that could indicate compromise or privilege escalation attempts.
• Additional logon information such as logon location derived from IP address enables users to verify logon activity matches their actual access location.
  AC-9(4) provides data enabling users to assess logon legitimacy; unauthorized logon locations indicate account compromise or credential theft.
• System use notification must remain displayed and require explicit user acknowledgment before system access is granted, constituting informed consent to monitoring.
  AC-8 establishes that users must acknowledge notification terms before proceeding, establishing legal consent to monitoring and recording.
• Mobile device security requires configuration management, mandatory protective software, malicious code scanning, software updates, and operating system integrity checks.
  AC-19 discussion outlines comprehensive mobile device security requirements beyond access control addressing device-specific threats.
• Mobile device restrictions outside controlled areas must address protection of device when not in organizational facilities, requiring user responsibility for device security.
  AC-19 recognizes that portable devices require user-based protection outside organizational physical security perimeters.
• Unclassified mobile devices must be prohibited in facilities containing classified systems unless specifically authorized with restrictions on connections and wireless interfaces.
  AC-19(4) prevents classified information compromise through unclassified device connections or wireless data exfiltration.
• Classified mobile devices require security policy restrictions on connections to classified systems to prevent unauthorized information disclosure.
  AC-19(4)(c) ensures even classified devices are subject to organization-defined restrictions on classified system access.
• Full-device or container-based encryption protects mobile device information confidentiality and integrity, with container-based encryption providing fine-grained control over specific data structures.
  AC-19(5) enables encryption of all device content or selective encryption of specific files, records, or data structures based on sensitivity requirements.
• Mobile device purging or wiping must occur after organization-defined consecutive unsuccessful logon attempts based on organization-defined thresholds and techniques.
  AC-7(2) supports data protection on lost or stolen devices through automatic data destruction if logon security is compromised.
• External system usage terms and conditions must address specific application types accessible from external systems and highest security category of information processable on external systems.
  AC-20 requires explicit definition of what organizational information can be accessed or processed from external systems based on trust assessments.
• Trust relationships with other organizations may reduce need for explicit terms and conditions when pre-existing information exchange agreements or statutory requirements establish permitted usage.
  AC-20 acknowledges that some inter-organizational relationships through agreements or law may not require additional AC-20 terms and conditions.
• Authorized individuals using external systems must be those over which organizations have authority to impose specific rules of behavior regarding access restrictions.
  AC-20 limits restrictions to individuals subject to organizational authority; external parties may not be subject to same restrictions.
• Restrictions on external system use may vary among authorized individuals based on different trust relationships requiring differentiated security restrictions.
  AC-20 allows organizations to impose different restrictions on contractors versus government entities based on assessed trust and relationship characteristics.
• Verification of external system control implementation must occur through external independent assessments, attestations, or other processes depending on required confidence levels.
  AC-20(1) enables organizations to verify external system controls before authorizing system access or information processing through various assessment methods.
• Approved system connection or processing agreements with external system hosting organizations constitute alternative to independent verification of control implementation.
  AC-20(1) allows organizations to rely on formal agreements specifying required controls rather than conducting independent assessments.
• Organization-controlled portable storage devices must have usage restrictions when used on external systems limiting how devices may be used and under what conditions.
  AC-20(2) prevents uncontrolled data movement to external systems through portable storage by establishing specific use limitations.
• Non-organizationally owned systems or components may be restricted or prohibited for processing organizational information based on organization-defined risk assessment.
  AC-20(3) recognizes that personally owned or other-organization-owned devices present higher risks than organization-controlled systems, warranting restricted use or prohibition.
• Network-accessible storage devices in external systems (online cloud storage) may be prohibited to prevent organizational information from residing on external storage infrastructure.
  AC-20(4) addresses cloud storage risks where data persistence beyond organizational control increases information exposure risks.
• Organization-controlled portable storage device use on external systems may be completely prohibited to prevent information exfiltration through removable media.
  AC-20(5) allows organizations to enforce complete prohibition of portable storage on external systems through technical or procedural enforcement.
• Access control policies include definition of permitted access attribute ranges and values to ensure meaningful and relevant attribute assignments.
  AC-16 requires organizations to define permitted security and privacy attribute values and ranges preventing nonsensical or inappropriate attribute assignments.
• Security and privacy attributes must be audited when changed to maintain integrity of attribute associations and enable detection of unauthorized modifications.
  AC-16(e) establishes audit requirements supporting review of attribute change compliance with access control policies.
• Security and privacy attributes must be reviewed for applicability at organization-defined frequencies to ensure attributes remain relevant to organizational security and privacy policies.
  AC-16(f) requires periodic review preventing obsolete attribute definitions from remaining in systems.
• Attribute binding strength and assurance affect the trustworthiness of information flow enforcement relying on attributes for policy enforcement decisions.
  AC-16 discussion establishes that binding techniques affect trust in enforcement processes and may require additional organizational reviews based on binding assurance levels.
• Dynamic attribute association changes attribute values as information characteristics change due to aggregation, authorization changes, classification changes, or situational factors.
  AC-16(1) enables attributes to reflect changing information sensitivity as data is combined or used in different contexts.
• Authorized individuals or processes must be able to define and change security and privacy attribute values to enable responsive access control reflecting changing needs.
  AC-16(2) empowers designated personnel to update attributes without requiring system changes or administrative overhead.
• System maintenance of attribute associations with integrity must support automated policy actions based on reliable attribute values throughout information lifecycle.
  AC-16(3) ensures attribute-based decisions remain trustworthy through protected attribute associations that cannot be altered without detection.
• Privileged users can assign attributes to system-defined subjects and objects with some systems allowing general users additional attribute assignment capability.
  AC-16(4) establishes varying levels of attribute assignment authority based on system design and organizational policy.
• Attribute displays on system output must show full unmasked attribute values in human-readable form using standard naming conventions identifying special dissemination or handling instructions.
  AC-16(5) ensures users can understand attribute significance on outputs; standards enable consistent interpretation across organization.
• Personnel must maintain associations of security and privacy attributes with subjects and objects in accordance with policies when systems do not automatically maintain associations.
  AC-16(6) addresses manual attribute maintenance in systems lacking automated association mechanisms.
• Distributed system components must implement consistent interpretation of security and privacy attributes to enable effective enforcement across multiple systems.
  AC-16(7) requires agreements and processes ensuring attributes have same meaning and effect across system boundaries.
• Cryptographic techniques including digital signatures with hardware-protected keys can bind attributes to information, providing high-assurance attribute integrity.
  AC-16(8) discusses association techniques providing different assurance levels, with cryptographic binding offering strongest assurance.
• Regrading mechanisms enabling security and privacy attribute changes must be validated using organization-defined techniques or procedures to ensure trustworthiness.
  AC-16(9) ensures only authorized trusted processes can change attributes, preventing unauthorized elevation or degradation of information protection.
• Authorized individuals must have capability to define or change types and values of security and privacy attributes available for association with system subjects and objects.
  AC-16(10) allows security administrators to create and modify attribute taxonomies supporting organizational policy requirements.
• Remote access configuration and implementation guidance must document security requirements, connection methods, and usage restrictions for each remote access type.
  AC-17 requires organizations to establish baseline security requirements for dial-up, broadband, and wireless remote connections before authorizing use.
• Encrypted virtual private networks with cryptographic mechanisms implemented per applicable standards provide sufficient assurance to treat remote connections as internal networks.
  AC-17 discusses VPN encryption enabling organizations to extend internal network security to remote users while acknowledging VPN traversal of external networks.
• Automated monitoring mechanisms for remote access enable detection of attacks and compliance verification of remote user connection activities.
  AC-17(1) provides visibility into remote access activities supporting security monitoring and policy compliance enforcement.
• Cryptographic mechanisms protecting remote access session confidentiality and integrity include transport layer security and similar protocols for internet communications.
  AC-17(2) establishes encryption as baseline security requirement for remote connections protecting data in transit.
• Remote accesses must be routed through authorized and managed network access control points to limit attack surfaces consistent with Trusted Internet Connections requirements.
  AC-17(3) concentrates remote access through monitored chokepoints preventing direct internet connections to organizational systems.
• Privileged commands and security-relevant information access via remote connection must be restricted to documented compelling operational needs with evidence of appropriate authorization.
  AC-17(4) recognizes greater risk from remote privileged access and requires additional justification and documentation of necessity.
• Organizations must be able to disconnect or disable remote access within organization-defined timeframes varying based on mission criticality and urgency.
  AC-17(9) ensures rapid disconnection capability supporting incident response and threat mitigation.
• Remote commands must be authenticated to prevent unauthorized command execution and command replay attacks against critical systems where failure could cause serious harm.
  AC-17(10) applies to systems where unauthorized commands could cause immediate consequences, requiring authentication mechanisms preventing command spoofing.
• Mechanism information about remote access methods must be protected from unauthorized use and disclosure to external parties.
  AC-17(6) prevents information about remote access methods from enabling adversary attacks against remote access infrastructure.
• Wireless technologies including 802.11 and Bluetooth require strong authentication and encryption to address vulnerability to eavesdropping and man-in-the-middle attacks.
  AC-18 recognizes wireless authentication and encryption as baseline requirements addressing fundamental wireless security weaknesses.
• Wireless device authentication must be implemented alongside user authentication to prevent unauthorized devices from accessing organizational networks.
  AC-18(1) requires dual authentication layers addressing both user identity and device legitimacy for wireless connections.
• Embedded wireless networking capabilities must be disabled when not essential to organizational missions to reduce wireless attack surface.
  AC-18(3) removes unnecessary wireless vulnerability from systems where wireless functionality is not required.
• Users authorized to independently configure wireless networking must be explicitly identified with enforcement through access control mechanisms limiting configuration capability.
  AC-18(4) prevents unauthorized users from modifying wireless security settings that could compromise network integrity.
• Radio antennas and transmission power levels must be calibrated to prevent wireless signals from extending beyond organization-controlled boundaries.
  AC-18(5) implements boundary control for wireless transmissions through antenna selection and power reduction to limit unintended reception.
• Wireless transmission power calibration may include emissions security measures and beamforming antennas directing signals away from external receivers.
  AC-18(5) discusses technical measures reducing wireless signal capture outside organizational boundaries.
• Concurrent session control must address both global session limits and account-type or account-specific limits accommodating different sensitivity levels.
  AC-10 allows organizations flexibility in applying different concurrent session limits based on account classification.
• Device lock prevents logical access through temporary visual concealment with screen savers, patterns, or blank screens preventing shoulder-surfing information disclosure.
  AC-11(1) addresses information disclosure risk from observers viewing device displays during user absence.
• Session termination differs from network disconnection in that logical sessions may end while network connections persist for background processes.
  AC-12 discussion clarifies distinction between user session termination and underlying communication session termination (SC-10).
• Session termination trigger events may include organization-defined inactivity periods, specific incident responses, or time-of-day restrictions limiting system access.
  AC-12 allows organizations to define multiple session termination conditions accommodating different operational requirements.
• User-initiated logout capabilities must be provided for authenticated information resources including local workstations, databases, and web services.
  AC-12(1) requires accessible logoff mechanisms enabling users to explicitly terminate their sessions.
• Explicit logout messages indicating session termination provide user confirmation that authentication session has ended and access is no longer available.
  AC-12(2) supports user awareness of session status preventing assumptions of continued access after logout.
• Timeout warning messages must notify users of impending session termination allowing users to continue sessions before automatic termination occurs.
  AC-12(3) improves usability by preventing unexpected session termination through advance warning.
• Permitted actions without identification or authentication must be identified, documented, and justified in security plans based on organizational mission and business functions.
  AC-14 requires organizations to explicitly define unauthenticated access with documented rationale supporting each permitted action.
• Bypasses of identification and authentication must be documented in security plans when physical switches or other mechanisms allow authentication bypass.
  AC-14 establishes accountability for any circumvention of normal authentication requirements through documented authorization.
• Organizations may determine no user actions can be performed without authentication, establishing zero unauthenticated access policy.
  AC-14 allows organizations to select 'none' as the assignment value prohibiting all unauthenticated access.
• Marking associates security and privacy attributes with information in human-readable form on system media enabling manual, procedural, or process-based policy enforcement.
  AC-16 discussion distinguishes between labeling (internal system association) and marking (external human-readable association) of security attributes.
• Classification of information per legal and compliance requirements represents a fundamental security attribute addressing regulatory compliance and need-to-know determination.
  AC-16 examples include classification levels (top secret, secret, confidential, controlled unclassified) as defined by legal and regulatory frameworks.
• Information impact level attributes must be assigned based on impact assessment reflecting potential harm from disclosure, loss, or modification.
  AC-16 applies impact-level attributes supporting risk-based access control decisions.
• High value asset information attributes identify critical organizational resources warranting additional protection and access restrictions.
  AC-16 allows organizations to flag particularly important information for enhanced access controls.
• Access authorization attributes must specify which subjects can access which objects with what privileges, enabling attribute-based authorization decisions.
  AC-16 applies authorization attributes as basis for AC-3 enforcement.
• Nationality attributes on information or individuals may restrict information access based on foreign national status or export control requirements.
  AC-16 addresses legal constraints on information access based on authorized recipient nationality.
• Data life cycle protection attributes including encryption requirements and data expiration dates enforce information retention and protection policies.
  AC-16 enables time-based information destruction through expiration attributes and requires encryption during specified protection periods.
• Personally identifiable information processing permission attributes must indicate authorized processing purposes and any individual consent requirements.
  AC-16 applies privacy-specific attributes tracking consent to specific processing activities.
• Contractor affiliation attributes may restrict information access based on contractor relationship or security clearance status.
  AC-16 allows organizations to control information access based on contractor authorization levels.
• Access control policies and procedures must reflect organization-specific risk management strategy considerations when establishing frameworks and guidance.
  AC-1 establishes that access control policies are security and privacy program foundations reflecting organizational risk tolerance and management commitments.
• Security and privacy programs should collaborate on policy development to ensure access control policies address both security and privacy controls.
  AC-1 discussion emphasizes integrated security-privacy approach to access control rather than separate security-only policies.
• Organization-level access control policies are generally preferable and may obviate mission-specific or system-specific policies reducing policy fragmentation.
  AC-1 encourages centralized policy frameworks providing consistent guidance across organizational systems unless mission requirements justify additional specialized policies.
• Access control policies may be included as part of general security and privacy policies or represented by multiple specialized policies reflecting organizational complexity.
  AC-1 allows policy structure flexibility accommodating diverse organizational structures and requirements.
• Procedures implementing access control policies must be documented at appropriate levels (security/privacy program, mission/business process, or system level) as needed.
  AC-1 establishes that procedures should be created at levels where they provide most effective implementation guidance.
• Procedures must describe implementation details directed at individuals or roles subject to procedures rather than simply restating control requirements.
  AC-1 emphasizes that documentation must provide actionable implementation guidance rather than theoretical policy statements.
• Events triggering access control policy and procedure updates include assessment findings, security incidents, breaches, and changes in applicable laws and regulations.
  AC-1 establishes review triggers ensuring policies reflect current threat environment and regulatory landscape.
• Assignment of a policy manager responsible for development, documentation, and dissemination of access control policies establishes accountability for policy governance.
  AC-1 requires organizations to designate an official accountable for policy management and updates.
• Frequency of policy and procedure review must be organization-defined balancing need for currency with administrative burden of frequent updates.
  AC-1 requires organizations to establish review schedule reflecting their operational environment and change velocity.
• Account managers must be assigned responsibility for specific account management functions and held accountable for account lifecycle management.
  AC-2 establishes that organizations must explicitly assign account management responsibilities rather than assuming implicit assignment.
• Shared and group account authenticators must be changed when individuals are removed from groups to prevent former members from retaining access.
  AC-2(k) addresses security weakness of group accounts where former members could retain access if authenticators are not changed.
• Account management processes must be aligned with personnel termination and transfer processes to ensure timely account disablement when employment status changes.
  AC-2(l) integrates account management with human resource processes ensuring no gap between employment termination and account disablement.
• Group and role membership requirements may include prerequisites like security clearances, background checks, or position-specific qualifications.
  AC-2 recognizes that group membership involves conditions beyond simple authorization, potentially requiring multiple prerequisites.
• Account authorization may be based on intended system usage, distinguishing between different user types with different authorization levels.
  AC-2(i) establishes that authorization decisions consider how individuals intend to use systems in addition to role-based factors.
• Additional attributes beyond privileges may be required for authorization such as restrictions on access time, day, or point of origin limiting when and where access occurs.
  AC-2 enables time-based and location-based access restrictions through additional attribute-based authorization.
• Administrative users requiring privileged account access must receive additional scrutiny from system owner, mission owner, and senior information security officials.
  AC-2 discussion emphasizes elevated approval requirements for privileged account creation reflecting higher risk of privilege misuse.
• High-risk account types including shared, group, emergency, anonymous, temporary, and guest accounts should be prohibited unless specific operational need justifies their use.
  AC-2 discussion identifies account types presenting elevated risk warranting organizational prohibition or strict limitation.
• Individual accounts provide accountability through one-to-one user-to-account mapping enabling audit trail attribution to specific individuals.
  AC-2 establishes individual accounts as preferred type addressing accountability requirements.
• Shared accounts prevent attribution of actions to specific individuals, increasing security risk through reduced accountability and making incident investigation difficult.
  AC-2 discusses accountability gap created by shared accounts explaining why they should be restricted or prohibited.
• System accounts typically operate without direct human user association, requiring different management approaches than user accounts.
  AC-2 establishes that system, service, and developer accounts have different characteristics and management requirements than standard user accounts.
• Guest accounts provide temporary access to non-organizational users warranting restrictions on data access and duration.
  AC-2 addresses guest account use cases requiring temporary access for non-employees.
• Anonymous accounts prevent user attribution and should be prohibited except for specific use cases like public-facing systems.
  AC-2 discussion identifies anonymous accounts as high-risk type to be avoided except when required for public access.
• Developer accounts used for system development and testing may require elevated privileges warranting separate management from production accounts.
  AC-2 establishes that development and production accounts should be segregated to prevent test privileges from affecting production systems.
• Account expiration dates or other disabling factors should be defined in policies to automatically disable accounts that have served their purpose.
  AC-2 enables automatic account lifecycle management through time-based disablement rather than administrative action.
• Organizations may define access privileges by account type grouping users with similar roles receiving same privilege set rather than individual customization.
  AC-2 enables efficiency through privilege definition at account type level rather than per-individual granularity.
• Emergency account activation may bypass normal authorization processes to enable rapid response to crisis situations requiring immediate system access.
  AC-2 acknowledges that emergency procedures may differ from normal processes recognizing immediate action requirements.
• Accounts of last resort used for special tasks or network unavailability scenarios should not be subject to automatic disabling unlike temporary and emergency accounts.
  AC-2 distinguishes between temporary/emergency accounts intended for discrete events and accounts of last resort remaining available for contingencies.
• Failure to consider system availability impacts when defining access restrictions or account limitations could degrade system reliability or user productivity.
  AC-2 discussion establishes that access control decisions must balance security with operational availability requirements.
• Infrequently used accounts including local logon accounts for special purposes may remain available contrary to automatic disabling of temporary accounts.
  AC-2 differentiates between intended temporary accounts and infrequently-used production accounts that should remain continuously available.
• Some account types may require specialized training for designated users to ensure proper account usage and prevent misuse.
  AC-2 establishes that training requirements may vary by account type and user role.

Source: Section 3.1 ACCESS CONTROL, pages 45-85

• Organizations must develop and disseminate awareness and training policy and procedures that address purpose, scope, roles, responsibilities, management commitment, coordination, and compliance, consistent with applicable laws and regulations.
  AT-1 requires policies and procedures at organization, mission/business process, or system levels. A designated official must manage their development and dissemination. Security and privacy programs should collaborate on these policies, which should be reviewed and updated at defined frequencies and following triggering events such as audit findings or security incidents.
• Security and privacy literacy training must be provided to all system users including managers, executives, and contractors as initial training and at defined frequencies thereafter, with content updated regularly and lessons learned from incidents incorporated.
  AT-2 requires organizations to determine training content based on organizational requirements, system access, and work environments. Training covers the need for security and privacy, user actions to maintain security and handle personally identifiable information, and operations security. Awareness techniques include posters, email advisories, logon messages, and awareness events.
• Role-based security and privacy training tailored to specific job functions must be provided before personnel access systems or information, and updated regularly to remain relevant and effective.
  AT-3 requires training for roles such as system owners, authorizing officials, security officers, developers, administrators, auditors, and personnel with privacy or contingency planning responsibilities. Training covers management, operational, and technical controls as well as policies, procedures, tools, and methods relevant to assigned roles. Types include web-based, classroom, and hands-on training.
• Organizations must document and monitor all security and privacy training activities and retain individual training records for a specified time period.
  AT-4 establishes that training documentation supports verification that personnel have completed required training. Specialized training records may be maintained by individual supervisors at organizational discretion, and federal agencies follow National Archives and Records Administration guidance on retention periods.
• Training feedback on awareness and role-based training results must be provided to defined personnel at specified frequencies to enable management awareness of training failures in critical roles.
  AT-6 recognizes that training failures, particularly among personnel in critical roles, may indicate serious problems requiring management response. Feedback supports the evaluation and update of organizational training programs.
• Literacy training should include practical exercises simulating security incidents such as social engineering attempts, phishing attacks, and malicious email scenarios to reinforce learning.
  AT-2(1) enhances training effectiveness by incorporating realistic simulations including no-notice social engineering attempts, unauthorized access collection, and malicious email attachment or spear phishing scenarios.
• Personnel must receive training on recognizing and reporting potential insider threat indicators such as job dissatisfaction, unauthorized access attempts, and policy violations.
  AT-2(2) requires organizations to educate employees and managers on behaviors that may indicate insider threat risk, with tailored training by role. Managers focus on team member behavior changes while employees focus on general observations. Training includes communication channels for reporting concerns.
• Training must address recognition and reporting of social engineering tactics including phishing, pretexting, impersonation, baiting, and social media exploitation, as well as social mining attempts.
  AT-2(3) emphasizes that social engineering is an attempt to trick individuals into revealing information or taking actions that compromise systems. Training includes communication of concerns through established organizational channels.
• Literacy training must teach personnel to recognize suspicious communications and anomalous system behavior using organization-defined indicators of malicious code.
  AT-2(4) recognizes that a well-trained workforce provides defense-in-depth protection against malicious code. Personnel are trained to identify suspicious emails, strange grammar, unfamiliar senders, and anomalous system behaviors that may indicate malicious code presence.
• Training on advanced persistent threat tactics must educate personnel on infiltration methods including websites, emails, advertisement pop-ups, social engineering, and targeting techniques used outside the workplace.
  AT-2(5) recognizes APTs as a significant threat and requires specific literacy training for individuals on various infiltration vectors, suspicious email recognition, secure use of removable systems, and protection against personal targeting.
• Dynamic threat literacy training must be provided on the current cyber threat environment and reflected in system operations to ensure organizational awareness of evolving threats.
  AT-2(6) requires organizations to maintain current threat information in training and operations since threats change continuously. Threat literacy training must not be isolated from system operations that support organizational missions and business functions.
• Role-based training enhancements for specific personnel must cover environmental controls operation including fire suppression, sprinkler systems, temperature control, and power management within facilities.
  AT-3(1) ensures personnel assigned to relevant roles understand the operation and employment of environmental protection controls necessary for facility security and business continuity.
• Training on physical security controls operation must be provided to designated personnel covering access control devices, intrusion detection alarms, facility guard procedures, and monitoring equipment.
  AT-3(2) ensures personnel understand the operation and employment of physical security controls protecting facilities and information systems.
• Role-based training must include practical exercises such as simulated attacks exploiting software vulnerabilities and phishing attacks targeted at executives, as well as privacy scenarios with quizzes on personally identifiable information handling.
  AT-3(3) reinforces training objectives through hands-on exercises. Developer training simulates vulnerability exploits while privacy training uses modules with scenarios on identifying personally identifiable information and conducting privacy impact assessments.
• Personnel in specific roles must receive training on personally identifiable information processing controls, authority to process such information, and associated risks, considerations, and obligations.
  AT-3(5) addresses the types of information constituting personally identifiable information and requires awareness of processing authority documented in privacy policies, system of records notices, privacy impact assessments, and information sharing agreements.

Source: Section 3.2, pages 86-91

• Audit and accountability policies and procedures must address purpose, scope, roles, responsibilities, management commitment, and coordination among organizational entities.
  These foundational elements establish the framework for audit activities. Policies should be consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines, and should be developed collaboratively between security and privacy programs.
• Organizations must identify event types capable of being logged and select a subset for actual logging based on security and privacy needs.
  Event types include password changes, failed logons, security attribute changes, administrative privilege usage, PIV credential usage, and data action changes. The selection must balance monitoring requirements with system performance considerations and include a rationale for adequacy.
• Audit records must contain what occurred, when, where, source, outcome, and identity of individuals or subjects involved.
  Additional information may be included such as access control rules invoked, flow control rules, and group account user identities. Organizations must consider privacy risks and limit personally identifiable information to only elements identified in privacy risk assessments.
• Audit log storage capacity must be allocated to accommodate defined retention requirements without exceeding capacity.
  Insufficient storage capacity risks loss of audit logging capability. Organizations must consider the types of logging to be performed and processing requirements when allocating storage, and may transfer logs to alternate storage to extend capacity.
• Organizations must alert designated personnel within defined time periods upon audit logging process failures and take additional actions such as overwriting oldest records, shutting down systems, or stopping record generation.
  Failures include software and hardware errors, capturing mechanism failures, and storage capacity exceedances. The response depends on failure type, location, severity, and whether it affects the logging system, storage repository, or total organizational storage capacity.
• Audit records must be reviewed and analyzed at defined frequencies for inappropriate or unusual activity, with findings reported to designated personnel.
  Review and analysis supports security and privacy monitoring including account usage, remote access, wireless connectivity, physical access, and equipment changes. The frequency, scope, and depth may be adjusted based on risk from law enforcement or intelligence information.
• Audit record reduction and report generation capabilities must support on-demand review and after-the-fact incident investigations without altering original content or time ordering of records.
  Reduction organizes collected log information into summary formats more meaningful to analysts. Modern data mining and advanced data filters can identify anomalous behavior, and customizable reports can be generated from various system components.
• Audit records must use internal system clocks with time stamps meeting defined granularity using Coordinated Universal Time with optional fixed local time offset.
  Time stamp granularity refers to synchronization degree between system clocks and reference clocks. Time service is critical to other security capabilities such as access control and identification and authentication.
• Audit information and audit logging tools must be protected from unauthorized access, modification, and deletion, with alerts upon detection of unauthorized changes.
  Audit information includes audit records, log settings, reports, and personally identifiable information. Technical protection limits access to authorized individuals, while physical protection is addressed through media and environmental controls.
• Non-repudiation services must provide irrefutable evidence that an individual or process performed defined actions such as creating, sending, receiving, or approving information.
  Non-repudiation protects against denials of authorship, transmission, receipt, or signature. Services are implemented through techniques including digital signatures and digital message receipts, with binding of identities to information at organization-defined strength levels.
• Audit records must be retained for defined time periods consistent with records retention policy to support incident investigations and meet regulatory and organizational requirements.
  Retention decisions consider administrative, legal, audit, and operational purposes including FOIA requests, subpoenas, and law enforcement actions. The National Archives and Records Administration provides federal records retention policy guidance.
• Systems must provide audit record generation capability for defined event types on specified system components, allowing designated personnel to select which events are logged.
  Generated records must include content defined in AU-3, and event types specified are a subset of all types the system can log. Records can be compiled into system-wide audit trails that are time-correlated within organizational tolerances.
• Organizations must monitor open-source information and websites at defined frequencies for evidence of unauthorized disclosure of organizational information including personally identifiable information and proprietary information.
  If disclosure is discovered, designated personnel must be notified and defined additional actions taken. Automated monitoring mechanisms and regular review of monitored sites help ensure discovery techniques remain relevant and effective.
• Session auditing capability must be provided for defined users or roles to record, view, hear, or log user session content under defined circumstances, developed in consultation with legal counsel.
  Session audits can monitor keystrokes, track websites visited, and record information transfers. Organizations must consider privacy risks, activate capability under well-defined situations, and consult with legal, civil liberties, and privacy officials.
• Cross-organizational audit logging must coordinate audit information when transmitted across organizational boundaries using defined methods.
  Coordination addresses challenges in maintaining individual identity across boundaries while managing performance and privacy impacts. Organizations should include coordination processes and audit information protection in information exchange agreements.
• Audit information management must be designated to an organization-defined official responsible for policy and procedure development, documentation, and dissemination.
  This official oversight ensures consistency and accountability. Policies should generally be at the organization level to prevent need for multiple mission- or system-specific policies, though procedures may be established at multiple levels as needed.

Source: Section 3.3, pages 92-109

• Assessment, authorization, and monitoring policies and procedures must address purpose, scope, roles, responsibilities, management commitment, and compliance while remaining consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines.
  CA-1 requires organizations to develop and disseminate documented policies at organization, mission/business process, or system levels. Policies and procedures contribute to security and privacy assurance, and security and privacy programs should collaborate on their development. Triggers for updates include assessment findings, security incidents, breaches, or changes in applicable laws and regulations.
• Control assessments must be conducted by appropriately skilled assessors or assessment teams to determine whether controls are implemented correctly, operating as intended, and producing desired outcomes against security and privacy requirements.
  CA-2 requires selecting appropriate assessors, developing a control assessment plan with defined scope and procedures, obtaining authorizing official approval, and assessing controls at defined frequencies. Assessment reports document results in sufficient detail, and results are provided to appropriate individuals such as authorizing officials and senior agency officials for privacy.
• Independent assessors conducting control assessments must be free from perceived or actual conflicts of interest regarding development, operation, sustainment, or management of systems under assessment.
  CA-2(1) emphasizes that independence means assessors do not create conflicting interests, assess their own work, act as management of assessed organizations, or advocate for acquiring organizations. When organizational structures prevent independence, independent review teams of experts can validate assessment completeness, accuracy, integrity, and reliability.
• Specialized assessments including in-depth monitoring, security instrumentation, automated test cases, vulnerability scanning, malicious user testing, and insider threat assessment can improve organizational readiness and performance.
  CA-2(2) allows organizations to conduct these assessments at defined frequencies either announced or unannounced. Vulnerabilities uncovered during assessments should be incorporated into vulnerability remediation processes, and specialized assessments can occur early in the system development life cycle.
• Organizations may leverage control assessment results from external organizations when assessments meet organizational requirements, reducing time and resources needed for independent assessment activities.
  CA-2(3) notes that factors in accepting external assessment results include past experience with the assessing organization, reputation, level of detail of supporting evidence, and applicable mandates. Accredited testing laboratories supporting Common Criteria, CMVP, or CAVP can provide independent assessment results organizations can reuse.
• System information exchanges with other systems must be approved and managed using interconnection security agreements, information exchange security agreements, memoranda of understanding, service level agreements, user agreements, nondisclosure agreements, or other organizational agreements.
  CA-3 requires documenting interface characteristics, security and privacy requirements, controls, responsibilities, and information impact level for each exchange. Organizations consider risk from systems with different security and privacy requirements. If systems share the same authorizing official, interface information may be described in security and privacy plans instead.
• Transfer authorizations between systems must be verified to ensure individuals or systems transferring data have requisite authorizations prior to data acceptance.
  CA-3(6) requires independent verification that data transferring individuals or systems are authorized to do so. This applies to both data plane traffic and control plane traffic such as routing and DNS, including authenticated SMTP relays.
• Organizations must identify transitive (downstream) information exchanges and cease such exchanges when controls on identified downstream systems cannot be verified or validated.
  CA-3(7) requires identifying downstream exchanges between systems receiving organizational information and other systems. Transparency of downstream system controls is essential for understanding security and privacy risks, as organizational systems can inherit risk from downstream systems through transitive connections.
• Plans of action and milestones document planned remediation actions to correct control weaknesses, deficiencies, and known vulnerabilities identified during assessments and continuous monitoring.
  CA-5 requires developing and updating plans of action and milestones based on control assessment findings, independent audits or reviews, and continuous monitoring activities. These plans are required in authorization packages and subject to federal reporting requirements established by OMB.
• Automated mechanisms should maintain the accuracy, currency, and availability of plans of action and milestones to facilitate coordination and sharing of security and privacy information across the organization.
  CA-5(1) supports identification of systemic weaknesses or deficiencies in organizational systems and ensures appropriate resources are directed at the most critical vulnerabilities in a timely manner.
• A senior official must be assigned as the authorizing official for each system who accepts common control inheritance and authorizes system operation before commencement of operations.
  CA-6 requires authorizing officials to be federal employees responsible and accountable for security and privacy risks associated with system operation and use. A separate senior official authorizes common controls for inheritance. Authorization is an official management decision accepting risk to organizational operations, assets, individuals, and the Nation.
• Authorizations must be updated at defined frequencies based on evidence from continuous monitoring programs, reducing the need for separate reauthorization processes.
  CA-6 indicates that robust continuous monitoring programs allow authorizing officials, common control providers, and system owners to maintain up-to-date awareness of security and privacy posture. Authorizing officials can leverage continuous monitoring results to the maximum extent possible for reauthorization decisions, reducing costs.
• Joint authorization processes with multiple authorizing officials from the same organization increase independence in risk-based decision-making and implement separation of duties and dual authorization concepts.
  CA-6(1) indicates this approach is most relevant for connected systems, shared systems, and systems with multiple information owners.
• Joint authorization involving multiple authorizing officials from different organizations increases independence in decision-making and is appropriate for connected systems, shared systems, and systems with multiple information owners.
  CA-6(2) indicates external authorizing officials may be necessary when external organizations have vested interests in authorization outcomes.
• Continuous monitoring strategies must establish system-level metrics, monitoring frequencies, assessment frequencies, and procedures for correlation and analysis of control assessment and monitoring results.
  CA-7 requires implementing continuous monitoring at the system level aligned with organization-level strategies. Different control types may require different monitoring frequencies. Results generate risk response actions, and automation supports more frequent updates to hardware, software, firmware inventories, and authorization packages.
• Continuous monitoring enables organizations to maintain authorizations of systems and common controls in dynamic environments with changing mission and business needs, threats, vulnerabilities, and technologies.
  CA-7 notes that access to security and privacy information on a continuing basis through reports and dashboards enables organizational officials to make effective and timely risk management decisions, including ongoing authorization decisions. Continuous monitoring activities are scaled according to security categories of systems.
• Independent assessors or assessment teams should monitor controls on an ongoing basis to provide impartiality and degree of assurance to the continuous monitoring process.
  CA-7(1) requires assessors to not create conflicting interests, assess their own work, act as management of assessed organizations, or advocate for acquiring organizations. Required independence levels are based on organizational continuous monitoring strategies.
• Trend analyses examining threat information, attack success rates, emerging vulnerabilities, configuration settings effectiveness, and assessment results should inform modifications to control implementations and continuous monitoring activities.
  CA-7(3) indicates trend analyses examine recent threats addressing events that occurred in the organization or Federal Government, effectiveness of configuration settings, results from multiple assessments, and findings from Inspectors General or auditors.
• Risk monitoring must include effectiveness monitoring, compliance monitoring, and change monitoring as integral parts of continuous monitoring strategies.
  CA-7(4) indicates risk monitoring is informed by established organizational risk tolerance. Effectiveness monitoring determines ongoing effectiveness of implemented risk response measures, compliance monitoring verifies required measures are implemented and security and privacy requirements are satisfied, and change monitoring identifies changes affecting security and privacy risk.
• Organizations must validate that implemented security and privacy controls operate in a consistent and coordinated manner through testing, monitoring, and analysis to prevent gaps or control interference.
  CA-7(5) notes that controls added incrementally may have inconsistent policies, potentially creating unacceptable gaps or causing some controls to impede others. Failing to consistently monitor all network protocols may create vulnerabilities, so validation is essential.
• Automated mechanisms should maintain the accuracy, currency, and availability of monitoring results to increase ongoing awareness of system security and privacy posture in support of organizational risk management decisions.
  CA-7(6) indicates automated monitoring tools help maintain accurate and current information that supports more effective and timely risk management.
• Penetration testing is a specialized assessment conducted on systems to identify vulnerabilities that could be exploited by adversaries, going beyond automated vulnerability scanning.
  CA-8 requires penetration testing at defined frequencies on defined systems or components. Testing is conducted by teams with demonstrable technical expertise in network, operating system, and application level security. It can validate vulnerabilities and determine penetration resistance within specified constraints of time, resources, and skills.
• Penetration testing includes pretest analysis based on full system knowledge, identification of potential vulnerabilities, and testing to determine exploitability, with all parties agreeing to rules of engagement before commencement.
  CA-8 indicates penetration testing can be conducted internally or externally on hardware, software, or firmware components and can exercise both physical and technical controls. Rules of engagement should be correlated with anticipated adversary tools, techniques, and procedures. Contracts or mechanisms can protect information exposed during testing.
• Independent penetration testing agents or teams must be free from perceived or actual conflicts of interest regarding development, operation, management, or assessment target systems.
  CA-8(1) emphasizes impartiality means testing agents do not create conflicting interests with targeted organizations, assess their own work, act as management, or advocate for acquiring organizations. This aligns with independence requirements in CA-2(1).
• Red team exercises simulate adversary attempts to compromise organizational systems and provide comprehensive assessment of security and privacy posture including technology-based and social engineering attacks.
  CA-8(2) indicates red team exercises extend penetration testing objectives by examining organizational capability to implement effective cyber defenses. Attacks may include hardware, software, firmware interactions and business process interactions as well as email, telephone, shoulder surfing, and personal conversation attacks. Red team exercises are most effective when conducted by teams with current adversarial tactics, techniques, procedures, and tools knowledge.
• Penetration testing of physical access points can identify critical vulnerabilities in system operating environments and correct weaknesses in physical controls.
  CA-8(3) requires facility penetration testing at defined frequencies with announced or unannounced attempts to bypass or circumvent controls at physical access points. Results inform correction of physical control deficiencies.
• Internal connections of system components must be authorized with documented interface characteristics, security and privacy requirements, and information nature, and reviewed periodically for continued need.
  CA-9 addresses connections between organizational systems and separate constituent system components including mobile devices, notebooks, desktops, tablets, printers, scanners, sensors, and servers. Organizations can authorize connection classes with common characteristics instead of individual connections. Connections are terminated after specified conditions.
• Security and privacy compliance checks should be performed on system components prior to establishment of internal connections to verify relevant baseline configuration.
  CA-9(1) ensures constituent system components meet compliance requirements before connection to the system.

Source: Section 3.4, pages 110-122

• Configuration management policy and procedures must be developed, documented, and disseminated to organizational personnel at appropriate levels, with designated officials responsible for managing their development and updates triggered by specific events or frequencies.
  CM-1 requires organizations to establish configuration management governance that addresses purpose, scope, roles, responsibilities, and compliance. Security and privacy programs should collaborate on development, and policies should be reviewed following events such as audit findings, security incidents, or changes in applicable laws and regulations.
• A baseline configuration is a formally reviewed and approved specification of system components that serves as the basis for future builds and includes security controls, operational procedures, network topology, and component information.
  CM-2 requires baseline configurations to be developed, documented, and maintained under configuration control. They must be reviewed and updated at organization-defined frequencies, when circumstances warrant, and when system components are installed or upgraded. Separate baseline configurations should be maintained for development, test, and operational environments.
• Configuration change control involves systematic proposal, justification, implementation, testing, review, and disposition of system changes, with changes documented and approved based on explicit security and privacy impact analyses.
  CM-3 requires organizations to determine types of configuration-controlled changes, review and approve changes with security and privacy considerations, document decisions, implement approved changes, retain records, and monitor change activities. A configuration change control element such as a Change Advisory Board should convene at defined frequencies or when specified conditions occur.
• Prior to implementing changes to a system, organizational personnel must analyze potential security and privacy impacts by reviewing plans, policies, design documentation, and conducting risk assessments.
  CM-4 impact analyses should be conducted by personnel with security or privacy responsibilities who possess necessary skills and technical expertise. Changes should be analyzed in separate test environments before operational implementation, and controls affected by changes must be verified to operate correctly after implementation.
• Physical and logical access restrictions must be defined, documented, approved, and enforced to ensure only qualified and authorized individuals can access systems for making changes.
  CM-5 requires access restrictions to include physical and logical controls, software libraries, workflow automation, and change windows. Automated mechanisms should enforce restrictions and generate audit records. Dual authorization may be required for critical system components, and privileges for production environment changes should be limited and regularly reevaluated.
• Configuration settings must be established and documented to reflect the most restrictive mode consistent with operational requirements using common secure configurations, with deviations approved and monitored.
  CM-6 requires organizations to establish organization-wide configuration settings that become part of the baseline, derive system-specific settings from those standards, and monitor changes. Configuration parameters include registry settings, permissions, service settings, and privacy parameters affecting the security and privacy posture. Common secure configurations such as STIGs and USGCB provide recognized benchmarks.
• Systems must be configured to provide only mission-essential capabilities, with unused functions, ports, protocols, software, and services prohibited or restricted to prevent unauthorized access and reduce risk.
  CM-7 least functionality principle requires disabling unnecessary ports and protocols, removing unused software, and limiting component functionality to single functions where feasible. Organizations should periodically review systems to identify and remove nonsecure functions, prevent execution of unauthorized software using deny-by-exception policies, and restrict installation of unauthorized hardware.
• An inventory of system components must be developed, documented, and maintained at appropriate granularity, including hardware, software, and firmware with information necessary for accountability, without duplicate accounting.
  CM-8 requires inventories to accurately reflect the system using unique identifiers for each component and include system name, software owners, version numbers, hardware specifications, license information, network addresses, and for networked components, machine names and protocols. The inventory must be reviewed and updated at organization-defined frequencies, including during installations and removals.
• A configuration management plan must be developed, documented, and implemented for the system addressing roles, responsibilities, processes, configuration items, and lifecycle activities from development through operations.
  CM-9 plans identify configuration items throughout the development lifecycle, define the configuration management process for each system, and describe how changes advance through change management. Plans should be reviewed and approved by designated personnel and protected from unauthorized disclosure and modification.
• Software usage must comply with contract agreements and copyright laws, with licensed software tracked to control copying and distribution, and peer-to-peer file sharing controlled to prevent unauthorized reproduction of copyrighted work.
  CM-10 requires organizations to use software according to license agreements and laws, track quantity-licensed software use through manual or automated methods, and document peer-to-peer file sharing use. Organizations should establish restrictions on open-source software use, considering licensing issues and security implications.
• Organizations must establish and enforce policies governing user installation of software, permitting updates and approved applications while prohibiting software with unknown pedigrees or suspected malicious intent.
  CM-11 requires policies to define permitted and prohibited software installations and enforcement methods. Software installations should require privileged status, and compliance must be monitored at organization-defined frequencies using automated mechanisms where feasible to detect and respond to unauthorized software installation.
• The location of information and system components where information is processed and stored must be identified, documented, and changes to those locations tracked to enable proper protection and policy management.
  CM-12 requires identification of where specific information types reside and how they flow through system components, including documentation of users with access to those components. Information location is essential for understanding security requirements and architecture design decisions based on information sensitivity.
• A map of system data actions must be developed and documented, identifying discrete data actions, elements of personally identifiable information processed, system components involved, and component owners or operators.
  CM-13 data action mapping encompasses the full information lifecycle including collection, generation, transformation, use, disclosure, retention, and disposal. Maps provide contextual factors important for assessing privacy risk and may be illustrated in different ways depending on organizational needs and mission requirements.
• Installation of software and firmware components must be prevented unless they are digitally signed using a certificate recognized and approved by the organization to ensure code authenticity.
  CM-14 signed component controls apply to version updates, patches, service packs, device drivers, and basic input/output system updates. Organizations identify applicable components by type or specific items and verify digital signatures as a method of code authentication.

Source: Section 3.5, pages 123-141

• Contingency planning policy and procedures must be developed, documented, and disseminated to organization-defined personnel, addressing purpose, scope, roles, responsibilities, management commitment, and coordination among organizational entities.
  CP-1 requires policies to be consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. An organization-defined official must manage the development and dissemination, with regular reviews and updates triggered by assessment findings, incidents, breaches, or changes in regulations.
• A contingency plan must identify essential mission and business functions, provide recovery objectives and restoration priorities, and address maintaining and restoring those functions despite system disruption, compromise, or failure.
  CP-2 requires the plan to specify contingency roles and responsibilities with contact information, address contingency information sharing, and be reviewed and approved by designated personnel. The plan must be distributed to key contingency personnel, coordinated with incident handling activities, and updated based on testing results and environmental changes.
• Organizations must provide contingency training to system users consistent with assigned roles and responsibilities, with training provided upon assuming a role, when system changes occur, and at organization-defined frequencies.
  CP-3 requires training content to be updated based on contingency plan testing results, actual contingency events (lessons learned), audit findings, or regulatory changes. Organizations may satisfy training requirements through participation in contingency plan tests and exercises including lessons learned sessions.
• Contingency plans must be tested using organization-defined tests at organization-defined frequencies to determine plan effectiveness and readiness for execution.
  CP-4 specifies testing methods including checklists, walk-throughs, tabletop exercises, simulations, and comprehensive exercises. Organizations must review test results and initiate corrective actions as needed. Testing can include full recovery and reconstitution of the system to a known state.
• Organizations must establish an alternate storage site geographically distinct from the primary site and provide equivalent controls to ensure backup information can be retrieved if the primary site is unavailable.
  CP-6 requires agreements covering environmental conditions, access rules, physical and environmental protection requirements, and coordination of delivery and retrieval of backup media. Alternate sites should be separated from primary sites to reduce susceptibility to the same threats that would affect the primary location.
• Organizations must establish an alternate processing site geographically distinct from the primary site to permit transfer and resumption of essential mission and business functions within organization-defined time periods consistent with recovery objectives.
  CP-7 requires equipment and supplies to be available or under contract at the alternate site, with equivalent controls provided. Alternate processing capability may use physical sites or alternatives such as cloud-based failover services. Agreements must address environmental conditions, access rules, personnel coordination, and priority-of-service provisions.
• Organizations must establish alternate telecommunications services with agreements to permit resumption of essential mission and business functions within organization-defined time periods when primary telecommunications capabilities become unavailable.
  CP-8 covers voice and data services for both primary and alternate processing and storage sites. Alternate services may include additional circuits, network-based approaches, or satellites. Organizations should request Telecommunications Service Priority for national security emergency preparedness and avoid single points of failure shared with primary services.
• Organizations must conduct regular backups of user-level information, system-level information, and system documentation at frequencies consistent with recovery time and recovery point objectives, while protecting the confidentiality, integrity, and availability of backup information.
  CP-9 specifies that system-level backups include system state information, operating system software, middleware, application software, and licenses. Backup protection mechanisms include digital signatures and cryptographic hashes. Testing of backup reliability and integrity must occur at organization-defined frequencies to verify media reliability and information recovery capability.
• Organizations must provide the capability to recover and reconstitute systems to a known state within organization-defined time periods consistent with recovery time and recovery point objectives following disruption, compromise, or failure.
  CP-10 specifies that recovery executes contingency plan activities to restore mission and business functions, while reconstitution returns systems to fully operational states including deactivation of interim capabilities, reestablishment of monitoring, and system reauthorization if required. Recovery capabilities can include automated mechanisms and manual procedures.
• Organizations must provide alternative communications protocols as part of contingency planning to support continuity of operations when primary protocols are unavailable or compromised.
  CP-11 requires organizations to incorporate alternate communications protocol capabilities into contingency plans and associated training or testing. Organizations must assess potential side effects of introducing alternate protocols before implementation.
• When organization-defined conditions are detected, systems supporting critical mission and business functions must enter a safe mode of operation with organization-defined restrictions limiting available operations.
  CP-12 applies particularly to military operations, civilian space operations, nuclear power plant operations, and air traffic control operations. Safe mode can be activated automatically or manually and may restrict operations to selected functions executable under limited power or reduced communications bandwidth.
• Organizations must employ alternative or supplemental security mechanisms to satisfy critical security functions when primary implementation means become unavailable or compromised.
  CP-13 supports system resiliency and continuity of operations by providing backup security capabilities that may be less effective than primary mechanisms but enable continued operations. Examples include issuing one-time pads when multi-factor token authentication is compromised. Alternative mechanisms are applied only to critical security capabilities due to cost and effort constraints.

Source: Section 3.6, pages 142-157

• Identification and authentication controls require organizations to develop documented policies and procedures covering purpose, scope, roles, responsibilities, and compliance, with designated management ownership and periodic review.
  Policies should be consistent with applicable laws and regulations, may be at organization, mission, or system level, and must be updated following assessment findings, security incidents, or regulatory changes. Security and privacy programs should collaborate on policy development.
• Organizations must uniquely identify and authenticate all organizational users and associate their unique identification with processes acting on their behalf.
  Users include employees and equivalents like contractors. Identification applies to all accesses except those explicitly documented in AC-14 using group authenticators. Authentication methods include passwords, physical authenticators, biometrics, or combinations thereof.
• Multi-factor authentication must be implemented for privileged accounts using two or more different factors: something you know, something you have, or something you are.
  Physical authenticators include hardware tokens, smartcards like PIV or CAC cards. Multi-factor authentication can be applied at system logon or application level. Organizations should implement multi-factor authentication for both privileged and non-privileged accounts as appropriate to risk level.
• Devices must be uniquely identified and authenticated before establishing local, remote, or network connections using shared information or organizational authentication solutions.
  Organizations determine required strength of authentication mechanisms based on security categories and business requirements. Device types include non-organization-owned devices. Authentication solutions include IEEE 802.1x, EAP, RADIUS, and Kerberos.
• System identifiers must be managed by obtaining authorization for assignment, selecting identifiers, assigning them to intended recipients, and preventing reuse for a defined time period.
  Identifier types include MAC addresses, IP addresses, and device-unique tokens. Individual identifiers are not applicable to shared accounts. The control prevents assigning previously used identifiers to different individuals, groups, roles, services, or devices.
• Authenticators including passwords, cryptographic devices, biometrics, and certificates must be managed through initial distribution verification, strength assessment, administrative procedures, default changes, and regular refreshing.
  Initial authenticator content must be verified and established by the organization. Authenticators must have sufficient strength for intended use. Organizations must establish procedures for distribution, loss, compromise, damage, and revocation. Default authenticators must be changed before first use.
• Password-based authentication requires maintaining lists of commonly used or compromised passwords, preventing their use, transmitting passwords over encrypted channels, and storing passwords using salted key derivation functions.
  Long passwords and passphrases are preferable to shorter passwords. Composition rules provide marginal security benefits while decreasing usability. Account recovery requires immediate selection of a new password. Organizations should support user selection of long passwords including spaces and all printable characters.
• Authentication feedback must be obscured during the authentication process to prevent exploitation by unauthorized individuals.
  Obscuring methods include displaying asterisks when passwords are typed or displaying feedback for limited time before obscuring. The approach should be selected based on system type and threat significance, balancing security against usability concerns like typographic errors.
• Non-organizational users must be uniquely identified and authenticated for accesses other than those explicitly identified in AC-14.
  Non-organizational users include system users other than organizational users covered by IA-2. Organizations consider security, privacy, scalability, and practicality when establishing authentication requirements for federal system access.
• Out-of-band authentication uses two separate communication paths to identify and authenticate users or devices, with the second path independently verifying authentication or requested actions.
  Example: user authenticates via computer to remote server, then server contacts user via cell phone to verify the action. Out-of-band authentication mitigates man-in-the-middle attacks. Activation conditions include suspicious activities, new threat indicators, or elevated threat levels.
• Adaptive authentication requires individuals to employ supplemental authentication techniques under specific circumstances such as accessing unusual information, excessive quantities, or from suspicious network addresses.
  Adaptive authentication assesses suspicious behavior and can require additional authentication information when pre-established conditions trigger. It augments rather than replaces multi-factor authentication and can increase strength based on records being accessed.
• Users must re-authenticate under defined circumstances including role changes, authenticator changes, system security category changes, privileged function execution, fixed time periods, or periodic intervals.
  Re-authentication requirements supplement device lock re-authentication requirements. Organizations define specific situations requiring re-authentication based on security needs and operational requirements.
• Identity proofing collects, validates, and verifies user identity information at appropriate assurance levels specified in standards and guidelines like SP 800-63-3.
  Identity proofing mitigates threats to user registration and account establishment. Organizations must comply with laws and regulations regarding identity evidence collection. Personnel should consult privacy officials and legal counsel on applicable requirements.
• Identity proofing enhancements include requiring supervisor authorization, presenting identity evidence to registration authority, validating and verifying evidence in person, and confirming address through out-of-band channels.
  Supervisor authorization ensures management awareness and appropriateness of privileges. In-person validation reduces fraudulent credential likelihood. Address confirmation through out-of-band delivery of codes or notices verifies the individual matches the address of record.
• Public key-based authentication requires enforcing authorized access to private keys, mapping authenticated identity to accounts, validating certificates through certification path verification, and implementing local revocation data caches.
  Certificate validation includes checking certification path to accepted trust anchors and reviewing certificate status. Local caches of revocation data support system availability when network access to revocation information is unavailable.
• Organizations must prohibit use of system account identifiers that are the same as public identifiers for communication like email and instant messaging.
  This requirement makes guessing user identifiers more difficult for adversaries. However, additional protections are required for authenticators and credentials to protect the account without this control alone.
• Pairwise pseudonymous identifiers must be generated as opaque, unguessable identifiers by identity providers for use at specific relying parties to discourage subscriber activity tracking.
  Distinct pairwise identifiers contain no identifying information about subscribers except where relying parties demonstrate demonstrable relationships justifying operational need for correlation or all parties consent to correlation.
• Cached authenticators are used for local machine authentication when networks are unavailable but must have use prohibited after a defined time period due to validity concerns.
  Cached authentication information validity becomes questionable when out of date. Time period limits must be defined by organizations based on security requirements and operational needs.

Source: Section 3.7, pages 158-175

• Incident response policy must be developed, documented, and disseminated to defined personnel and roles, addressing purpose, scope, roles, responsibilities, management commitment, coordination, and compliance.
  Organizations should establish policies at organizational, mission/business process, or system level, and designate an official to manage policy and procedures. Policies must be consistent with applicable laws, regulations, and standards. Regular review and updates are required following defined frequencies and triggering events.
• Incident response training must be provided to system users based on assigned roles and responsibilities, within specified timeframes, when system changes occur, and at defined intervals.
  Training content varies by role - general users need to recognize and report incidents, administrators require more detailed handling procedures, and incident responders need forensics and recovery training. Training content must be reviewed and updated following events such as testing, actual incidents, or changes in applicable regulations.
• Organizations must test incident response effectiveness using checklists, walk-throughs, tabletop exercises, simulations, or automated mechanisms at defined frequencies.
  Testing should determine effectiveness and identify weaknesses. Results should provide qualitative and quantitative data to enable continuous improvement of incident response processes and generate measurable metrics in a reproducible format.
• Incident handling capability must implement the five-phase process of preparation, detection and analysis, containment, eradication, and recovery with coordination to contingency planning.
  Lessons learned from incidents must be incorporated into procedures, training, and testing. Handling should be consistent in rigor, intensity, scope, and results across the organization. Organizations may employ dynamic reconfiguration, automated processes, insider threat handling, integrated response teams, forensic analysis, and security operations centers as enhancements.
• Incidents must be tracked and documented to maintain records about status, forensic details, and trends necessary for evaluating incident handling effectiveness.
  Incident information sources include network monitoring, user reports, audit monitoring, physical access monitoring, and supply chain partners. Automated mechanisms can support tracking and analysis of incident data.
• Personnel must report suspected incidents to the organizational incident response capability within defined timeframes and report to designated authorities.
  Reporting types, content, and timeliness are determined by applicable laws and regulations. Automated reporting mechanisms may be used. Incident information informs risk assessments, control effectiveness, acquisition requirements, and technology selection.
• Organizations must provide incident response support resources including help desks, ticketing systems, and forensics services to assist users in handling and reporting incidents.
  Support resources should be integral to the incident response capability. Automated mechanisms can increase availability of information and support. External providers may offer system protection and incident response capabilities through established cooperative relationships.
• An incident response plan must provide a roadmap for implementing the capability, describe its structure and organization, define reportable incidents, establish metrics, and designate responsibility.
  The plan must address organizational mission, size, structure, and functions; outline resource and management support needs; address information sharing; and include breach procedures for personally identifiable information. The plan requires documented approval, distribution, and protection from unauthorized disclosure.
• Information spillage refers to placement of information on unauthorized systems and requires immediate response including isolation, eradication, contamination tracking, and personnel notification.
  Response procedures depend on classification level, system security capabilities, and individual access authorizations. Personnel must be alerted using communication methods not associated with the spill. Training on spillage response and procedures for continued operations during remediation are essential controls.

Source: Section 3.8, pages 176-188

• MA-1 requires organizations to develop, document, and disseminate maintenance policies and procedures at appropriate levels (organization, mission/business process, or system level) with designated management responsibility and regular review cycles.
  Maintenance policies must address purpose, scope, roles, responsibilities, management commitment, and compliance with applicable laws and regulations. Security and privacy programs should collaborate on policy development. Policies should be reviewed and updated following defined frequency and triggering events such as audit findings or changes in applicable standards.
• MA-2 establishes controlled maintenance practices requiring scheduling, documentation, approval, and monitoring of all maintenance activities whether performed on-site or remotely, with equipment sanitization before off-site removal and verification that controls remain functional afterward.
  Organizations must maintain detailed maintenance records including date, time, description of work, personnel names, escorts, and equipment removed or replaced. Supply chain risks associated with replacement components must be considered. Automated mechanisms can be used to manage and document maintenance activities.
• MA-3 requires approval, control, monitoring, and periodic review of maintenance tools to prevent introduction of malicious code or unauthorized modifications into systems.
  Maintenance tools include hardware, software, and firmware used for diagnostic and repair purposes and may be pre-installed, brought on media, cloud-based, or downloaded. Organizations should inspect tools for malicious code and unauthorized modifications, restrict tool use to authorized personnel, and ensure tools are updated with latest patches.
• MA-4 mandates approval and monitoring of nonlocal (remote) maintenance with strong authentication, session termination upon completion, and detailed record-keeping for all remote diagnostic and maintenance activities.
  Strong authentication for remote sessions must resist replay attacks and employ multi-factor authentication such as PKI certificates. Organizations must log audit events for remote sessions and review records for anomalous behavior. Cryptographic mechanisms should protect the integrity and confidentiality of remote communications.
• MA-5 establishes authorization processes for maintenance personnel and requires escorting or supervision of uncleared personnel, with specific restrictions for classified systems requiring security clearances and U.S. citizenship.
  Organizations must verify that non-escorted maintenance personnel possess required access authorizations and designate cleared personnel to supervise those without clearances. For classified systems, personnel must possess appropriate security clearances and formal access approvals. Temporary credentials may be issued to contractors and vendors based on risk assessment.
• MA-6 requires obtaining maintenance support and spare parts for critical system components within defined timeframes following failure to avoid loss or degradation of mission capabilities.
  Preventive maintenance performed at scheduled intervals maintains equipment in satisfactory condition by detecting and correcting incipient failures before they develop. Predictive maintenance evaluates equipment condition through monitoring to perform maintenance at cost-effective times before performance degradation occurs.
• MA-7 restricts or prohibits field maintenance on critical systems, requiring that such maintenance be conducted in trusted facilities with additional controls rather than at operational deployment sites.
  Field maintenance conducted at deployment sites may lack the rigor and quality control checks applied in depot maintenance facilities. For systems designated as critical by the organization, requiring maintenance in trusted facilities ensures consistent control application and reduces operational risk.

Source: Section 3.9, pages 189-197

• Media protection policy and procedures must be developed, documented, and disseminated to defined personnel, addressing purpose, scope, roles, responsibilities, and compliance with applicable laws and regulations.
  Policies can be established at organization, mission/business process, or system level. A designated official manages development and dissemination. Policies and procedures must be reviewed and updated at defined frequencies and following triggering events such as assessments, security incidents, or regulatory changes.
• System media includes both digital media (flash drives, diskettes, magnetic tapes, external hard drives, compact discs, DVDs) and non-digital media (paper, microfilm).
  Understanding the scope of media types is essential for applying appropriate protection controls across different storage and transport methods.
• Access to media must be restricted to authorized personnel or roles, with controls applied based on the sensitivity of the information contained.
  Examples include restricting access to patient medical records to authorized healthcare providers or limiting access to design specifications on compact discs to system development team members.
• System media must be marked with distribution limitations, handling caveats, and applicable security markings, with exemptions possible only for media remaining in controlled areas.
  Security markings are human-readable attributes reflecting applicable laws, orders, and regulations. Public domain or publicly releasable information may not require markings.
• Media must be physically controlled and securely stored in controlled areas using locked drawers, cabinets, or controlled media libraries, with storage commensurate to the security classification of information.
  Accountability mechanisms include conducting inventories and tracking checkout and return procedures. Automated restricted access mechanisms can log access attempts and grant records.
• Media during transport outside controlled areas must be protected, controlled, and tracked using measures such as cryptography or locked containers, with activities restricted to authorized personnel.
  Organizations must maintain accountability throughout transport, document transport activities, and designate identified custodians to provide specific points of contact and facilitate accountability.
• System media must be sanitized prior to disposal, reuse, or release from organizational control using techniques and procedures commensurate with the security classification of the information.
  Sanitization techniques include clearing, purging, cryptographic erase, de-identification, and destruction. NSA standards control sanitization for classified information; NARA policies control sanitization for controlled unclassified information.
• Organizations must review, approve, track, document, and verify media sanitization and disposal actions to ensure compliance with records retention policies.
  Records must include personnel involved, media types, files stored, sanitization methods, dates and times, and verification that sanitization was effective prior to disposal.
• Sanitization equipment and procedures must be tested at defined frequencies to ensure the intended sanitization is being achieved effectively.
  Testing may be conducted by qualified and authorized external entities, including federal agencies or external service providers.
• Nondestructive sanitization techniques should be applied to portable storage devices obtained from untrustworthy sources or when chain of custody cannot be maintained before connecting to organizational systems.
  Portable storage devices can contain malicious code that transfers through USB ports or entry portals. Sanitization provides assurance that devices are free of malicious code.
• Dual authorization must be enforced for sanitization of designated system media, with rotating duties among individuals to reduce collusion risk.
  Two technically qualified individuals must conduct the sanitization task, ensuring proper standards compliance and protecting against errors or false claims.
• Remote purging or wiping capability should be provided for designated systems to protect information if devices are obtained by unauthorized individuals.
  Remote purge or wipe commands require strong authentication. The function can be implemented by overwriting data multiple times or destroying decryption keys.
• The use of specific types of system media on designated systems must be restricted or prohibited, and portable storage devices with no identifiable owner must be prohibited.
  Controls can include physical cages blocking external ports, disabling write capabilities, limiting use to approved organizational devices, or restricting by device type. Identifiable owners enable responsibility assignment for addressing vulnerabilities.
• Media downgrading processes must remove information by security category or classification level so information cannot be retrieved or reconstructed before release outside the organization.
  Downgrading includes redacting information to enable wider release and distribution. Processes must be verified as commensurate with the security category and access authorizations of recipients. Documentation of downgrading actions is required.
• Downgrading equipment and procedures must be tested at defined frequencies to ensure downgrading actions are achieved effectively.
  This includes testing both controlled unclassified information and classified information downgrading processes using approved sanitization tools and techniques.

Source: Section 3.10, pages 198-205

• Organizations must develop, document, and disseminate physical and environmental protection policy and procedures at the organization, mission/business process, or system level, designate an official to manage them, and review them at defined frequencies and upon triggering events.
  PE-1 establishes the foundational requirement for governance of the entire PE control family. Policy and procedures must address purpose, scope, roles, responsibilities, management commitment, and coordination among organizational entities, and be consistent with applicable laws and standards.
• Physical access authorizations must be maintained as an approved list of individuals with facility access, issued via credentials such as ID badges or smart cards, reviewed at defined frequencies, and removed when no longer needed.
  PE-2 applies to both employees and visitors. Role-based authorization is addressed in enhancement (1), two-form identification for visitors in enhancement (2), and restriction of unescorted access to those with appropriate clearances or need-to-know in enhancement (3).
• Physical access control must be enforced at defined entry and exit points by verifying authorizations before granting access and using physical access control systems or guards.
  PE-3 establishes baseline controls including maintaining access audit logs, controlling access to public areas, escorting visitors, securing physical access devices, inventorying devices regularly, and changing combinations or keys at defined intervals or when compromised. Multiple enhancements address system-level access, perimeter security checks, 24-hour guards, lockable casings, anti-tamper technologies, physical barriers, and access control vestibules.
• Physical access to system distribution and transmission lines within facilities must be controlled using security measures such as locked spare jacks, locked wiring closets, conduit protection, or wiretapping sensors.
  PE-4 prevents accidental damage, disruption, physical tampering, and eavesdropping on unencrypted transmissions by controlling physical access to cabling and transmission infrastructure.
• Physical access to output devices must be controlled to prevent unauthorized individuals from obtaining output through locked rooms, keypad access, monitoring by personnel, screen filters, or headphones.
  PE-5 applies to monitors, printers, scanners, audio devices, facsimile machines, and copiers. Enhancement (2) allows linking individual identity to output device receipt through authentication functionality on devices.
• Physical access to facilities must be monitored to detect and respond to physical security incidents, access logs must be reviewed at defined frequencies and upon defined events, and results must be coordinated with incident response.
  PE-6 establishes baseline monitoring requirements. Enhancements provide for intrusion alarms and surveillance equipment (1), automated intrusion recognition and response (2), video surveillance with defined retention (3), and system-level physical access monitoring (4).
• Visitor access records must be maintained for defined time periods, reviewed at defined frequencies, and anomalies reported to designated personnel, including visitor names, identification, dates, times, purpose, and contacted individuals.
  PE-8 supports ongoing verification that access authorizations are current and required. Enhancement (1) allows automated record maintenance and review, and enhancement (3) permits limiting personally identifiable information elements based on privacy risk assessment.
• Power equipment and cabling must be protected from damage and destruction; redundant cabling paths may be physically separated and automatic voltage controls employed for critical components.
  PE-9 addresses protection of both internal cabling and external power sources including generators and backup systems, with enhancements for redundancy and voltage stability.
• Emergency power shutoff capability must be provided for defined systems or components, with switches placed in accessible locations for authorized personnel and protected from unauthorized activation.
  PE-10 applies primarily to data centers, mainframe rooms, and areas with computer-controlled machinery to enable safe emergency response.
• An uninterruptible power supply must be provided to facilitate orderly shutdown or transition to long-term alternate power in case of primary power loss.
  PE-11 establishes the baseline using batteries, supercapacitors, or flywheels for near-instantaneous protection. Enhancements allow for alternate power supplies with manual or automatic activation maintaining minimal or full operational capability.
• Automatic emergency lighting must be employed and maintained that activates during power outage and covers emergency exits and evacuation routes within the facility.
  PE-12 applies primarily to data centers, server rooms, and mainframe rooms. Enhancement (1) requires emergency lighting for all areas supporting essential mission and business functions.
• Fire detection and suppression systems must be employed and maintained with support from independent energy sources.
  PE-13 applies to data centers, server rooms, and mainframe computer rooms. Enhancements require automatic detection activation with notifications (1), automatic suppression with notifications and capability when unstaffed (2), and regular inspections by qualified personnel (4).
• Temperature, humidity, pressure, radiation, and other environmental control levels must be maintained within acceptable ranges and monitored at defined frequencies.
  PE-14 applies primarily to facilities with concentrations of system resources. Enhancements provide for automatic controls to prevent harmful fluctuations (1) and monitoring with alarms and notifications (2).
• Systems must be protected from water damage through accessible and functional master shutoff or isolation valves known to key personnel.
  PE-15 applies to data centers, server rooms, and mainframe computer rooms. Enhancement (1) allows automated detection of water presence and alerting of personnel.
• System components entering and exiting the facility must be authorized and controlled, and records of components must be maintained.
  PE-16 may require restricting access to delivery areas and isolating them from systems and media libraries.
• Organizations must determine and document alternate work sites allowed for employee use, employ defined controls at those sites, assess control effectiveness, and provide incident communication capability for employees.
  PE-17 covers government facilities and private residences. Alternate work sites support contingency operations and controls may vary by site type or work activities conducted.
• System components must be positioned within the facility to minimize potential damage from defined physical and environmental hazards and to minimize opportunity for unauthorized access.
  PE-18 considers hazards such as floods, fires, tornadoes, earthquakes, hurricanes, terrorism, vandalism, electromagnetic pulse, and electrical interference, as well as proximity to entry points used by unauthorized individuals.
• Systems must be protected from information leakage due to electromagnetic signal emanations, implemented in accordance with national Emissions Security policies based on information security category or classification.
  PE-19 addresses intentional or unintentional data release from electromagnetic emissions. Emissions Security (EMSEC) policies include former TEMPEST policies.
• Organizations must employ defined asset location technologies to track and monitor the location and movement of defined assets within controlled areas.
  PE-20 helps ensure critical assets including vehicles, equipment, and system components remain in authorized locations; deployment must coordinate with privacy considerations.
• Organizations must employ defined protective measures against electromagnetic pulse damage for specified systems and system components.
  PE-21 addresses protection from natural or man-made electromagnetic pulse bursts using shielding, surge suppressors, ferro-resonant transformers, and earth grounding, particularly for critical infrastructure systems.
• Defined system hardware components must be marked to indicate the impact level or classification level of information permitted to be processed, stored, or transmitted.
  PE-22 applies to input devices (computers, keyboards, tablets, smartphones) and output devices (printers, monitors, facsimile machines, scanners, copiers). Marking reflects applicable laws, orders, policies, regulations, and standards.
• Organizations must consider physical and environmental hazards when planning the location or site of facilities, and for existing facilities, must consider such hazards in organizational risk management strategy.
  PE-23 addresses hazards including floods, fires, tornadoes, earthquakes, hurricanes, terrorism, vandalism, electromagnetic pulse, and electrical interference, with internal component positioning covered separately in PE-18.

Source: Section 3.11, Physical and Environmental Protection, pages 206-220

• Planning policy and procedures must be developed, documented, and disseminated at organization, mission/business process, or system level, addressing purpose, scope, roles, responsibilities, and compliance while remaining consistent with applicable laws and regulations.
  Organizations should designate an official to manage policy and procedures development. Policies and procedures must be reviewed and updated following specified frequencies and triggering events such as assessment findings, security incidents, or regulatory changes. Security and privacy programs should collaborate on development.
• System security and privacy plans must comprehensively define system components, operational context, information types, security categorization, threats, privacy risk assessments, dependencies, control baselines, and risk determinations for architecture and design decisions.
  Plans are scoped to the system within its authorization boundary and contain sufficient detail to correctly implement and assess controls. Plans may be integrated documents or collections of existing documents that reference policies and procedures. They are living documents requiring updates throughout the system development life cycle.
• Individuals requiring system access must receive documented rules of behavior describing their responsibilities and expected conduct, and must provide written acknowledgment before authorization and re-acknowledge when rules are revised.
  Rules of behavior represent an access agreement type and may differentiate between privileged and general users. Documented acknowledgment can be satisfied through training programs that include rules of behavior, using electronic or physical signatures and agreement check boxes.
• A Concept of Operations (CONOPS) must be developed describing how the organization intends to operate the system from information security and privacy perspectives, and must be reviewed and updated throughout the system development life cycle.
  CONOPS may be included in security or privacy plans or other lifecycle documents. It requires updating to remain consistent with design, architecture, and operational procedures, with changes reflected in related plans and procurement specifications.
• Security and privacy architectures must describe requirements and approaches for protecting confidentiality, integrity, and availability, minimizing privacy risk, integrating with enterprise architecture, and identifying external system dependencies.
  Architectures include allocation of security and privacy functionality across layers, user roles and privileges, information types, supply chain requirements, and restoration priorities. Defense-in-depth strategies allocate controls to multiple locations and layers to increase adversary work factor and detection likelihood. Supplier diversity can be required for certain controls.
• Central management of controls and processes promotes standardization of implementations, efficient use of organizational resources, and supports independence requirements for authorizations and continuous monitoring.
  Central management includes organization-wide planning, implementing, assessing, authorizing, and monitoring of designated controls. Automated tools can improve accuracy and provide data aggregation, correlation, alerting, and dashboards. Hybrid controls may be managed partially at the system level when full central management is not feasible.
• Control baselines are predefined sets of controls addressing protection needs of groups or communities of interest, selected based on stakeholder needs, mission and business requirements, and applicable mandates from laws and regulations.
  Federal baselines in SP 800-53B are based on FISMA and PRIVACT requirements. Baseline selection is determined by analysis of information types, potential adverse impacts of loss or compromise, and system and organizational risk assessments. CNSSI 1253 provides guidance for national security systems.
• Baseline tailoring allows organizations to specialize control sets by applying defined tailoring actions including identifying common controls, applying scoping, selecting compensating controls, assigning parameter values, and supplementing with additional controls.
  Tailoring facilitates specialization to reflect specific mission and business functions, operational environments, threats, vulnerabilities, and mission-critical conditions. Tailoring actions in SP 800-53B can be applied to federal baselines or supplemented with additional actions for specific community needs.

Source: Section 3.12, pages 221-229

• Program management controls are organization-wide controls independent of individual information systems and FIPS 200 impact levels.
  These controls implement federal compliance requirements and are documented in information security and privacy program plans that supplement system-level plans to provide complete security and privacy coverage.
• An organization must develop and maintain an information security program plan approved by a senior official with accountability for security risk.
  The plan provides an overview of security requirements, describes program management and common controls, assigns roles and responsibilities, and requires regular updates following organizational changes and assessment findings.
• Organizations must appoint a senior agency information security officer with mission and resources to coordinate and implement the organization-wide security program.
  This role is essential for managing the information security program and may be titled senior information security officer or chief information security officer.
• Information security and privacy resources must be included in capital planning and investment requests with documented exceptions.
  Organizations should establish champions, assign specialized expertise, and empower oversight bodies such as Investment Review Boards to manage security and privacy aspects of capital planning.
• Organizations must implement a plan of action and milestones process to document and track remedial security, privacy, and supply chain risk management actions.
  Plans must be reviewed for consistency with organizational risk management strategy and updated based on control assessment findings and continuous monitoring results.
• Organizations must maintain an organization-wide inventory of systems updated at defined frequencies.
  PM-5(1) requires organizations to maintain a separate inventory of all systems, applications, and projects that process personally identifiable information.
• Organizations must develop outcome-based measures of performance to monitor the effectiveness and efficiency of security and privacy programs.
  These measures should be aligned with organizational risk tolerance as defined in the risk management strategy.
• Enterprise architecture must integrate security and privacy requirements to ensure they are addressed throughout the system development life cycle.
  Organization-level security and privacy architectures representing all systems are distinct from system-level architectures and should be consistent with organizational risk management strategy.
• Organizations must address information security and privacy in critical infrastructure protection plans.
  Protection strategies are based on prioritization of critical assets and resources, with specific requirements found in applicable laws, executive orders, and standards.
• A comprehensive organization-wide risk management strategy must address both security risk and privacy risk with defined risk tolerance and mitigation strategies.
  The strategy is led by the senior accountable official for risk management and implemented through a risk executive function to ensure consistent organization-wide application.
• Authorization processes must be integrated into an organization-wide risk management program with designated roles for risk management.
  Specific roles include risk executive function and authorizing officials for each system and common control provider, integrated with continuous monitoring processes.
• Organizations must define mission and business processes considering information security, privacy, and resulting risks, then determine protection needs.
  Information protection and personally identifiable information processing needs are technology-independent capabilities derived from mission needs and risk management strategy.
• Organizations that handle classified information must implement an insider threat program with a cross-discipline incident handling team.
  Programs include centralized integration of technical and nontechnical information, user monitoring policies, awareness training, and human resources coordination with legal oversight.
• Organizations must establish a security and privacy workforce development program defining knowledge, skills, and abilities needed for security and privacy roles.
  Programs should include role-based training, qualification standards, and career paths to encourage professionals to advance and fill positions with greater responsibility.
• Organizations must implement a process for coordinating organization-wide security and privacy testing, training, and monitoring activities.
  These plans must be reviewed for consistency with risk management strategy and informed by current threat and vulnerability assessments.
• Organizations should establish contact with security and privacy groups and associations to facilitate education, maintain currency with practices, and share threat information.
  Contact with special interest groups, professional associations, and peer organizations helps organizations address rapidly changing technologies and threats.
• Organizations must implement a threat awareness program with cross-organization information-sharing capability for threat intelligence.
  Sharing may be bilateral or multilateral and enables organizations to learn from others' experiences with tactics, techniques, procedures, and effective mitigations.
• Organizations must establish policy and procedures to ensure controlled unclassified information on external systems is protected per applicable standards.
  Policy must be reviewed and updated at defined frequencies and implemented through contracting processes in accordance with federal regulations.
• Organizations must develop and maintain an organization-wide privacy program plan describing privacy program structure, resources, roles, and goals approved by a senior official.
  The privacy program plan documents program management and common controls with sufficient detail to enable compliant implementation and determine privacy risks.
• Organizations must appoint a senior agency official for privacy with authority, accountability, and resources to implement privacy requirements and manage privacy risks.
  The senior agency official for privacy is an organizational official who participates in data management and data integrity boards and may be titled chief privacy officer.
• Organizations must maintain a central webpage serving as the public source of information about the privacy program with links to privacy policies, impact assessments, and contact information.
  PM-20(1) requires plain language privacy policies on all external-facing websites and digital services updated when substantive changes occur.
• Organizations must develop and maintain an accurate accounting of personally identifiable information disclosures including date, nature, purpose, and recipient information.
  Accounting records must be retained for the length the information is maintained or five years after disclosure, whichever is longer, and be available to individuals upon request.
• Organizations must establish policies and procedures to review personally identifiable information for accuracy, relevance, timeliness, and completeness throughout the information life cycle.
  Procedures must include mechanisms for individuals to request correction or deletion, clearly defined denial decision processes with appeals, and notification when corrections occur.
• Organizations must establish a Data Governance Body with defined roles and responsibilities to ensure coherent policies balancing data utility with security and privacy.
  The body establishes policies for data modeling, quality, integrity, de-identification, and review of applications to release data outside the organization.
• Organizations must establish a Data Integrity Board to review matching program proposals and conduct annual reviews of all matching programs in which the agency participates.
  The board includes the Inspector General and senior agency official for privacy and reviews computerized comparisons of records from multiple automated systems.
• Organizations must develop and implement policies limiting the use of personally identifiable information for internal testing, training, and research, preferring placeholder data when possible.
  Policies must be reviewed and updated at defined frequencies and authorized by appropriate officials in consultation with privacy officials.
• Organizations must implement a complaint management process with easy-to-use mechanisms for the public to file complaints about security and privacy practices.
  Process must include tracking to ensure complaints are reviewed and addressed within defined timeframes, acknowledgement of receipt, and response to complaints.
• Organizations must develop and disseminate privacy reports to oversight bodies and officials demonstrating accountability with privacy mandates.
  Reports must be reviewed and updated at defined frequencies and include annual reports to OMB for federal agencies.
• Organizations must identify and document assumptions, constraints, priorities, trade-offs, and risk tolerance affecting risk assessment and response as part of risk framing.
  Risk framing results must be distributed to defined personnel and reviewed at defined frequencies; findings inform the risk management strategy.
• Organizations must appoint a Senior Accountable Official for Risk Management to align security and privacy management with strategic, operational, and budgetary planning.
  A Risk Executive function must be established to view and analyze risk organization-wide and ensure consistent management of risk across the organization.
• Organizations must develop an organization-wide supply chain risk management strategy addressing security and privacy risks in system development, acquisition, maintenance, and disposal.
  The strategy expresses risk appetite and tolerance, acceptable mitigation approaches, and implementation methods; PM-30(1) requires identification and assessment of critical suppliers.
• Organizations must develop an organization-wide continuous monitoring strategy establishing metrics, frequencies, correlation analysis, and reporting of security and privacy status.
  Continuous monitoring facilitates ongoing risk awareness, guides risk response actions, and enables maintaining system authorizations in dynamic environments.
• Organizations must analyze systems supporting mission-essential services to ensure information resources are used consistent with intended purpose.
  Over time systems may be used for unintended functions that expose resources to increased threat, particularly impacting mission-essential services and functions.

Source: Section 3.13, pages 230-248

• Personnel security policy must address purpose, scope, roles, responsibilities, management commitment, coordination, and compliance, and be consistent with applicable laws and regulations.
  Organizations must develop and disseminate personnel security policies at the appropriate level (organization, mission, or system), designate an official to manage them, and review them regularly following defined events such as audit findings or regulatory changes.
• All organizational positions must be assigned a risk designation based on potential damage to service integrity and national security impact.
  Position risk designations guide investigation levels and determine the types of authorizations individuals receive when accessing systems. The Position Designation System (PDS) assesses duties and responsibilities to establish risk and sensitivity levels.
• Organizations must screen individuals before authorizing system access and rescreen them according to defined conditions and frequencies.
  Personnel screening includes background investigations and agency checks. Rescreening conditions may vary based on information types processed; enhanced screening is required for classified information, special access programs, restricted data, and sensitive compartmented information.
• Upon employment termination, organizations must disable system access within a defined time period, revoke authenticators and credentials, conduct exit interviews covering security topics, and retrieve security-related property.
  Exit interviews remind terminated individuals of nondisclosure agreements and post-employment constraints. Timely execution is especially critical for individuals terminated for cause. Automated mechanisms can accelerate notification and access revocation.
• When personnel are reassigned or transferred, organizations must review ongoing operational need for current access authorizations and modify them to match new operational requirements.
  Transfer actions may include returning old keys and identification, closing old accounts, establishing new accounts, and updating system access privileges. Notifications must be sent within defined timeframes to relevant personnel.

Source: Section 3.14, pages 249-253

• Organizations must establish policy and procedures for personally identifiable information processing and transparency that address purpose, scope, roles, responsibilities, and compliance with applicable laws and regulations.
  PT-1 requires development and dissemination of PII processing policies at organization, mission, or system level, with designation of an official to manage them and periodic review following defined events such as assessment findings or regulatory changes.
• Organizations must determine and document the legal authority that permits processing of personally identifiable information and restrict processing only to that which is authorized.
  PT-2 defines processing as operations across the information lifecycle including creation, collection, use, storage, dissemination, disclosure, and disposal. Authority must be documented in privacy policies, system of records notices, privacy impact assessments, contracts, or other documentation as appropriate.
• Organizations must identify, document, and publicly describe the specific purposes for which personally identifiable information is processed and restrict processing to compatible purposes.
  PT-3 requires that purposes be documented and described in privacy notices and policies, with monitoring for changes and implementation of mechanisms to ensure new processing aligns with defined requirements or risk management decisions.
• Organizations must implement tools or mechanisms for individuals to provide informed consent prior to collection of personally identifiable information.
  PT-4 allows organizations to select consent as a control when individuals can reasonably understand the privacy risks, and permits opt-in, opt-out, revocation, and tailored consent mechanisms to support individual autonomy and risk management.
• Organizations must provide clear, plain-language privacy notices available to individuals at first interaction and subsequently at defined frequencies that identify processing authority, purposes, and other required information.
  PT-5 requires notices that are easy to understand and may include just-in-time notices presented at specific data actions or Privacy Act statements on forms collecting system of records information.
• Federal agencies maintaining Privacy Act systems of records must draft, submit for advance review, and publish system of records notices in the Federal Register that describe system existence, purposes, record categories, routine uses, and exemptions.
  PT-6 requires that notices remain accurate and up-to-date and that routine uses be reviewed to ensure continued compatibility with original collection purposes and that exemptions remain necessary and appropriate.
• Organizations must apply appropriate processing conditions to specific categories of personally identifiable information as required by law, regulation, or privacy risk assessment.
  PT-7 requires organizations to consult with privacy officials and legal counsel regarding protections for sensitive categories such as Social Security numbers, which must have unnecessary uses eliminated, or First Amendment information, which is subject to statutory restrictions.
• Federal agencies conducting computer matching programs must obtain Data Integrity Board approval, develop matching agreements, publish Federal Register notices, and independently verify results before taking adverse action against individuals.
  PT-8 applies when agencies match records from two or more Privacy Act systems or from a system and non-federal records for benefit program or personnel purposes, and requires notice and contest opportunity for affected individuals.
• Data tagging enhancements enable automated tracking and enforcement of authorized processing and processing purposes through metadata attached to personally identifiable information elements.
  PT-2(1) and PT-3(1) support conveying authorized processing and purposes throughout systems via tags, facilitating both human oversight and automated enforcement of data handling restrictions.
• Just-in-time consent and notice mechanisms allow organizations to obtain individual participation in processing decisions or inform individuals at the moment of data collection or specific processing actions.
  PT-4(2) and PT-5(1) present consent or notice at times most relevant to individuals, addressing circumstances where assumptions about processing may no longer be accurate or where specific data actions create elevated privacy risk.

Source: Section 3.15, pages 256-264

• Risk assessment policy and procedures must be developed, documented, and disseminated to defined personnel at organization, mission/business process, or system levels, with designated official responsibility for management.
  RA-1 requires that policies address purpose, scope, roles, responsibilities, management commitment, and coordination, while remaining consistent with applicable laws, executive orders, and regulations. Security and privacy programs should collaborate on development. Policies and procedures are reviewed and updated at defined frequencies or following triggering events such as security incidents or regulatory changes.
• Security categorization identifies potential adverse impacts from loss of confidentiality, integrity, or availability and must be documented in the security plan with authorizing official approval.
  RA-2 requires categorization of systems and their information, considering impacts to organizational operations, assets, and individuals. Organizations conduct this as an organization-wide activity involving senior officials and system owners. The categorization process is revisited throughout the system development life cycle to maintain accuracy. Impact-level prioritization can further partition systems into sub-categories for more granular risk-based decision-making.
• Risk assessments must identify threats and vulnerabilities, determine likelihood and magnitude of harm, and integrate organizational findings with system-level assessments.
  RA-3 requires assessment of how unauthorized access, use, disclosure, disruption, modification, or destruction could impact the system and information. Risk assessments consider threats from external parties including contractors and service providers. Assessments occur at all three hierarchy levels and throughout the system development life cycle, with results documented, reviewed at defined frequencies, and disseminated to relevant personnel. Supply chain risks, all-source intelligence, dynamic threat awareness, and predictive analytics can enhance risk assessment.
• Vulnerability monitoring and scanning must occur at organization-defined frequencies, with tools that enable interoperability and automate the vulnerability management process.
  RA-5 requires continuous monitoring for vulnerabilities in systems and applications using standardized tools that enumerate platforms, format checklists, and measure impact. Scan reports must be analyzed, legitimate vulnerabilities remediated according to risk assessment, and findings shared across the organization. Tools must be readily updated as new vulnerabilities are discovered. Vulnerability disclosure programs and bug bounty programs can supplement internal scanning efforts.
• Technical surveillance countermeasures surveys detect technical surveillance devices and security weaknesses at defined locations and frequencies.
  RA-6 surveys are performed by qualified personnel to identify technical penetration risks and evaluate the technical security posture of facilities through visual, electronic, and physical examinations. Results inform risk assessments and understanding of organizational exposure to adversaries.
• Risk response decisions must align with organizational risk tolerance and can include mitigation through new or strengthened controls, acceptance, sharing, transfer, or avoidance.
  RA-7 requires responding to assessment, monitoring, and audit findings. Organizations determine appropriate responses before generating plans of action; if mitigation cannot be completed immediately, a plan of action and milestones entry is required. Risk response is distinct from but precedes detailed mitigation planning.
• Privacy impact assessments analyze how personally identifiable information is handled to ensure compliance, determine privacy risks, and identify mitigation approaches.
  RA-8 requires conducting privacy impact assessments before developing or procuring information technology that processes personally identifiable information or initiating new PII collections meeting specified criteria. The assessment is a living document updated when information technology, organizational practices, or privacy risks change. Senior agency officials for privacy must collaborate with program managers, system owners, and other relevant personnel.
• Criticality analysis identifies critical system components and functions at defined decision points to inform protection prioritization and supply chain risk management.
  RA-9 applies functional decomposition to identify mission-critical components, considering interfaces, dependencies, and impact of failure on organizational missions. Analysis considers operational environment connections to cyber-physical systems and outsourced services. Early analysis enables design modifications such as redundancy to reduce criticality. Criticality of information is assessed as part of security categorization.
• Threat hunting is a proactive cyber defense capability that searches for indicators of compromise and detects threats evading existing controls.
  RA-10 requires establishing and maintaining threat hunting to search for compromise indicators and track advanced threats. Threat hunting teams leverage threat intelligence and create new intelligence shared with peer organizations and ISACs. It complements traditional protections like firewalls and intrusion detection systems by enabling early detection and response to cyber adversaries.

Source: Section 3.16, pages 265-275

• Organizations must develop and document system and services acquisition policy and procedures at appropriate organizational levels, designate an official to manage them, and review them regularly following defined events.
  System and services acquisition policies should address purpose, scope, roles, responsibilities, and compliance; be consistent with applicable laws and regulations; and be coordinated across organizational entities. Security and privacy programs should collaborate on development, and policies should contribute to security and privacy assurance.
• Resource allocation for information security and privacy must be determined during mission and business planning, documented in capital planning processes, and established as a discrete line item in organizational budgeting.
  Resource allocation includes funding for system acquisition, sustainment, and supply chain-related risks throughout the entire system development life cycle, ensuring adequate financial support for security and privacy measures.
• A system development life cycle incorporating security and privacy considerations from the start is fundamental; organizations must define roles and responsibilities, identify personnel, and integrate risk management throughout.
  Early integration of security and privacy is a foundational principle of systems and privacy engineering. Qualified personnel should be included to ensure requirements are met. Integration of security and privacy architectures into enterprise architecture supports alignment with organizational risk management strategy.
• Acquisition contracts must explicitly include security and privacy functional requirements, strength of mechanism requirements, assurance requirements, documentation requirements, and acceptance criteria.
  Strength requirements address correctness, completeness, resistance to tampering, and resistance to direct attack. Assurance requirements include development processes and evidence from assessment activities. Controls must be specified with responsibility allocation and clear acceptance criteria.
• System documentation must include both administrator and user documentation covering secure configuration, security and privacy functions, known vulnerabilities, and user responsibilities.
  Administrator documentation describes installation, operation, and maintenance of security mechanisms. User documentation explains how to use security functions securely and user responsibilities. Attempts to obtain documentation from manufacturers must be documented, with recreated documentation if essential.
• Systems security and privacy engineering principles must be applied throughout specification, design, development, implementation, and modification of systems and components.
  These principles include developing layered protections, establishing policies as design foundation, incorporating requirements into development lifecycle, delineating security boundaries, training developers on secure software, and threat modeling. Application facilitates trustworthy and resilient system development.
• External system service providers must comply with organizational security and privacy requirements, with documented oversight roles and continuous monitoring of control compliance.
  Organizations must establish and maintain trust relationships with providers, define user roles and responsibilities, employ monitoring processes, and retain responsibility for managing risks even though they have no direct control over provider implementations. Service-level agreements define performance expectations and remedies.
• Developers must implement configuration management during system design, development, implementation, operation, and disposal, documenting and controlling integrity of approved changes.
  Configuration items include designs, specifications, source code, hardware schematics, and object code. Masters must be protected from unauthorized modification. Configuration management must track authorized changes and prevent unauthorized ones throughout the system lifecycle.
• Developers must conduct testing and evaluation at all post-design stages, including unit, integration, system, and regression testing, producing evidence of execution and correct flaw remediation.
  Testing confirms controls are implemented correctly and operate as intended. Organizations require security assessment plans with specific activities, analysis types, frequency, and rigor. Testing depth refers to rigor and detail; coverage refers to scope of artifacts included.
• Developer security and privacy architecture must be consistent with organizational enterprise architecture, accurately describe required security and privacy functionality, and express how security functions work together to provide unified protection.
  Developers must produce design specifications and security architecture showing allocation of controls among physical and logical components. This requirement applies to external developers and ensures alignment with organizational security architecture as part of enterprise architecture.
• Critical system components that cannot be adequately protected through standard controls may need to be reimplemented or custom developed to address specific threats and vulnerabilities.
  Organizations determine which components cannot be trusted due to threats and vulnerabilities with no viable mitigating controls. Custom development may achieve higher assurance by making standard attacks less likely to succeed.
• System components must be replaced when support is no longer available from developers or vendors, or alternative sources for continued support must be established through in-house or contracted arrangements.
  Unsupported components lacking patches and updates present exploitation opportunities for adversaries. Alternative support arrangements can include in-house development of patches or contracted external support, with additional isolation controls if components cannot be replaced.
• Systems supporting mission-essential services or functions must be enhanced through design modification, augmentation, or reconfiguration to increase trustworthiness.
  Enhancement may occur at design level or post-design through modifications or augmentation with additional components, such as supplemental authentication or non-repudiation functions to strengthen critical resource identity and protection.

Source: Section 3.17, System and Services Acquisition, pages 276-318

• System and communications protection policies and procedures must be developed, documented, and disseminated at organization, mission/business process, or system levels and reviewed regularly following defined events.
  A designated official manages the development and dissemination of these policies and procedures. The risk management strategy is a key factor in establishing such policies. Security and privacy programs should collaborate on development, with organization-level policies generally preferred to avoid redundancy across multiple system-specific policies.
• System management functionality must be separated from user functionality through physical or logical means to prevent non-privileged users from accessing administrative capabilities.
  This can be achieved using different computers, operating system instances, virtualization, or additional access controls on administrative interfaces. The separation prevents general users from obtaining administrative privileges or seeing management options.
• Security functions must be isolated from nonsecurity functions using partitions, domains, and access control mechanisms to protect the integrity and confidentiality of security-related code and hardware.
  Isolation boundaries can be implemented through processor rings, file system protections, and address space protections. The goal is to minimize the amount of code within the isolation boundary and achieve high cohesion with low coupling between modules.
• Systems must prevent unauthorized information transfer via shared system resources by ensuring residual information from prior users is not accessible to subsequent users after resource release.
  This protection addresses object reuse and residual information protection but does not cover information remanence, covert channels, or single-user system components. Procedures must be followed when processing switches between different classification levels.
• Organizations must protect against denial-of-service events by either protecting against their effects or limiting them through appropriate controls based on threat type and capacity management.
  Controls may include boundary protection devices to filter packets, increased network capacity and bandwidth, service redundancy, monitoring tools to detect indicators, and resource quotas. External connections should be restricted and systems should implement detection and capacity monitoring.
• Boundary protection must monitor and control communications at external and key internal interfaces, implement demilitarized zones for public-facing components, and connect to external networks only through managed boundary protection devices.
  Boundary protection devices include gateways, routers, firewalls, and encrypted tunnels. Traffic flow policies should follow deny-by-default and allow-by-exception principles. Organizations must monitor for threats, prevent split tunneling on remote devices, and implement fail-secure mechanisms.
• Transmission confidentiality and integrity of information must be protected for both internal and external communications through physical or logical means, including cryptographic mechanisms and protected distribution systems.
  Cryptographic protection during transmission prevents unauthorized disclosure and modification. Pre- and post-transmission handling must also maintain confidentiality and integrity. Message headers, routing information, and communication patterns may require additional protection.
• Network connections associated with communications sessions must be terminated at session end or after defined inactivity periods to prevent unauthorized continued access.
  Termination applies to both internal and external networks and includes de-allocating TCP/IP address and port pairs at the operating system level and application level.
• A trusted communications path must be provided for users to communicate directly with system security functions, particularly for authentication and re-authentication, that cannot be spoofed by untrusted applications.
  Trusted paths employ out-of-band signals or key combinations that cannot be hijacked. The system or user can initiate the path. An irrefutable communications path permits the system to initiate it so users can unmistakably recognize it as trusted.
• Cryptographic keys must be established and managed according to defined requirements covering generation, distribution, storage, access, and destruction, with validated cryptographic modules and algorithms employed.
  Key management can use manual procedures or automated mechanisms. Organizations must manage trust stores to ensure only approved trust anchors are included. Symmetric keys and asymmetric keys have specific production and distribution requirements.
• Cryptographic protection appropriate to the identified use cases must be implemented, using FIPS-validated or NSA-approved cryptography depending on whether the goal is to protect classified information, implement digital signatures, or enforce information separation.
  Organizations determine cryptographic uses and associated types based on applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Implementation must align with specific use case requirements.
• Remote activation of collaborative computing devices must be prohibited except for defined exceptions, and explicit indication of use must be provided to physically present users.
  Collaborative computing devices include remote meeting devices, networked whiteboards, cameras, and microphones. Organizations should provide physical or logical disconnect options and disable such devices in secure work areas like SCIFs.
• Security and privacy attributes must be associated with information exchanged between systems and components to support access control, information flow control, and privacy requirements.
  Attributes enable implementation of policies and may reflect dissemination instructions or permitted uses of personally identifiable information. The integrity of transmitted attributes must be verified to prevent unauthorized modification.
• Public key certificates must be issued under an organization-defined policy or obtained from approved providers, and only approved trust anchors must be included in managed trust or certificate stores.
  PKI certificates include both external-facing certificates and those for internal system operations. Root certificates serve as trust anchors in hierarchical cryptographic systems.
• Mobile code must be defined as acceptable or unacceptable, and its use must be authorized, monitored, and controlled within systems to prevent damage from malicious code.
  Mobile code includes programs transmitted across networks and executed remotely, such as Java applets, JavaScript, and HTML5. Implementation guidelines must address both server-side and client-side usage, and may require digital signatures from trusted sources.
• Authoritative name resolution services must provide data origin authentication and integrity verification artifacts, and support verification of chain of trust among parent and child domains using mechanisms like DNSSEC.
  Systems providing name resolution must enable external clients to obtain authentication and integrity assurances. Recursive resolvers must request and verify response integrity from authoritative sources.
• Name and address resolution services must be fault-tolerant with at least two geographically separated authoritative servers and internal/external role separation to process only appropriate client requests.
  Primary and secondary servers should be deployed in separate network subnetworks. DNS servers with internal roles only process requests from internal clients; those with external roles only process external requests.
• Session authenticity must be protected at the session level to establish confidence in party identities and transmitted information validity, preventing man-in-the-middle attacks and session hijacking.
  Session identifiers must be invalidated at logout. System-generated session identifiers should incorporate randomness requirements. Only approved certificate authorities should be used for establishing protected sessions.
• Systems must fail to a defined known state in the event of operational failure of boundary protection devices while preserving critical system state information to maintain security properties.
  Failures of boundary protection devices must not cause external information to enter protected systems or permit unauthorized information release. Managed interfaces should prevent unsecure failure states.
• System components must employ minimal functionality and information storage to reduce the attack surface and exposure of information, systems, and services to attacks.
  Thin nodes and diskless technologies with minimal functionality reduce the need to secure every endpoint. This approach limits potential compromise impact on organizational operations.
• Decoy system components must be included to attract, detect, deflect, and analyze malicious attacks, with isolation measures ensuring deflected malicious code does not infect operational systems.
  Honeypots, honeynets, and deception nets deflect attacks away from systems supporting organizational functions. Virtualization techniques provide suitable isolation. General Counsel consultation may be needed before deployment.
• Platform-independent applications must be included in organizational systems to promote portability and reconstitution on different platforms, increasing availability when specific operating systems are under attack.
  Platforms are hardware, firmware, and software combinations. Platform-independent applications can execute on multiple platforms, supporting business continuity and mission-essential function availability.
• Information at rest must have confidentiality and/or integrity protected through mechanisms such as cryptographic protection, offline storage, or write-once-read-many technologies appropriate to the information sensitivity.
  Information at rest includes data on storage devices, databases, and system components not in process or transit. System-related information requiring protection includes firewall rules, authentication information, and configurations. When adequate protection is not feasible, organizations may employ frequent scanning or offline storage.
• A diverse set of information technologies must be employed for defined system components to protect against common mode failures, supply chain attacks, and to increase adversary work factor.
  Diversity reduces the likelihood that attack means effective against one component will succeed against others. Virtualization techniques can support changing operating systems and applications at defined frequencies, though this adds management complexity.
• Concealment and misdirection techniques must be employed at defined time periods to confuse and mislead adversaries, potentially reducing attack targeting capabilities through virtualization, randomness, and uncertainty.
  Techniques include randomizing routine actions, changing processing and storage locations, employing different technologies and suppliers, and rotating personnel roles. Misleading information about security posture can be placed in system components known to be targeted.
• Covert channel analysis must be performed to identify potential storage and timing channels within system communications, estimating maximum bandwidth and testing exploitability when appropriate.
  Analysis is most meaningful when unauthorized information flows across security domains exist, such as in systems with export-controlled information connected to external networks. Complete elimination of covert channels is often impossible without significant performance impacts.
• Systems must be partitioned into defined components residing in separate physical or logical domains based on circumstances such as security categorization, with managed interfaces controlling access among partitions.
  Physical separation options include separate racks, separate rooms, or geographical separation of critical components. Partitioning is part of defense-in-depth strategy and prevents single points of failure.
• Operating environments and defined applications must load and execute from hardware-enforced, read-only media to ensure software integrity from creation of the read-only image.
  Hardware-enforced read-only media include CD-R and DVD-R drives or one-time programmable read-only memory. Reprogrammable read-only memory may be acceptable if integrity is adequately protected from initial writing through system insertion.
• System components must proactively seek to identify network-based malicious code and malicious websites, with isolation measures ensuring discovered malicious code does not infect organizational systems.
  This differs from decoys in that components actively probe networks including the Internet. Virtualization is a common isolation technique to prevent infection from discovered malicious code.
• Processing and storage components must be distributed across multiple physical locations or logical domains to provide redundancy and overlap, increasing adversary work factor to impact organizational operations.
  Distributed processing and storage do not assume a single primary location, allowing parallel processing. Polling techniques identify potential faults, errors, or compromises; synchronization ensures distributed components remain consistent.
• Out-of-band channels must be employed for physical delivery or electronic transmission of defined information, components, or devices to avoid vulnerabilities of in-band channels used for operational traffic.
  Out-of-band channels include local non-network access, physically separate network paths, or non-electronic delivery such as postal service. They are used for authenticators, credentials, cryptographic key information, backups, configuration changes, and security updates.
• Operations security controls must be employed throughout the system development life cycle to protect key organizational information by identifying and protecting unclassified information related to planning and execution of sensitive activities.
  OPSEC is a systematic process involving identification of critical information, threat analysis, vulnerability analysis, risk assessment, and countermeasure application. Controls protect confidentiality and limit sharing with external parties.
• Separate execution domains must be maintained for each executing system process by assigning separate address spaces, preventing one process from modifying another's code and controlling inter-process communication.
  Separate execution domains can be achieved through separate address spaces, sandboxing, or virtualization. Process isolation limits access of potentially untrusted software to other system resources.
• External and internal wireless links must be protected from defined signal parameter attacks through cryptographic mechanisms achieving specified protection levels against electromagnetic interference, detection, and deception.
  Wireless link protection reduces impact of attacks unique to wireless systems. Cryptographic mechanisms prevent prediction of spread spectrum waveforms by unauthorized individuals.
• Connection ports and input/output devices must be physically disabled or removed from defined systems or components to prevent exfiltration of information and introduction of malicious code.
  Targeted ports include USB, Thunderbolt, and Firewire. I/O devices include CD and DVD drives. Physical disabling or removal is stronger than logical disabling.
• Environmental sensing capabilities on mobile devices must be prohibited in defined facilities or areas, with remote activation restricted to defined exceptions and explicit user indication of sensor use provided.
  Mobile device sensors include microphones, cameras, GPS, and accelerometers. Organizations may prohibit cellular phones and digital cameras in areas storing classified information or where sensitive conversations occur.
• Usage restrictions and implementation guidelines must be established for defined system components, and their use must be authorized, monitored, and controlled within systems.
  Usage restrictions apply to mobile code, mobile devices, wireless access, and peripheral components. Restrictions are based on potential for components to cause system damage.
• Detonation chambers or dynamic execution environments must be employed to safely open email attachments, execute untrusted applications, and resolve URLs in isolated virtual sandboxes.
  Detonation chambers quickly identify malicious code to prevent propagation to user environments. They differ from deception nets in being temporary rather than long-term adversary operating environments.
• System clocks must be synchronized within and between systems and components, essential for proper execution of identification, authentication, and access control processes involving time-based restrictions.
  Time is expressed in UTC or local time with UTC offset. Synchronization with authoritative sources at defined frequencies prevents denial of service and credential expiration failures. Secondary geographic sources provide redundancy.
• A policy enforcement mechanism must be implemented physically or logically between interfaces connecting security domains, avoiding logical bypass paths and preventing logical covert channels.
  Physical policy enforcement robustness may be needed to preclude logical covert channels penetrating domain boundaries. Organizations should contact NSA for guidance on cross-domain policy enforcement implementation.
• Alternate communications paths must be established for system operations and organizational command and control to ensure continuity during incident-related disruption of primary paths.
  Alternate paths reduce risk of all communications being affected by the same incident. Designating alternative decision makers with defined authority limits can facilitate timely organizational response to incidents.
• Sensors and monitoring capabilities must be relocated to defined locations under specified conditions to impede adversaries' lateral movement through systems and confuse attack path prediction.
  Relocation may be based on acquired threat information or performed randomly. Dynamic relocation of sensors under specified conditions increases adversary work factor to reach targets or exfiltrate information.
• Hardware-enforced separation and policy enforcement mechanisms must be implemented between defined security domains for applications requiring greater strength of mechanism than software enforcement.
  Hardware-enforced mechanisms provide greater assurance and robustness for domain separation and policy enforcement in specific threat environments and operational contexts.
• Software-enforced separation and policy enforcement mechanisms must be implemented between defined security domains where hardware enforcement is not required.
  Software-enforced mechanisms provide separation and policy enforcement while potentially offering less strength than hardware mechanisms but greater flexibility.
• Hardware-based write-protect must be employed for defined system firmware components, with authorized procedures enabling manual disable for firmware modifications and re-enable prior to operational return.
  Hardware write-protection prevents unauthorized firmware modification. Specific procedures for authorized individuals control the enable/disable cycle for maintenance activities.
• Resource availability must be protected by allocating defined resources through priority, quota, or other controls to prevent lower-priority processes from delaying or interfering with higher-priority services.
  Priority protection prevents service disruption from lower-priority activities. Quotas prevent users or processes from consuming more than predetermined amounts of shared resources.
• System management functionality must prevent presentation of management options to non-privileged user interfaces, with such options only available to users with appropriate administrative privileges.
  Preventing grey-out options ensures administration features are completely hidden rather than merely disabled. One approach is withholding administrator options until users establish administrative sessions.

Source: Section 3.18, pages 319-358

• System and information integrity policy and procedures must be developed, documented, and disseminated to defined personnel or roles at appropriate organizational levels.
  Policies address purpose, scope, roles, responsibilities, management commitment, coordination, and compliance with applicable laws and regulations. Procedures facilitate implementation of controls. Security and privacy programs should collaborate on policy development.
• Organizations must identify, report, and correct system flaws, including testing updates for effectiveness before installation and incorporating remediation into configuration management.
  Security-relevant updates include patches and malicious code signatures. Update timelines vary based on system criticality, vulnerability severity, and risk tolerance. Testing may not always be practical, such as for malicious code signature updates.
• Malicious code protection requires implementing signature-based and non-signature-based detection mechanisms at system entry and exit points to detect and eradicate malicious code.
  Non-signature-based detection uses heuristics and artificial intelligence for polymorphic malicious code. Mechanisms must automatically update, perform periodic and real-time scans, and handle false positives appropriately.
• System monitoring must detect attacks, unauthorized connections, and anomalies through strategically deployed monitoring devices that provide real-time or periodic analysis of events.
  Monitoring includes external and internal observation of system events. Devices are placed at perimeter locations and near critical servers. Legal opinions must be obtained regarding monitoring activities, and monitoring information is provided to designated personnel as needed or at defined frequencies.
• Organizations must receive and implement security alerts, advisories, and directives from external organizations on an ongoing basis and generate internal alerts as necessary.
  External sources include CISA, OMB, and supply chain partners. Compliance with directives is essential due to potential immediate adverse effects. Alerts must be disseminated and implemented within established timeframes.
• Security and privacy function verification must test correct operation of designated functions at transitional states or specified frequencies, with alerts to personnel and system shutdown or restart upon failure.
  Transitional states include startup, restart, shutdown, and abort. Privacy function verification ensures privacy functions operate as approved by the senior agency official for privacy.
• Software, firmware, and information integrity must be verified using integrity verification tools to detect unauthorized changes, with defined actions taken when violations are detected.
  Integrity checks include parity checks, cyclical redundancy checks, and cryptographic hashes. Checks can occur at startup, transitional states, security-relevant events, or defined frequencies. Cryptographic mechanisms provide detection of unauthorized modifications.
• Information input validation must check the validity of specified system inputs to prevent attacks such as cross-site scripting and injection attacks by verifying syntax, semantics, character set, length, and acceptable values.
  Valid inputs are defined per field; invalid inputs are rejected. Input validation prevents attackers from inserting malicious commands or special characters into structured messages.
• Error messages must provide information necessary for corrective actions without revealing exploitable information such as stack traces, implementation details, or personally identifiable information.
  Error messages are revealed only to designated personnel or roles. Organizations must consider message structure and content based on policy and operational requirements.
• Information management and retention must comply with applicable laws, executive orders, directives, regulations, policies, and operational requirements throughout the full information life cycle.
  NARA provides federal policy on records retention. Retention requirements cover information created, collected, used, processed, stored, maintained, disseminated, disclosed, and disposed. Control implementation records must be managed and retained as required.
• Mean time to failure (MTTF) must be determined for security-relevant system components, with substitute components and exchange means provided based on organizational criteria.
  MTTF addresses potential failures of security components. Failure rates reflect installation-specific considerations. Transfer of responsibilities between active and standby components must not compromise safety or security capabilities.
• Non-persistent system components and services must be initiated in a known state and terminated at the end of session or at defined frequencies to mitigate advanced persistent threats.
  Non-persistence reduces attack surface and window of opportunity for adversaries. Components are refreshed, reimaged, or implemented using virtualization techniques. Refreshes occur with sufficient frequency to prevent attack spread without causing system instability.
• Information output filtering must validate software program and application output to ensure consistency with expected content and detect anomalous behavior from attacks like SQL injections.
  Filtering detects extraneous content, prevents display of such content, and alerts monitoring tools to anomalous behavior.
• Memory protection controls must prevent unauthorized code execution in non-executable memory regions through mechanisms such as data execution prevention and address space layout randomization.
  Hardware-enforced controls provide greater strength than software-enforced controls. These defenses protect against adversary attacks targeting non-executable memory regions.
• Fail-safe procedures must be defined for specified failure conditions such as loss of communications among critical system components, with procedures including alerts and instructions for subsequent actions.
  Fail-safe procedures may involve alerting operators, doing nothing, reestablishing settings, shutting down processes, restarting the system, or contacting designated personnel.
• Personally identifiable information quality operations must check accuracy, relevance, timeliness, and completeness throughout the information life cycle and correct or delete inaccurate or outdated information.
  Quality operations include editing, validating, and tracking updates to data. Measures are based on the nature, context, and intended use of the information. More comprehensive validation applies to information affecting individual rights and benefits.
• De-identification must remove defined personally identifiable information elements from datasets and evaluate effectiveness of de-identification at specified frequencies to manage re-identification risk.
  De-identification methods include removal, masking, encryption, hashing, or replacement of direct identifiers. Re-identification remains a residual risk requiring ongoing evaluation as data analytics improve.
• Data tainting embeds false data or steganographic data in systems to detect if organizational data has been exfiltrated or improperly removed by unauthorized entities.
  Tainting ranges from passive approaches like false email addresses to active approaches embedding software that alerts the organization to capture and location. This enables detection of compromises and data breaches.
• Information refresh must occur at defined frequencies or be generated on demand and deleted when no longer needed to reduce its value as a target for adversaries.
  Keeping information available for the minimum necessary period reduces opportunity for compromise, capture, and exfiltration by reducing retention risk.
• Information diversity requires identifying alternative sources of information for essential functions and using alternate sources when primary sources become corrupted or unavailable.
  Alternative information sources may be less precise or accurate than primary sources but provide sufficient quality to enable continued operation in degraded form.
• Information fragmentation distributes sensitive information across multiple systems or system components to increase adversary work factor and increase probability of detection during exfiltration attempts.
  Fragmentation extent is dictated by information value, threat intelligence, and whether data tainting is used. Fragmentation impacts timely access to information by the organization.

Source: Section 3.19 (pages 359-389)

• Organizations must develop, document, and disseminate supply chain risk management policy and procedures at organization, mission/business process, or system level, addressing purpose, scope, roles, responsibilities, and compliance.
  The policy and procedures should be consistent with applicable laws and regulations. Security and privacy programs must collaborate on development. Policies at the organization level are preferable and may eliminate the need for mission- or system-specific policies. Events triggering updates include assessment findings, security incidents, or changes in applicable regulations.
• A supply chain risk management plan must address the full lifecycle from research and development through disposal, including threat and risk assessment, mitigation strategies, monitoring approaches, and roles and responsibilities.
  The SCRM plan is implementation-specific and tailored to individual program, organizational, and operational contexts. It documents policy implementation, requirements, constraints, and implications. It can be standalone or incorporated into system security and privacy plans and should address requirements for trustworthy, secure, and resilient system components.
• Organizations must establish a dedicated supply chain risk management team with diverse roles including risk executive, IT, contracting, security, privacy, mission/business, legal, supply chain, and acquisition personnel to lead and support SCRM activities.
  The team approach enables coordinated analysis of supply chains, communication with internal and external partners, and consensus on resource allocation. Team members collectively provide expertise in acquisition processes, vulnerabilities, threats, attack vectors, and technical system dependencies.
• Organizations must identify and address weaknesses in supply chain elements and processes through established processes coordinated with supply chain personnel, and document selected controls in security and privacy plans or SCRM plans.
  Supply chain elements include organizations, entities, or tools used for research, development, design, manufacturing, acquisition, delivery, integration, operations, maintenance, and disposal of systems. Supply chain processes include hardware, software, firmware development, shipping, personnel security, and configuration management. Weaknesses represent vulnerabilities that adversaries can exploit.
• Provenance documentation must track the chronology of origin, development, ownership, location, changes, and associated personnel for systems and critical components throughout their lifecycle.
  Provenance includes methods to document and monitor valid provenance baselines, prevent unauthorized changes to provenance records, and ensure non-repudiation. Organizations should establish unique identification of supply chain elements, processes, and personnel; track and trace systems through the supply chain; and validate that components received are genuine and unaltered.
• Organizations must employ acquisition strategies, contract tools, and procurement methods such as obscuring end use, blind or filtered buys, tamper-evident packaging, and trusted distribution to protect against supply chain risks.
  Tools and techniques protect against unauthorized production, theft, tampering, counterfeits, malicious software insertion, and poor development practices. Organizations should incentivize suppliers implementing controls, promote transparency, include contract language prohibiting tainted components, and provide personnel training on supply chain risk mitigation.
• Suppliers and contractors must be assessed and reviewed at organization-defined frequencies for supply chain-related risks, including their security processes, foreign ownership or control, and ability to assess subordinate suppliers.
  Assessments can be conducted by the organization or independent third parties and should consider documented processes, controls, intelligence, and publicly available information. Organizations can use open-source information to monitor for stolen information, poor quality practices, information spillage, and counterfeits.
• Organizations must employ Operations Security (OPSEC) controls to protect supply chain-related information including user identities, system uses, supplier identities, requirements, configurations, and design specifications.
  Supply chain OPSEC expands traditional OPSEC to include suppliers and potential suppliers. It requires identifying critical information, analyzing friendly actions to identify observable elements, determining adversary indicators, and implementing countermeasures. Organizations may need to withhold mission information from suppliers or use intermediaries to hide end use.
• Agreements and procedures must be established with supply chain entities for notification of compromises, assessment and audit results, and other organization-defined information to facilitate timely response to incidents.
  Early notification of supply chain compromises or potential compromises that could affect organizational systems is essential for effective incident response. Results from assessments and audits can help supply chain entities resolve concerns and improve their processes.
• Anti-tamper technologies, tools, and techniques must be implemented throughout the system development lifecycle to protect systems and components against reverse engineering, modification, and substitution.
  Strong identification combined with tamper resistance and detection is essential during distribution and in-use phases. Organizations use hardware and software techniques including obfuscation, self-checking, and customization to make tampering more difficult and costly for adversaries.
• Systems or system components must be inspected at random or defined frequencies to detect tampering, with indications of need including changes in packaging, specifications, factory location, or purchase entity.
  Inspection addresses both physical and logical tampering and applies to systems removed from organization-controlled areas. Indications triggering inspection include changes in supply sources or when personnel return from high-risk travel locations.
• Anti-counterfeit policy and procedures must be developed and implemented to detect and prevent counterfeit components from entering systems, with procedures for reporting counterfeits to sources or external organizations.
  Counterfeit components can originate from manufacturers, developers, vendors, and contractors. Anti-counterfeiting policies support tamper resistance and prevent introduction of malicious code. Personnel should be trained to detect counterfeits in hardware, software, and firmware, and organizations should conduct periodic anti-counterfeit scanning.
• Data, documentation, tools, and system components must be disposed of using organization-defined techniques and methods at any point in the system development lifecycle to prevent compromise and unauthorized reuse.
  Disposal opportunities occur during research, development, design, prototyping, or operations/maintenance phases. Methods include disk cleaning, removal of cryptographic keys, and partial component reuse. Proper disposal prevents sensitive components and information from entering secondary markets.
• Supply chain controls must be flowed down from prime contractors to subcontractors at all tiers to ensure consistent supply chain risk management across the entire supply chain.
  Tier 1 prime contractors must implement processes facilitating the flow down of supply chain risk management controls to sub-tier contractors. This ensures holistic and effective supply chain risk management across all levels of the supply chain.

Source: Section 3.20, Supply Chain Risk Management, pages 390-400

• NIST SP 800-53 Rev. 5 references external publications that directly support FISMA and Privacy Projects, with additional standards and guidelines cited throughout the control sections in Chapter Three.
  The references section lists laws, executive orders, regulations, standards, and guidelines organized by category. Direct links to NIST publications are provided for access, and the document is available free of charge from https://doi.org/10.6028/NIST.SP.800-53r5.
• Key legislative foundations include FISMA (Federal Information Security Modernization Act), the Privacy Act, FOIA, and the E-Government Act, which establish legal requirements for federal information security and privacy protection.
  These acts form the statutory basis requiring federal agencies to implement security controls and protect personally identifiable information. FISMA in particular mandates agencies use NIST standards for information security.
• Executive Orders on classified information, cybersecurity, and supply chain security provide presidential direction on federal security practices and critical infrastructure protection.
  Orders cover classified information handling, controlled unclassified information, critical infrastructure cybersecurity, and information and communications technology supply chain security.
• OMB memoranda provide implementation guidance on privacy provisions, trusted internet connections, breach response, and cybersecurity enhancement for federal agencies.
  These memoranda translate statutory requirements and executive orders into specific operational directives for federal agencies regarding information management and incident response.
• ISO and IEC standards referenced cover systems and software assurance, IT security evaluation, key management, privacy frameworks, and supply chain risk management.
  International standards provide globally recognized best practices for cryptography, authentication, access control, and lifecycle processes that align with NIST control requirements.
• NIST FIPS publications establish federal requirements for cryptographic algorithms, security categorization, and personal identity verification.
  FIPS standards including FIPS 197 (AES), FIPS 199 (categorization), FIPS 200 (minimum requirements), and FIPS 201-2 (PIV) are mandatory for federal systems.
• Extensive NIST Special Publications provide detailed guidance on specific security domains including access control, incident response, cryptography, and continuous monitoring.
  SP publications numbered 800-12 through 800-192 cover implementation approaches for controls across access control, authentication, audit, assessment, configuration management, contingency planning, and other domains.
• NIST Interagency Reports document emerging topics and provide research-based guidance on smart cards, attack graphs, cloud cryptography, automation for assessments, and supply chain risk analysis.
  IRs offer deeper technical analysis and novel approaches to security challenges, supplementing the foundational guidance in main NIST publications.
• Supporting resources include the Federal PKI infrastructure, the NIST Cybersecurity Framework, Privacy Framework, National Checklist Program, and the National Vulnerability Database tied to SP 800-53 controls.
  These tools and repositories help organizations implement, assess, and maintain compliance with NIST controls through standardized configuration guidance and vulnerability tracking.

Source: Pages 401-420, REFERENCES section

• Access control is the process of granting or denying requests for information and physical facility access based on authorization decisions.
  It applies to both information systems and physical facilities like Federal buildings and military establishments, controlling who can obtain and use resources.
• Adequate security means applying cost-effective security controls that provide appropriate confidentiality, integrity, and availability protections proportionate to the risk of unauthorized access, use, disclosure, disruption, modification, or destruction of information.
  Adequacy is determined by risk assessment and the need to ensure information systems operate effectively with proper protections.
• An advanced persistent threat is a sophisticated adversary with significant resources that pursues objectives repeatedly over extended periods, adapts to defender resistance, and may use cyber, physical, or deception attack vectors.
  These threats typically aim to establish footholds in IT infrastructure for exfiltration, mission disruption, or future attack positioning.
• Authentication verifies the identity of a user, process, or device, typically as a prerequisite to granting access to system resources.
  This foundational security function ensures that only legitimate entities can access protected systems and information.
• An authenticator is something the claimant possesses and controls, such as a cryptographic module or password, used to prove identity.
  Authenticators serve as the mechanism for demonstrating that a user actually is who they claim to be during authentication.
• Authorization grants access privileges to users, programs, or processes, establishing what actions and resources are permitted.
  Authorization defines the scope of what an authenticated user or system may do within an organization's systems.
• Authorization to operate is the official decision by a senior Federal official to allow a system to run while explicitly accepting the associated risk to agency operations, assets, individuals, and the Nation.
  This decision is based on implementation of an agreed-upon set of security and privacy controls and applies to both system-specific and inherited common controls.
• An authorization boundary includes all components of an information system to be authorized for operation but excludes separately authorized systems connected to it.
  This boundary defines the scope of what is covered by a single authorization decision.
• Availability ensures timely and reliable access to and use of information.
  It is one of the three primary security objectives, alongside confidentiality and integrity.
• A control baseline is a predefined set of controls assembled to address protection needs of specific groups, organizations, or communities of interest.
  Baselines serve as starting points for tailoring controls to match organizational risk profiles and requirements.
• Control effectiveness measures whether a security or privacy control contributes to reduction of information security or privacy risk.
  Assessment of effectiveness determines whether controls are operating as intended and producing desired outcomes.
• Control inheritance occurs when a system receives protection from security controls developed, implemented, and monitored by entities other than those responsible for the system itself.
  Inheritance can come from internal or external sources and is also known as receiving common controls.
• Confidentiality preserves authorized restrictions on information access and disclosure, including protection of personal privacy and proprietary information.
  It is one of the three primary security objectives and requires preventing unauthorized revelation of sensitive data.
• Configuration management is a collection of activities that establish and maintain integrity of IT products and systems through control of processes for initializing, changing, and monitoring configurations throughout the system life cycle.
  Configuration control protects systems against improper modifications before, during, and after implementation.
• Continuous monitoring maintains ongoing awareness to support organizational risk decisions about information systems.
  It enables organizations to track security posture and compliance status over time rather than only at assessment points.
• Controlled unclassified information is information the government creates or possesses that regulations require or permit safeguarding or dissemination controls, but exclude classified information.
  CUI is subject to special handling and protection requirements defined by law and government-wide policy.
• Countermeasures are actions, devices, procedures, or techniques that reduce system vulnerability and are synonymous with security controls and safeguards.
  Countermeasures form the defensive measures that organizations implement to protect against identified threats.
• A covert channel is an unintended or unauthorized intra-system channel that enables entities to transfer information in violation of the security policy without exceeding access authorizations.
  Covert channels represent a subtle security risk where information flows bypass normal security mechanisms.
• Cybersecurity involves prevention of damage to and protection and restoration of computers, electronic systems, and information to ensure availability, integrity, authentication, confidentiality, and nonrepudiation.
  It encompasses defensive and recovery measures across the full spectrum of electronic systems and communications.
• De-identification is any process of removing the association between identifying data and the data subject.
  It is a privacy protection technique that reduces personal privacy risks by breaking the link between data and individuals.
• Defense in depth is an information security strategy that integrates people, technology, and operations capabilities to establish multiple barriers across organizational layers and missions.
  This layered approach provides redundant protections so that failure of one control does not compromise security.
• Discretionary access control allows subjects granted access to information to pass it to others, grant privileges, or change security attributes unless restricted by mandatory controls.
  In discretionary systems, data owners have significant control over how access is delegated.
• An information system is a discrete set of information resources organized for collection, processing, maintenance, use, sharing, dissemination, or disposition of information.
  Systems are the primary assets that security and privacy controls protect.
• Integrity guards against improper information modification or destruction and ensures information non-repudiation and authenticity.
  It is one of the three primary security objectives and requires assurance that information has not been altered.
• Mandatory access control is uniformly enforced across all subjects and objects, preventing subjects from passing information to unauthorized parties, granting privileges, or changing security attributes unless explicitly trusted.
  Mandatory controls provide stronger restrictions than discretionary controls and are used in high-security environments.
• Multi-factor authentication requires more than one authentication factor for successful authentication, using either a single authenticator providing multiple factors or multiple authenticators providing different factors.
  The three authentication factors are something you know, something you have, and something you are.
• A personally identifiable information processing operation includes collection, retention, logging, generation, transformation, use, disclosure, transfer, and disposal of personally identifiable information.
  Understanding PII processing is essential for privacy control implementation and compliance.
• Personally identifiable information is information that can distinguish or trace an individual's identity either alone or when combined with other linked or linkable information.
  PII identification is foundational to applying privacy protections and requirements.
• Risk is a measure of the extent to which an entity is threatened by a potential circumstance or event, typically a function of adverse impact and likelihood of occurrence.
  Risk assessment identifies and quantifies threats and vulnerabilities to inform control decisions.
• Risk management includes threat and vulnerability analyses and mitigations through security and privacy controls, and is synonymous with risk analysis.
  Comprehensive risk management is the process that drives security and privacy control selection.
• Tailoring is the process of modifying security control baselines by identifying common controls, applying scoping considerations, selecting compensating controls, and assigning values to control parameters.
  Tailoring allows organizations to adapt baseline controls to their specific operational and environmental contexts.
• Threat is any circumstance or event with potential to adversely impact organizational operations, assets, individuals, or the Nation through unauthorized access, destruction, disclosure, modification, or denial of service.
  Threat identification is the first step in risk assessment and security planning.
• Trustworthiness in systems is the degree to which an information system can preserve confidentiality, integrity, and availability of information across the full range of threats despite disruptions and attacks.
  Trustworthy systems operate within defined risk levels and maintain essential functionality under adverse conditions.
• A vulnerability is a weakness in an information system, security procedures, controls, or implementation that could be exploited or triggered by a threat source.
  Vulnerability assessment identifies weaknesses that threats could potentially leverage to cause harm.

Source: Appendix A - Glossary, pages 421-450

• NIST SP 800-53 uses numerous technical and organizational acronyms that must be understood to interpret security and privacy controls.
  The acronyms section provides standardized abbreviations for common technologies, government agencies, standards, and security concepts referenced throughout the document. Familiarity with these terms is essential for practitioners implementing or assessing controls.
• Security-specific acronyms include control frameworks (ABAC, RBAC, PKI), vulnerability management tools (CVE, CVSS, CWE), and incident response mechanisms (CIRT, IOC, SIEM).
  These acronyms represent key concepts in access control, vulnerability identification, and security monitoring that are central to the controls framework described in the publication.
• Government and regulatory acronyms such as FISMA, FIPS, OMB, and DoD establish the policy and compliance context for security control implementation.
  These represent the legislative, regulatory, and organizational authorities that mandate or guide the adoption of NIST SP 800-53 controls in federal and defense systems.
• Network and communications acronyms (TCP/IP, DNS, VPN, TLS) represent fundamental protocols and technologies underlying secure information system architecture.
  Understanding these technical terms is necessary to properly implement and assess controls related to system and communications protection.

Source: Pages 451-454 (Appendix B - Acronyms)

• Control summaries in Tables C-1 through C-20 organize all security and privacy controls by family, with designations for withdrawal status, implementation approach, and assurance contribution.
  A withdrawn control is marked with 'W' and explanation. Controls are marked 'S' if implemented by information systems via technical means, 'O' if by organizations through nontechnical means, and 'O/S' if by either or both. A check mark indicates the control contributes to grounds for confidence that security or privacy claims have been or will be achieved.
• Control enhancements add functionality, specificity, or strength to base controls and are always used together with their base control.
  Enhancements are employed in systems requiring greater protection due to potential adverse impacts or organizational risk assessments. The use of any control enhancement requires concurrent use of the base control.
• Families are arranged alphabetically while controls within families are arranged numerically, but this ordering does not imply prioritization, importance, or implementation sequence.
  Organizations retain flexibility to implement selected controls and enhancements in the most cost-effective and efficient manner while complying with control intent.
• Organizations may implement controls through systems, organizations, or combinations of both, despite notional 'S' or 'O' designations in the tables.
  Actual implementation approach depends on organizational circumstances, cost-effectiveness considerations, and efficiency requirements while maintaining control intent compliance.
• Assurance measures confidence that security and privacy functions, features, practices, policies, procedures, mechanisms, and architecture accurately enforce established security and privacy policies.
  Controls marked with assurance indicators contribute to trustworthiness of systems by demonstrating that established policies are genuinely mediated and enforced.

Source: Pages 455-492, Control Summaries