Sign In
App icon


Available Now!
Get the App
Click Here to Continue Browser Session   ❯

Technical Data Management


The Technical Data Management process provides a framework to acquire, manage, maintain and ensure access to the technical data and computer software required to manage and support a system throughout the acquisition life cycle (see DAG CH 3–4.3.24. System Security Engineering for information regarding protection of critical program information).

Key Technical Data Management considerations include understanding and protecting Government intellectual property and data rights, achieving competition goals, maximizing options for product support and enabling performance of downstream life-cycle functions. DoDI 5000.02, Enc 2, sec. 6.a contains Technical Data Management requirements for Acquisition Category (ACAT) I and II programs.

Acquiring the necessary data and data rights, in accordance with Military Standard (MIL-STD)-31000, for acquisition, upgrades, and management of technical data provide:

  • Information necessary to understand and evaluate system designs throughout the life cycle.
  • Ability to operate and sustain weapon systems under a variety of changing technical, operational, and programmatic environments.
  • Ability to re-compete item acquisition, upgrades, and sustainment activities in the interest of achieving cost savings; the lack of technical data and/or data rights often makes it difficult or impossible to award contracts to anyone other than the original manufacturer, thereby taking away much or all of the Government’s ability to reduce total ownership costs (TOC).

Technical Data Management Activities and Products

The Program Manager (PM) and Systems Engineer, in conjunction with the Product Support Manager, should ensure that life-cycle requirements for weapon system-related data products and data rights are identified early and appropriate contract provisions are put in place to enable deliveries of these products. Figure 40 below shows the activities associated with Technical Data Management.

image containing five rectangles. The first 3 are lableed identify data requirements, acquire data, receive verify and accept data. These are grouped with the caption Data acquisition and are lifecycle impacting decision points. The last two are labeled sore, maintain and control data; and use and exchange data - these correspond to data management and use

Figure 40: Data Management Activities

Identify Data Requirements

  • Formulate the program’s Intellectual Property (IP) Strategy and technical data management approach, with an emphasis on technical and product data needed to provide support throughout the acquisition life cycle. (See CH 1–4.2.18. for more information about Data Rights).
  • Ensure that data requirements are documented in the IP Strategy; summarized in the Acquisition Strategy (AS) and presented with the Life-Cycle Sustainment Plan (LCSP) during the Operations and Support Phase; and submitted at each milestone before award of the contract for the next life-cycle phase.
  • Based on the technical baseline, identify assemblies, subassemblies, and parts that are candidates for Government ownership of data rights. Include this information in AoAs, trade studies and as input to RFPs.
  • Consider not only the immediate, short-term costs of acquiring the needed technical data and data rights but also the long-term cost savings resulting from the ability to compete production and logistics support activities and reduce TOC. Understand that the Government can possess either Government Purpose or Unlimited Rights to use many types of technical data and data rights, at no additional cost, based on the type of technical data and the source of funding used to generate the data (see DoD Open Systems Architecture Contract Guidebook for Program Managers for more information about data rights).
  • Consider any requirements to acquire rights to production and sustainment tooling and facilities, including processes required to use this equipment. Where the government has acquired rights to specific parts, these rights do not necessarily also convey rights to the equipment or processes used to produce the parts.

Acquire Data

  • Use explicit contract Statement of Work (SOW) tasks to require the developer to perform the work that generates the required data. The content, format and quality requirements should be specified in the contract.
  • Use current, approved Data Item Descriptions (DID) and Contract Data Requirements Lists (CDRL) in each contract to order the delivery of the required technical data and computer software.
  • Consider obtaining data through an open business model with emphasis on having open, modular system architectures that can be supported through multiple competitive alternatives. The model may include modular open systems approaches as a part of the design methodology supported by an IP strategy, which may be implemented over the life cycle of a product. (See DAG CH 3–2.4.1. Modular Open Systems Approach.)

Receive, Verify and Accept Data

  • Ensure verification of content, format, and quality of all required product-related data received from originators.
  • Inspect contractually ordered data deliverables to ensure markings are in accordance with the relevant data rights agreements and DFARS clauses and contain appropriate distribution statements and/or export control statements.

Caution: Acceptance of delivered data not marked consistent with the contract can result in the Government "losing" legitimate rights to technical data and can incur significant legal liability on the Government and the individual Government employees. Regaining those rights generally requires costly and time-consuming legal actions.

