Page History

BRIEF

Policy Summary

This policy establishes line management and individual responsibility for lifecycle management of Laboratory Information and Laboratory Information Technology (IT) assets at Berkeley Lab. This policy complements other policies on aspects of lifecycle management, including security and information controls. This policy describes responsibilities and requirements for lifecycle management of Berkeley Lab's:

• Information
• Institutional (centrally provided) services
• Hardware, software, and services, including acquisition restrictions
• Software with special considerations, including:
  • Safety Software
  • Software with physical interfaces
  • Hardware and software assets, and services, including acquisition restrictions

Who Should Read This Policy

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

To Read the Full Policy, Go To:

The POLICY tab on this wiki page

Contact Information

Information Technology Policy Manager
Information Technology Division
[email protected]

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

Anchor
_D._Policy_Statement _D._Policy_Statement

D. Policy Statement

Anchor
_D.1_Employee_Responsibilities _D.1_Employee_Responsibilities

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

Anchor
_D.2_Institutional_Services _D.2_Institutional_Services

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.

Anchor
_D.3_Operations_Divisions _D.3_Operations_Divisions

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.

Anchor
_D.4_Researchers_and _D.4_Researchers_and

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.

Anchor
_D.5_Safety_Software _D.5_Safety_Software

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.

Anchor
_D.6_Open_Source _D.6_Open_Source

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.

Anchor
_D.7_Information_Technology _D.7_Information_Technology

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.

Anchor
_F._Definitions/Acronyms _F._Definitions/Acronyms

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