POLICY

A. Purpose

This policy establishes lifecycle management for information, hardware, software, and services to promote the efficient management of Laboratory Information and IT, while facilitating the scientific mission of Lawrence Berkeley National Lab (Berkeley Lab).

B. Persons Affected

Employees and affiliates who use or manage Laboratory Information or IT; employees and affiliates who acquire, develop, or manage hardware, software, or services.

C. Exceptions

Not applicable

D. Policy Statement

D.1 Employee Responsibilities

Everyone is responsible for lifecycle management. Lifecycle management is a line-management function at Berkeley Lab. Laboratory employees and affiliates are responsible for the lifecycle management of Laboratory Information and Laboratory IT that they use or manage. Lifecycle management includes:

• Planning and project management, including disaster and continuity planning
• Security throughout the lifecycle
• Acquisition, development, and implementation
• Management, operations, backups, and maintenance and
• Disposal or retirement

D.2 Institutional Services

For both security and efficiency reasons, the Chief Information Officer identifies select services as Institutional Services. Only the responsible office or its designee may provide Institutional Services.

D.3 Operations Divisions

Operations divisions may not acquire hardware, software, or services to support operation-level activities without coordination with and approval from the IT Division.

D.4 Researchers and Research Divisions

In general, researchers and their line management are in the best position to identify hardware, software, and service needs, excluding Institutional Services. When identifying needs, researchers should use a cost-benefit approach to evaluate commercial, open source, custom, or other existing solutions. This section provides additional requirements or policy to promote responsible stewardship.

1. General Requirements for Software Development
   1. Lifecycle Management. Researchers should consider what components of lifecycle management, including quality assurance, are appropriate to the risks and uses of their software. In general, the peer review process constitutes adequate quality assurance for software developed for research purposes.
   2. Licensing. Researchers should consider licensing options early in their project and contact the Innovation and Partnerships Office for assistance.
   3. Disclosure Requirement. Under certain circumstances, researchers must submit software developed in the course of their work at Berkeley Lab per requirements of the Software Disclosure and Distribution policy.
2. Software and Service Acquisition
   1. Acquisition. If unavailable through Laboratory venues (e.g., software.lbl.gov and ebuy.lbl.gov), researchers may acquire software via standard procurement procedures. Software acquisition must comply with the Lab’s Prohibited and Inadvisable Products list.
   2. Researchers may acquire IT services provided that the services meet security requirements as appropriate.
      1. For cloud providers, researchers should assess the risks and identify any controls to mitigate those risks. Guidance: Cloud Services - Things to Consider.
      2. Researchers must contact Cyber Security ([email protected]) to discuss appropriate controls if a software or service:
         1. Has deep, persistent connections to institutional business systems or
         2. Has a Berkeley Lab domain name and is highly visible to the outside world such that compromise or failure would be newsworthy or
         3. Processes sensitive data such as Personally Identifiable Information (PII) or institutional financial or safety data with special integrity and availability requirements
   3. Licensing Agreements. Berkeley Lab permits licensing agreements in which the user accepts the agreement by clicking or opening the package. A Procurement representative must sign licensing agreements that require signatures.
3. Hardware Acquisition. In support of our mission, Berkeley Lab encourages system choice to support the diverse needs of researchers. Divisions and groups may set hardware standards or leave hardware decisions to the discretion of the principal investigator or end user. Standards and decisions should be based on managing lifecycle costs in support of effectively achieving research missions. Hardware purchases must comply with the Lab’s Prohibited and Inadvisable Products list.

D.5 Safety Software and Software with Physical Interfaces

During the course of research or operations, employees and affiliates may be involved with the development, maintenance, management, or use of Safety Software or software with physical interfaces. Employees and affiliates must adhere to the following requirements.

1. Safety Software. Safety Software is software whose degradation can have a direct effect on human safety (see full definition in Section F, below). Safety Software at Berkeley Lab must be appropriately approved, controlled, and tested.
   
   1. Approval and Inventory. Software that meets the definition of Safety Software must be reported to the Environment/Health/Safety (EHS) Division for approval. EHS must approve the development of safety software in coordination with the Information Technology Division. The Office of Contractor Assurance maintains the Safety Software Inventory, and the organization that owns or uses the software updates the inventory.
   2. Safety Software Quality Assurance Requirements. Anyone involved in the development, maintenance, management, or use of software on the Safety Software Inventory must adhere to the Safety Software Quality Assurance Requirements.
   3. Where software is part of a safety chain, but where a nonsoftware control protects human safety from software degradation, management may adopt a subset of the Safety Software Quality Assurance Requirements at its discretion.
2. Software with Physical Interfaces. Software used to monitor or interact with the physical world presents additional risks. This software usually includes programmable logic controllers (PLC) and supervisory control and data acquisition systems (SCADA). Even where this software does not rise to the level of Safety Software, it still merits deliberate controls and testing. Anyone involved in the development, maintenance, management, or use of software with physical interfaces should conduct a risk analysis and identify appropriate controls. When conducting the risk analysis, consider the whole system, including both software and nonsoftware components. Specific risks to consider include cyber security, data integrity, and damage to equipment.

D.6 Open Source Software

The Laboratory encourages the use of open source software and contributing to open source projects provided that contributions are within the terms associated with the funding for the work.

1. Cyber Security. Open source software may have cyber security benefits as multiple individuals view the code. However, use caution, especially with smaller projects. Download the software from a reputable source and, when available, use tools to check the integrity of the code (e.g., checksums).
2. Licensing. Open source software is typically released under a license that creates a legal obligation between the copyright holder and Berkeley Lab. Users must review and adhere to the licensing restrictions, especially when modifying or including the code within other software.

D.7 Information Technology Division

The Information Technology Division is responsible for developing and maintaining a graded approach to IT lifecycle management, from conception to retirement.
All IT-managed services (including institutional), hardware, software, and outsourced services must adhere to the IT lifecycle management approach, which incorporates grades based on risk to physical safety as well as privacy.

E. Roles and Responsibilities

Employees and affiliates are responsible for adhering to this policy.

F. Definitions/Acronyms

G. Recordkeeping Requirements

None

H. Implementing Documents

I. Contact Information

Information Technology Policy Manager
Information Technology Division
[email protected]

J. Revision History

DOCUMENT INFORMATION

Source Requirements Documents

• DOE O 200.1A, Information Technology Management, CRD
• DOE O 414.1D, Quality Assurance, Attachment 1, CRD
• DOE O 205.1C, Department of Energy Cybersecurity Program, CRD
• DOE Office of Science Program Cyber Security Plan, June 2010
• Berkeley Lab Senior Management requirement

Implementing Documents