System configuration management
(CT:IM-344; 06-24-2025)
(Office of Origin: DT/ES)
5 FAM 861 SUMMARY
(CT:IM-344; 06-24-2025)
This subchapter pertains to Enterprise Configuration Management and Change Control requirements, which make up the Technology Review Board (TRB). It describes requirements related to Department-funded custom-developed source code and ensures such code is designed, developed, and documented with process ownership rights. This is sufficient to enable government-wide access to, sharing of, use of, and modification of any custom-developed code created in the development of such software, in accordance with the "Source code Harmonization and Reuse in Information Technology Act" or the "SHARE IT Act".
5 FAM 862 overall department policy
(CT:IM-344; 06-24-2025)
a. Configuration management (CM) is the detailed recording and updating of Department information systems and networks, including all hardware and software components, also called the “baseline.” Configuration management details versions and updates applied to installed software packages and the locations and network addresses of hardware devices, collectively known as Configuration Items. When a system undergoes changes to the baseline, i.e. hardware or software upgrade, the system manager is required to update the configuration management database (CMDB).
b. Developers use configuration management in software development to help keep track of the source code, documentation, problems, and changes requested and implemented. The developed code is maintained in a repository.
c. Configuration management ensures that an information system in the operational/maintenance phase of its lifecycle is correctly configured. Any changes made are reviewed for security implications by the Cyber Operations (DT/CO) reviewer and the appropriate Bureau of Diplomatic Security (DS) reviewer before implementation. Configuration management guarantees that changes occur in a controlled and identifiable manner and have been tested to prevent adverse effects on the system’s functionality, including its security posture and that of any connected Department information systems. Ongoing configuration monitoring is required to detect unauthorized changes or deviations from approved baselines.
d. System manager will consult the IT catalog for approved hardware and software or use the TRB to obtain approval for hardware of software (IT products) not currently approved, once approved all IT products are added to the IT catalog. All IT catalog approved products should be configured with the appropriate Department guidelines.
e. Diplomatic Technology Officers (DTOs), information security officers (ISOs), information system security officers, and system administrators must develop and maintain Department configuration management plans on all Department information systems and the networks under their management authority, as part of a system’s security documentation required to undergo certification and accreditation.
5 FAM 862.1 Standard Operating Environments
(CT:IM-344; 06-24-2025)
a. A Standard Operating Environment (SOE) is a version-controlled specification for using a standard architecture and applications within a Department information system.
b. An SOE supports development of strong configuration management plans for common computing environments commonly used throughout the Department.
c. An SOE is a documented subset of the overall DT approved IT hardware and IT software approved for Department use, for example, the SOE for desktops or servers.
d. Use of an SOE ensures that the following goals are met:
(1) Efficiently and effectively maintain the components of an SOE. The Department authorizes only IT catalog approved products. Regular review by system change management personnel ensures that the SOE is regularly updated. Publishing via IT catalog, the DT TRB ensures that current and future forms of the SOE are effectively communicated throughout the Department;
(2) All components of an SOE are expected to have a standard lifecycle, which consists of implementation, maintenance, and ultimate disposal and removal. Only current Department supported or approved vendor versions of SOE components can exist within the Department;
(3) The TRB must review and approve new IT products for use within an SOE. System level change management personnel do not have approval authority for approving new versions of SOE components;
(4) Ensure that all SOE components previously approved by the TRB are compatible with new SOE components. System manager must upgrade or remove previous DT approved IT hardware and IT software that is not compatible with new SOE components as directed by the Office of the Chief Architect (DT/OCA);
(5) The configuration of the SOE must comply with appropriate Department information security and configuration standards. (See 12 FAH-10 H-220 and 12 FAM 630 and the Directorate of Cyber and Technology Security (DS/CTS) IT Security Configuration Standards);
(6) Outline any exclusion to this policy in the DT TRB Standard Operating Procedure (SOP) available on the TRB website; and
(7) In accordance with 5 FAM 915.14, the TRB administers the creation, maintenance, and deactivation of components comprising an SOE. (See the DT TRB SOP)
5 FAM 862.2 Minimum Hardware Specifications
(CT:IM-344; 06-24-2025)
System manager will adequately manage the hardware lifecycle to ensure replacements are planned before the hardware reaches vendor provided end of life and all hardware is covered by a maintenance agreement.
5 FAM 862.3 Example TRB IT Products
(CT:IM-344; 06-24-2025)
a. The Enterprise Technology Review Board (TRB) provides the review process for hardware, software, and cloud products that are not available in the IT catalog before procurement and deployment to all DOS IT Environments; all IT products are reviewed for four (4) key critical factors: Network Compatibility, Cybersecurity, Interoperability, and Standards to ensure quality, integrity, and compliance of technical solutions bult on top of these products.
b. The TRB must approve all wireless equipment. The Department does not authorize local configuration management approval of wireless equipment.
c. The TRB must approve all hardware and software.
d. The TRB must approve all digital senders.
e. The TRB must approve all browsers, or CRT software.
f. The TRB must approve all convergence of network systems (e.g., systems that consolidate voice, video, and/or data onto the same physical network, or Internet-of-Things (IoT)).
g. All updates to the local change control must be immediately communicated to the TRB.
5 FAM 863 sYSTEM Configuration MANAGEMENT
(CT:IM-344; 06-24-2025)
5 FAM 863.1 Local IT Responsibilities
(CT:IM-344; 06-24-2025)
a. A post or bureau that maintains its own IT systems or local IT applications in support of a Department or post must establish formal system level change and configuration management plans in coordination with their Bureau’s Executive Office and IT director who sponsor any technology requests to DT TRB. Such system level change management processes will comply with Federal laws, regulations, and policies, including reporting requirements.
b. Establish a system level change management plan to ensure that the IT hardware, software, or network components installed on a LAN do not adversely affect the existing local IT infrastructure under the operational control of bureau or post IT personnel. The system level change management personnel must also ensure that all IT catalog approved software and hardware functions only inside the post’s supporting LAN or VLAN segment(s).
c. System level change management personnel must ensure that the Department’s Integrated Management, Analytics, and Technology Resource for Information Exchange (iMATRIX) includes current, complete, and accurate data on all general support systems, minor and major applications (see 5 FAH-11 H-014), and other IT resources approved for installation on a Department network; or on IT resources that contain Department data, including websites commissioned on behalf of the Department, bureau, office, division, or post.
d. The system level change management plan must include steps in its process for gaining TRB approvals for IT products, that are not approved in the IT catalog, before procurement and deployment:
(1) Reviewing industry sources to be specified by the Office of Information Assurance (DT/CO) concerning vulnerabilities of those IT resources, and correcting any vulnerabilities that pose a threat to the network or Department data as a condition to approval of the software; and
(2) Deciding whether to request and obtain vulnerability scanning of those IT resources by the Bureau of Diplomatic Security as a condition for approval. Thereafter, the system level change management personal must repeat this review and condition process on a recurring basis, supplemented with data on actual configurations from vulnerability and compliance scanning as technically feasible and justified by the level of acceptance risk
e. The system level change management personnel verifies that the local applications’ administrators promptly review all vulnerability scanning and configuration compliance data about the locally managed IT resources (provided by the DT, DS, and/or other Departmental security authorities) to identify and correct vulnerabilities and configuration compliance issues to a level of risk considered acceptable to the Department.
5 FAM 863.2 System Level IT Memberships
(CT:IM-344; 06-24-2025)
a. The system level CM plans should consist of a local IT chairperson (i.e., the DTO or Bureau IT director) and added members as appropriate.
b. For generic information, see your Bureau’s IT director and the DT TRB website.
5 FAM 864 change control
(CT:IM-344; 06-24-2025)
5 FAM 864.1 Operating System Software Change Control
(CT:IM-344; 06-24-2025)
a. Only use IT catalog approved hardware, software, cloud services to include operating systems on the Department’s classified and unclassified networks.
b. System administrators must request approval from DS/CTS and DT/CO to use a non-TRB-approved operating system. See 12 FAH-10 Information System Security Controls and Procedures Handbook and 12 FAH-10 H-220 Configuration Management and 12 FAM 633 Systems Implementation.
5 FAM 864.2 Application Software and Change Control
(CT:IM-344; 06-24-2025)
a. System owners will implement application software change controls for major and developed applications installed on Department Systems:
(1) Define requirements, including security, in the system development and acquisition stage for system confidentiality and availability as well as integrity of data input, transaction processing, and data output;
(2) Initiate the systems authorization process;
(3) Test the application in a development environment, or test bed, prior to operation to ensure the presence of satisfactory operation of controls (this is usually the certification and authority to operate process);
(4) Monitor security controls for vulnerabilities throughout the deployment, operation, and maintenance stages;
(5) Limit access to software programming libraries in a production environment;
(6) Protect system documentation, as appropriate, with the same due diligence as the data that is protected;
(7) Ensure source code is escrowed in a Department of State owned code repository to ensure software is sustainable over time as contracts/vendors may rotate; and
(8) Operate the TRB approved SOE without negative impact to other SOE components.
b. Each system owner must ensure the integrity of major applications and operating system software by implementing documented and effective configuration management procedures, including procedures to:
(1) Restrict the ability to change software (update, upgrade, install, and uninstall) to only those authorized by the system owner;
(2) Audit all changes and maintain a secure copy of the audit;
(3) Collect and share audit logs with DS/CTS and M-21-31 log requirements;
(4) Maintain a secure copy of changes (old and new software); and
(5) Test all changes on non-live data before deploying changes in a live environment.
c. The system level change control personnel must approve each application, as appropriate, before it is submitted to the TRB or before use. See 5 FAM 862.3 Example TRB IT Products.
d. All government-off-the-shelf (GOTS) or commercial-off-the-shelf (COTS) applications need to be contained in the Integrated Management, Analytics, and Technology Resource for Information Exchange (iMATRIX). Posts and bureaus are responsible for ensuring that any applications they develop or purchase are already present or are added to the iMATRIX. See the iMATRIX website for instructions on adding and/or updating information.
5 FAM 865 COPYRIGHTED SOFTWARE
(CT:IM-344; 06-24-2025)
a. Department employees and contractors may use and distribute commercial software only in accordance with U.S. copyright laws and manufacturer’s licensing agreements. (See 5 FAM 865)
b. The software and Sourcing Management Division (DT/BMP/ITA/SSM) manages the Enterprise Agreements (EAs) for the Department. (See 5 FAM 916.2, paragraph a.)
c. The DTO/ISO/system administrator must install copyrighted software to conform with the Department’s enterprise licensing agreements, or locally approved licensing agreements.
5 FAM 866 PATCH MANAGEMENT
(CT:IM-344; 06-24-2025)
a. The purpose of the Department’s Enterprise Patch Management Program is to protect data confidentiality, integrity, and availability by mitigating software and hardware vulnerabilities through proactive patch management.
b. The Endpoint Engineering Services Division (DT/ES/MCS/EES) manages the Department’s Enterprise Patch Management Program.
c. DTOs/ISOs/system administrators must follow guidelines and procedures established by the Department’s Enterprise Patch Management Program and apply patches in an expeditious manner.
d. The Designated Approval Authority (DAA) must disconnect any system, LAN, or domain that does not comply with the Department’s Enterprise Patch Management Program’s directives.
e. The Enterprise Patch Management Program will only patch the newest versions of approved software products within its scope. Software that is not determined to be enterprise level are not supported by the enterprise management program.
f. All Departmental application owners have the responsibility to address known vulnerabilities for their applications by:
Coordinating with their development or application software vendor teams and getting the source code or patches to address the vulnerabilities;
g. All Departmental application owners and/or developers must designate a person or group to represent their organization in the Patch and Vulnerability Group (PVG). There are two purposes of the PVG:
(1) To champion patch management compliance in their respective organizations; and
(2) To test patches as they are released against their functional applications and provide testing results to the Enterprise Patch Management Program.
5 FAM 867 DOCUMENTATION
(CT:IM-344; 06-24-2025)
System managers/system owners must maintain documentation for all aspects of computer support and operations. This documentation is important to ensure continuity and consistency throughout the Department. Documentation must include:
(1) Current security plans, contingency plans, and risk analyses;
(2) Sufficient documentation to explain how software/hardware is used, including operational procedures;
(3) A current list of workstations (including standalones), printers, servers, and other network peripherals/devices (e.g., scanner), the office in which each is located, the cable number/device serial number, and port in the hub/switch/router where each is located;
(4) A current list of all the software applications used, the names of principal users, and the person/office to contact for operational issues or problems;
(5) An annual IT system performance report (i.e., capacity, availability, integrity, etc.);
(6) A systems operations log. System owners must maintain this log for 6 months. (See 12 FAH-10 H-122.12, Operations Log, or 12 FAM 632.5, Log and Record Keeping);
(7) An annual security self-assessment, in accordance with guidance DT/CO will provide each year;
(8) Audit records on servers and workstations for 6 consecutive months; and
(9) The current configuration management plan for the bureau/post.
5 FAM 868 Enterprise Source Code & Open Source Software
(CT:IM-324; 06-28-2024)
5 FAM 868.1 Solution Architecture
(CT:IM-344; 06-24-2025)
System owners must conduct market research and develop an analysis of alternatives prior to seeking funding and obtaining management approval for a candidate solution. The market research and the subsequent analysis of alternative (AoA) shall include the following solution alternatives, listed in order or priority:
(1) Reuse another Department solution
(2) Shared Federal Service/Solution
(3) FedRAMP certified solution
(4) COTS
(5) Custom developed solution
5 FAM 868.2 Enterprise Source Code Inventory & Inter-Agency Sharing
(CT:IM-344; 06-24-2025)
a. DT/BMP/SPB will direct the Federal Source Code Policy (FSCP) Working Group and maintain the Department’s enterprise code inventory, which catalogs all Department strictly unclassified custom-developed code. The Enterprise Code Inventory is a listing of code products published in accordance with the SHARE IT Act, on the Department’s Intranet site.
b. All strictly unclassified custom-developed code must be listed in the Enterprise Code Inventory:
(1) System owners must provide information for the enterprise code inventory, including all related data elements. Information may be sent to the FSCP Working Group’s email address, SourceCode@state.gov for review and inclusion in the Enterprise Code Inventory; and
(2) System owners must indicate whether the code for each project listed in the inventory is available to other federal agencies, available to the public as OSS and licensed appropriately, or is withheld from sharing due to one of the predefined exception categories in the SHARE IT Act.
c. All custom-developed code developed after the August 8, 2016 publication of OMB M-16-21 must be made available for release to other federal government agencies, unless a specific exemption from sharing is claimed, under a category listing in Section 6 of the OMB M-16-21. System owners must provide a written justification for each exemption claimed in their enterprise code inventory submission to SourceCode@state.gov.
d. Clearance and approval will be coordinated by the system owners, the FSCP Working Group and the Office of Public Affairs. Clearance must be documented before any Department source code can be release as OSS.
5 FAM 868.3 Releasing Custom-Developed Code as Open Source Software for the Public
(CT:IM-344; 06-24-2025)
a. System owners may publish custom-developed code as OSS through the FSCP Working Group, which manages the Intranet-accessible enterprise code repository where the Department’s open-source projects are published. The FSCP Working Group will collaborate with the Office of Public Affairs on maintaining the Internet-accessible venues where other Government and the general public can access Department OSS.
b. An open -source license, based on the Creative Commons License 1.0 Universal and Apache license 2.0, shall be specified and documented for all source code release as OSS by the Government.
c. Clearance and approval must be obtained and documented through the system owner and the FSCP Working Group before any Department source code can be released as OSS.
5 FAM 868.4 SHARE IT Act Responsibilities
(CT:IM-344; 06-24-2025)
a. System Owners/Program/Project Managers (PMs) must:
(1) Ensure that sufficient rights, through contracts, are acquired to enable government-wide access, sharing, use and modification of the code. This includes code produced by federal employees. Consult with L regarding any contractual issues to ensure adequate legal protections are in place; and
(2) Ensure custom code development within their projects complies with source code sharing and associated metadata management practices that are congruent with this policy. Annual reports to the chief information officer (CIO) shall include the following:
(a) The frequency of reuse of the custom-developed code, including access and modification;
(b) Whether the shared custom-developed code is maintained; and
(c) What feedback mechanism is in place for improvements to community development of the shared custom-developed code.
b. CIO is responsible for:
(1) Develop implementation policies and procedures to align with custom-code development with the best practices established by the Director of Office and Management and Budget and standardize reporting that captures key information relating to a contract under which custom-developed source code was produced for reporting statistics about the contract;
(2) Procedures for Federal employees to gain access to repositories containing custom-developed source code; and
(3) A report detailing the custom source code of the department to which any of the exemptions, outlined in the exemption section below, were applied during the fiscal year that ended on September 30 of that year, along with a brief narrative justification of each exemption, must be submitted by the CIO of an agency to the administrator of the Office of Electronic Government.
c. The Department’s acquisition program is responsible for issuing acquisition policies that are updated to ensure contracting officers incorporate language in solicitations and contract documents that are sufficient to obtain appropriate Government data rights to custom-developed code in compliance with the SHARE IT Act.
5 FAM 868.5 Exemptions
(CT:IM-344; 06-24-2025)
Source code developed for National Security Systems (NSS), as defined in 40 U.S.C. § 11103, is exempt from the requirements of this policy. For NSS, agencies shall follow applicable statutes, Executive Orders, directives, and internal agency policies. Exemptions to this policy shall be applied in the following cases when involving the SHARE IT Act:
(1) Classified source code or source code developed primarily for use in a national security system, as defined in section 11103 of title 40, United States Code, or by an agency, or part of an agency, that is an element of the intelligence community (as defined in section 3(4) of the National Security Act of 1947 (50 U.S.C. 3003(4));
(2) Classified source code or source code which is exempt from disclosure under Section 552(b) of title 5, United States Code (commonly known as the Freedom of Information Act);
(3) Export Administration Regulations;
(4) International Traffic in Arms Regulations;
(5) The regulations of the Transportation Security Administration relating to the protection of Sensitive Security Information;
(6) The sharing of the source code would create identifiable risk to the detriment of national security, confidentiality of Government information, or individual privacy;
(7) Federal laws and regulations governing the sharing of classified information not covered by the exemption regarding NSS and the intelligence community;
(8) The sharing or public accessibility of the source code would create an identifiable risk to the privacy of an individual; and
(9) The CIO deems it in the national interest to exempt sharing the Department custom-developed code.
5 FAM 869 REFERENCES
(CT:IM-344; 06-24-2025)
5 FAM 869.1 Acronyms
(CT:IM-344; 06-24-2025)
AO – Authorizing Official
AoA – Analysis of Alternative
ATO – Authorization to Operate
C&A – Certification and Accreditation
CM – Configuration Management
COTS – Commercial Off-the-Shelf
DOS – Department of State
DS – Bureau of Diplomatic Security
DS/CTS – Directorate of Cyber and Technology Security
DT – Bureau of Diplomatic Technology
DTO – Chief Diplomatic Technology Officer
DTO-ITI – Sub-unit Chief for IT Infrastructure
DTO-CE – Sub-unit Chief for Customer Engagement
EA – Enterprise Agreement
FAR – Federal Acquisitions Regulations
FSCP – Federal Source Code Policy
GOTS – Government Off-the-Shelf
IoT – Internet of Things
ISO – Information Security Officer
ISSO – Information Systems Security Officer
OCA – Office of the Chief Architect (DT/OCA)
OMB – Office of Management and Budget
OSS – Open-Source Software
OT – Operational Technology
SOE – Standard Operating Environment
SOP – Standard Operating Procedure
TRB – Technology Review Board
5 FAM 869.2 Definitions
(CT:IM-344; 06-24-2025)
Patch management — Is the subset of systems management that involves identifying, acquiring, testing and installing patches, or code changes, that are intended to fix bugs, close security holes or add features
Custom-developed software code – Produced in the performance of a federal contract or is otherwise fully funded by the Federal Government, including code, or segregable portions of code, for which the Government could obtain unlimited rights under Federal Acquisition Regulation (FAR) Pt. 27 and relevant agency FAR Supplements. Custom-developed code also includes code developed by agency employees as part of their official duties. For the purposes of this policy, custom-developed code may include, but not limited to, code written for software projects, modules, plugins, scripts, middleware, and APIs; it does not, however, include code that is truly exploratory or disposable in nature, such as that written by a developer experimenting with a new language or library.
Configuration Management Database – A centralized repository that stores information about the components (hardware, software, etc.) that make up an organization’s IT infrastructure and how they are related. It’s the system of record that services as a detailed inventory of an organization’s IT assets, serving as a “single source of truth” for IT service management and other related processes.
5 FAM 869.3 Authorities
(CT:IM-344; 06-24-2025)
The authorities for this policy include:
(1) NIST SP 800-128 (Guide for Security-Focused Configuration Management of Information Systems)
(2) Federal Information Security Modernization Act (FISMA) of 2014 (Title III of Public Law 113-283);
(3) Source Code Harmonization And Reuse in Information Technology (public law 118-187, H.R. 9566)