Store, Maintain and Control Data

  • Budget for and fund the maintenance and upkeep of product data throughout the life cycle.
  • An Integrated Data Environment (IDE) or Product Life-cycle Management (PLM) system allows every activity involved with the program to create, store, access, manipulate and exchange digital data.
  • To the greatest extent practical, programs should use existing IDE/PLM infrastructure such as repositories operated by Commodity Commands and other organizations. (Program-unique IDEs are discouraged because of the high infrastructure cost; furthermore, multiple IDEs inhibit access, sharing and reuse of data across programs.)
  • Ensure all changes to the data are made in a timely manner and are documented in the program IDE or PLM system.

Use and Exchange Data

Plan for and establish methods for access and reuse of product data by all personnel and organizations that perform life-cycle support activities. In support of the Government’s requirement for a Technical Data Package (TDP), the PM should also consider all product-related data (e.g., technical manuals, repair instructions and design/analysis data) to:

  • Allow logistics support activities.
  • Better enable sustainment engineering.
  • Apply, implement, and manage product upgrades.

Contractually deliverable data should be identified and ordered at the specific "data product" level, (e.g., two-dimensional drawings, three-dimensional Computer-Aided Design (CAD) models, technical manuals, etc.). Figure 41 below provides a notional representation of different types of product-related data.

Caution: PMs and Systems Engineers should be aware that terms such as "technical data," "product data," and "TDP" are imprecise, not equivalent, and often incorrectly used interchangeably.

Resources for establishing and conducting Technical Data Management activities include but are not limited to:

figure showing taxonomy of data with data at the top in level 1. Level two shows technical data and management info, computer software, and financial info. Level 3 is product data. Level 4: Product definition info, product associated info, and product operational info. Product definition info splits into requirements info, design info, and manufacturing info. Product associated info splits into ocnfiguration control info and verification info. Product Operational Info splits into logistics management info and in-service info. Design info goes into technical data package.

Data Protection

The Program Manager is responsible for protecting system data, whether the data is stored and managed by the Government or by contractors. The DoD policy with regard to data protection, marking, and release can be found in:

Data containing information subject to restrictions are protected in accordance with the appropriate guidance, contract, or agreement. Guidance on distribution statements, restrictive markings and restrictions on use, release or disclosure of data can be found in the DFARS (Subpart 252.227-7013 and 7014), and DoDI 5230.24.

When digital data are used, the data should display applicable restriction markings, legends and distribution statements clearly and visibly when the data are first opened or accessed. These safeguards not only ensure Government compliance regarding the use of data but also guarantee and safeguard contractor data delivered to the Government and extend responsibilities of data handling and use to parties who subsequently use the data.

P.L. 107-347 (SEC 208 para (b)) and DoDI 5400.16, "DoD Privacy Impact Assessment (PIA) Guidance" requires that PIA be conducted before developing or purchasing any DoD information system that collects, maintains, uses or disseminates personally identifiable information about members of the public, federal personnel, DoD contractors and, in some cases, foreign nationals. Available PIA guidance provides procedures for completing and approving PIAs.


Key terms

Intellectual Property (IP)
Intellectual Property (IP) Strategy

Statutes, Regulations, Guidance

DASD(SE) Initiative

Digital Engineering

DAU Training Courses

ACQuipedia Articles


Communities of Practice

DAU Data Management Community of Practice

Products and Tasks

Product Tasks
18-1-1: Verify technical data acquisition, access, management and protection policies and procedures
  1. Assess the technical data needs required for the program.
  2. Identify policies and procedures for information technology and technical data applicable to the system / program.
  3. Develop statement of work tasks to generate technical data to be acquired for a system, and submit to the decision maker for inclusion in contract documentation.
  4. Identify data item descriptions (DIDs) and contract data requirements lists (CDRLs) to acquire technical data for the system from the developer, and submit to the decision maker for inclusions in contract documentation.
  5. Document technical data needs, SOW tasks and technical data deliverables, along with associated technical data management processes, and incorporate into the intellectual property (IP) strategy.
  6. Receive, verify, and accept contractually ordered technical data.
  7. Verify contractually ordered technical data is stored, maintained, and has access controlled in accordance with the configuration management plan and the IP strategy.

Source: AWQI eWorkbook