CH 6–1. Purpose

The Defense Acquisition Guidebook (DAG) Chapter 6 provides guidance on where overarching policy may have unique application to the acquisition of Information Technology (IT) in the Department of Defense (DoD). The goal of this chapter is to enable the functional and acquisition communities who are developing and deploying IT capabilities to deploy at the speed at which they become viable – and ensure those capabilities are secure, data-centric, and readily available to users.

CH 6–2 DoD Information Technology (IT) Background

The DoD provides the IT infrastructure for our nation’s defenses and the 24/7/365 constant cybersecurity vigilance that is required to defend us from our determined cyber foes.

Historically, DoD’s IT investments were made to meet the needs of individual projects, programs, organizations, and facilities. This decentralized approach resulted in large cumulative costs and a patchwork of capabilities that created cyber vulnerabilities and limited the ability to capitalize on the promise of new developments in IT. That picture is now changing as better enterprise capabilities are being developed and implemented.

“IT” is a large, umbrella term covering many capabilities embodied in hardware, software, networking, and application hosting services that are essential to warfighting operations and efficient management of warfighting and the Department. Figure 1 depicts some of the types of IT operated in the Department applicable to the topics discussed in Chapter 6. It is not exhaustive of all IT but describes the most common types in use across DoD.

Figure 1: DoD Information Technology (IT)

CH 6–2.1 Key DoD IT Categories

There are varying types of IT managed in the Department, though not all are managed through “standard” acquisition process as outlined in DoD Instruction (DoDI) 5000.02, “Operation of the Defense Acquisition System”. Table 1 explains the broad categories of IT that are acquired and managed under standard acquisition processes while Table 2 outlines some exceptions to those processes.

Table 1: IT Managed Under Standard DoD Acquisition Processes

Major Category


Automated Information System (AIS)

As defined in Enclosure 1 Table 1 of DoDI 5000.02 (Footnote 4), an AIS is a system of computer hardware, software, data or telecommunications that performs functions such as collecting, processing, storing, transmitting, and displaying information. AISs exclude hardware and software embedded in a weapons system.

Despite minor differences in the definitions, the term “AIS” is synonymous with “Information System (IS).” While the word “automated” is historically part of the AIS term, the need for it has greatly diminished now that few people would consider an IS that does not take advantage of the automation offered by computer hardware and software. We have now taken to use the term “IS”, especially when needing to distinguish IS from weapons systems.

Information Systems (IS)

As defined in Title 44 U.S.C. section 3502, an IS is a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.

Information Technology (IT)

As defined in Title 40 U.S.C. section 11101, IT is any equipment or interconnected system or subsystem of equipment, used in the automatic acquisition, storage, analysis, evaluation, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information; includes computers, ancillary equipment (including imaging peripherals, input, output, and storage devices necessary for security and surveillance), peripheral equipment designed to be controlled by the central processing unit of a computer, software, firmware and similar procedures, services (including support services, and related resources). IT is equipment used by the DoD directly or is used by a contractor under a contract with the DoD that requires the use of that equipment. This term does not include the definition of National Security Systems as defined in Title 44 U.S.C. section 3552.

Major Automated Information System (MAIS)

A MAIS is an AIS that meets one or more of the estimated cost magnitude criteria listed in Enclosure 1 Table 1 of DoDI 5000.02.

Note: Sec. 846 of the FY2017 National Defense Authorization Act (NDAA) repealed Title 10 U.S.C. Chapter 144A (MAIS reporting statute) as of September 30, 2017. Per a November 17, 2017 memo from the USD(AT&L), the definition, dollar value, and decision authorities for MAIS programs shall remain as published in Enclosure 1 Table 1 of DoDI 5000.02, although baseline and breach reporting to Congress is no longer required. Additionally, per Sec. 831 of the FY2018 NDAA, Title 10 U.S.C section 2430(a) now excludes MAIS from the definition of a Major Defense Acquisition Program (MDAP).

National Security Systems (NSS)

As defined in Title 44 U.S.C. section 3552, NSS are telecommunications or information systems operated by or on behalf of the Federal Government, the function, operation, or use of which:

  • involves intelligence activities, cryptologic activities related to national security, command and control of military forces, equipment that is an integral part of a weapon or weapons system, or, is critical to the direct fulfillment of military or intelligence missions; OR
  • is protected at all times by procedures established for information that has been specifically authorized under criteria established by an Executive order or an Act of Congress to be kept classified in the interest of national defense or foreign policy.

NSS do not include systems used for routine administrative and business applications (including payroll, finance, logistics, and personnel management applications), i.e., defense business system (DBS).

Table 2: IT Exceptions to Standard DoD Acquisition Processes

Major Category


Defense Business System (DBS)

As defined in Title 10 U.S.C. section 2222, a DBS is an IS that is operated by, for, or on behalf of the Department of Defense, including any of the following: (i) a financial system; (ii) a financial data feeder system; (iii) a contracting system; (iv) a logistics system; (v) a planning and budgeting system; (vi) An installations management system; (vii) a human resources management system; (viii) a training and readiness system. DBS are not NSS, nor are they systems operated exclusively by the defense commissary system or the exchange system or conducted for the morale, welfare, and recreation of members of the armed forces using non-appropriated funds.

DBS are covered by DoDI 5000.75, “Business Systems Requirements and Acquisition”, which describes a process called the Business Capability Acquisition Cycle (BCAC). DBS are generally referred to as “business systems” throughout this chapter. Per a November 17, 2017 memo signed by the USD(AT&L), DBS that meet MAIS thresholds will follow the requirements of DoDI 5000.75. Additionally, per Sec. 831 of the FY2018 NDAA, Title 10 U.S.C section 2430(a) now excludes DBS from the definition of a MDAP.

Embedded IT

Embedded IT (refer to definition of “AIS” in Enclosure 1 Table 1 of DoDI 5000.02, Footnote 4) is described as computer resources, both hardware and software, that are an integral part of a weapon or weapons system; used for highly sensitive classified programs (as determined by the Secretary of Defense); used for other highly sensitive IT programs; or determined by the Defense Acquisition Executive (DAE) or designee to be better overseen as a non-AIS program (e.g., a program with a low ratio of Research, Development Test, & Evaluation (RDT&E) funding to total program acquisition costs or that requires significant hardware development).

This form of IT acquisition is usually better managed as a subsystem of the larger weapon system. The embedded IT subsystem Program Manager (PM) usually reports to the weapon system PM and in these circumstances oversight of embedded IT programs or subprograms is not distinct from the parent weapon system.


Many aspects of IT can be acquired as a service; hardware, software, infrastructure services, and data can all be acquired on a subscription basis. Some forms of service-based acquisitions are covered by the new DoDI 5000.74, “Defense Acquisition of Services”. DoDI 5000.74 applies to programs with “a total estimated acquisition value in current year dollars at or above the simplified acquisition threshold.” If, however, the estimated costs exceed any of the MAIS definition thresholds of Enclosure 1 Table 1 of DoDI 5000.02, the program is treated in the nature of an IS (i.e., MAIS) program. Other exceptions are noted in DoDI 5000.74.

CH 6–2.2 DoD Information Technology (IT) Acquisition

Acquisition programs are generally categorized based on the criteria in Enclosure 1 Table 1 of DoDI 5000.02. CH 1 - Section includes a broader discussion of acquisition categories, or “ACATs”, and explains their thresholds. Table 1 of DoDI 5000.74 explains applicability of Acquisition of Services Categories, or “S-CATs”, while Table 1 of DoDI 5000.75 contains applicability of Business System Categories, often referred to as “B-CATs”. Both DoDIs also describe decision authority unique to each category.

In terms of broad applicability to IT programs, under the DoDI 5000.02:

  • ACAT I programs are either Major Defense Acquisition Programs (MDAPs) or Major Automated Information Systems (MAIS);
  • Large IT programs are most often MAIS programs and are not managed as MDAPs even if they meet the MDAP threshold (see Sec. 831 of the FY2018 NDAA, which updates Title 10 U.S.C. section 2340(a) to exclude MAIS from the definition of a MDAP); and
  • IS programs do not fall into the ACAT II category – they are either ACAT I or ACAT III.
  • Programs can be deemed “special interest” (for any number of reasons) and treated as an ACAT I or IA – though often these programs are managed in a highly tailored way.
  • If the estimated costs to acquire IT services, which is covered by DoDI 5000.74, exceed any of the MAIS definition thresholds of DoDI 5000.02, the program is treated as a MAIS program and not a service (see paragraph 2.b.(1) of DoDI 5000.74).

Regarding decision authority for IT programs:

  • The Under Secretary of Defense for Acquisition and Sustainment (USD(A&S)) is the Defense Acquisition Executive (DAE) and will typically serve as the Milestone Decision Authority (MDA) for MAIS and MDAP programs, unless this authority is delegated.
  • MDA for ACAT III programs is typically delegated to Program Executive Officers.

CH 6–3. Business Practice

CH 6–3.1 Oversight and Tailoring

MDA designation and associated oversight is determined by Enclosure 1 Table 1 of DoDI 5000.02 (or through the DoDI 5000.74 or DoDI 5000.75) and adjusted through consideration of estimated cost magnitude, risk assessment, third party interest, acquisition phase, subject matter, and system function. This generally applies to programs for acquiring IT, including IS, IT embedded in weapon systems, IT infrastructure, and information services; however, each of those types of IT acquisition requires a customized (if not unique) approach to structuring the program and providing its oversight.

From a program structuring / process perspective, the goal should be to design and scope a program that will deliver capability rapidly, while tailoring out unneeded or non-value added documentation and process steps. Tailoring must begin up-front, with key stakeholders involved to create buy-in to the approach. In general, tailoring should consider multiple factors including program size, scope, risk, urgency of need, and technical complexity. IT programs are often excellent candidates for tailoring as they necessitate more rapid deployments and more frequent upgrades of capability. CH 1, Section 4.2.3 includes additional discussion on tailoring.

Generally, the PM proposes and the MDA approves tailoring decisions in an Acquisition Decision Memorandum (ADM). Tailoring discussions should occur with program leadership, stakeholders, and the MDA (if possible) very early on in the program and should continue throughout. There are various methods of tailoring described throughout this Chapter.

CH 6–3.2 Program Structure

There is no one best way to structure or “tailor” an acquisition program. Consistent with applicable statutes and regulations, time constraints for delivery of the capability, solution characteristics, and performance criteria all will determine program strategies and oversight (to include documentation of program information, acquisition phases, timing and scope of decision reviews, and decision levels). For an IT program specifically, the hardware/software mix and the degree of customization at minimum will impact how that program is structured and managed – though many other factors ultimately impact these decisions (i.e., funding availability, requirements prioritization, risk, etc.). Refer to CH 1, Section 3.3 for detailed discussions on organizing an acquisition program.

In the DoD acquisition context, the terms “Program” and “Increment” refer to the management structure of an acquisition effort. The term “program,” however, is used in confusingly similar ways by the acquisition community as well as other communities within DoD. Therefore, “acquisition program” is used by the acquisition community to refer to the basic unit of management for an acquisition effort. In the DoDI 5000.02 the terms “Acquisition Program” and “Increment” are often used interchangeably.

The basic unit of management for a weapon system acquisition is a Program. Weapon system acquisitions are often lengthy endeavors, which can span decades. IS or IT acquisitions—in contrast—require a tighter acquisition cycle because technology must be developed or configured and deployed before it becomes obsolete. The pace of development and change in IT is fast and the general expectation is that IT acquisitions can and should react at the same speed. The Increment has quickly become the basic unit for management of an IT acquisition.

An Increment is a militarily useful and supportable operational capability that can be developed, produced, deployed, and sustained. Each Increment typically has an Acquisition Program Baseline (APB) with its own set of threshold and objective values set by the user and is a separate acquisition program as defined in paragraph 5.c.(3)(d) of DoDI 5000.02. In the context of an IS or IT acquisition, this means that both threshold and objective values for cost, schedule, and performance parameters must be established for each Increment.

The terms “generation” and “block” have been used for IT acquisitions, but they are more useful in the context of weapon system hardware acquisition. The term "program" in the IT context refers to the summation of a succession of Increments, and is a consolidation of acquisition efforts that is useful for Planning, Programming, Budgeting, and Execution System (PPBE) purposes.

Program (IT) = Σ Increments (IT)

The following additional terms are useful referencing the software itself: “version,” “release,” and “iteration” all relate to the sequence and importance of a particular software application. For example, the hypothetical Application 2.3.4 is Iteration 4 of Release 3 of Version 2.

The term “version” is regularly used together with a hierarchically structured number such as 2.4.3 to refer to and track the series of improvements or progress of software development. These numbers are assigned in increasing order and correspond to new developments in the software. Logically, the initial number of a Version should reflect the Increment to which it belongs; Version 3.1.1 should be part of the Increment 3 effort.

CH 6–3.3 DoD Acquisition Models

The Department’s acquisition models as described in paragraph 5.c.(2) of DoDI 5000.02 are high-level processes that encompass the acquisition of a system in the DoD. Not all are used for the acquisition of IT and therefore models 1 and 4 have been omitted from the discussion. Descriptions of all models are available in paragraph 5.c.(2) of DoDI 5000.02 as well as CH 1, Section of the DAG. The DoDI 5000.75, "Business System Requirements and Acquisition" provides an additional model specific for business systems, the Business Capability Acquisition Cycle (BCAC). Table 3 provides descriptions, examples and drawbacks of the models that are typically used for acquiring IT in the Department.

Table 3: Models Used for the Acquisition of IT


Description of Model




Defense Unique Software Intensive Program

  • Used for complex, usually defense unique software programs that are deployed only after several software builds have been completed.
  • Subsequent software builds only proceed after successful completion of program milestones.
  • Military unique command and control (C2) systems
  • Significant upgrades to the combat systems found on major weapons systems such as surface combatants and tactical aircraft.
  • Can lead to long waits between deliveries that can cause product obsolescence
  • Slow delivery can cause customer dissatisfaction and push back


Incrementally Deployed Software Intensive Program

  • Used for software development programs where the deployment of the full capability will occur in multiple Increments as new capability is developed and delivered, nominally in 1- to 2-year cycles.
  • It is distinguished from model 2 by the rapid delivery of capability through multiple Increments.
  • Each Increment provides part of the overall required program capability.
  • Most often referred to as the “DBS” Model though may be used less frequently for DBS with the introduction of the DoDI 5000.75.
  • There is some concurrency of development for each Increment.
  • Can be used for commercial-off-the-shelf (COTS) software development with multiple modular capabilities.
  • DBS
  • Upgrades to some C2 system software
  • Upgrades to weapons systems software
  • Problems in Increments may be difficult to fix in other concurrent Increments.
  • Concurrent deliveries can be difficult to manage especially in complex systems.
  • The program can become overwhelmed with frequent milestone or deployment decision points and associated approval reviews.
  • Usage may become less common with introduction of DoDI 5000.75.


Hybrid Program A (Hardware Dominant)

  • Used for developing systems where hardware and software development is occurring simultaneously.
  • The implementation of prototypes determine overall schedule, but software development and deployment must be tightly integrated and coordinated with hardware development and delivery.
  • Software builds should lead up to the full capability needed to satisfy program requirements and Initial Operational Capability (IOC).
  • Aircraft, ship or land vehicle development where software is a critical component of weapon system delivery.
  • Difficult to manage the timing for both hardware and software deliveries.


Hybrid Model B (Software Dominant)

  • Used for software intensive product development with a mix of incrementally deployed software releases that includes intermediate software builds.
  • All of the characteristics of Model 3 also apply to this Model.
  • DBS
  • Upgrades to some C2 system software
  • Upgrades to weapons systems software
  • It is a complex model to plan and execute successfully.
  • Highly integrated complex software and hardware development, poses special risks to program cost and schedule

Business Systems “BCAC”

  • Integrated requirements and acquisition process guidance to improve the delivery of business capabilities
  • Drive cultural change, governance shifts to an integrated and streamlined format
  • Use of flexible and tailorable Authority To Proceed decisions (ATPs) vs more rigid Milestones
  • Streamlined documentation; less emphasis on format/separate documents, more emphasis on the information presented
  • DBS
  • New, not yet widely adopted
  • Policy is less prescriptive than the DoDI 5000.02

CH 6–3.4 Common Software Development Methods

The DoD uses many different variations and combinations of software development methods, but they generally fall into three major categories: Waterfall, Incremental, and Agile. These development methods are also used for other types of project implementation plans other than software development. The DoD’s most widely-used development method for IT is Incremental, though more organizations are working to adopt Agile or are incorporating principles of agile into their software development practices.

CH 6–3.4.1 Waterfall

The Waterfall method is a classical software development method where tasks are arranged to fall sequentially. One phase is completed before the next phase is started. Several software builds are completed before deployment. In its purest form, all requirements are known before IT is developed and the finished product is not delivered until all tasks are completed. For large and complex projects, this can mean that the underlying technology is obsolete before delivery. It also assumes an unrealistic view that organizations are static with the product’s requirements remaining the same throughout the life of the project. If one task is not completed on time, the entire project can be halted. This method provides the greatest risk to user satisfaction; however, it also typically provides the lowest risk to meeting contractual requirements.

CH 6–3.4.2 Incremental

The Incremental method has been used to correct some of the problems associated with the Waterfall method. Note that “Spiral” and “Evolutionary Acquisition” are sometimes used synonymously with “Incremental”. These terms actually vary slightly from one another and the preferred term as used in the DoDI 5000.02 is Incremental. It has the goal of delivering additional improved capability in block Increments over time. This method allows capability to be developed and delivered concurrently. If well-managed, this method allows the product to be delivered earlier. In the DoD, you will generally see an initial deployment of 60%-80% of the product delivered; with the remaining capabilities delivered incrementally later.

A variant of Incremental is often used where an Increment is broken down into multiple manageable releases (i.e., Increment 1; Release 1.1; Release 1.2). This may enable both the Functional and the Program Manager to better manage requirements and deployments into smaller “chunks” of capability, getting capability into users’ hands more quickly.

CH 6–3.4.3 Agile

In 2001 a group of software developers got together to develop a set of best practices for developing software earlier, with greater customer satisfaction, and higher quality. The group developed the Agile Manifesto:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
  • The manifesto was further elaborated in the Agile Principles.

The best practices established through the Agile Manifesto and Principles are not necessarily new. However, they have been very difficult for the DoD to implement.

In Agile’s purest form, end user(s) should sit with developers in order to make instant decisions on user functionality. High level requirements are initially prioritized and developed quickly by small teams in order to get a working product quickly to the customer. There are several Agile methods have been developed from the Agile Manifesto and Principles including eXtreme Programming (XP), Scrum, and Adaptive Software Development (ASD). An excellent description of the various Agile development methods is provided in a White Paper developed by the Software Engineering Institute titled, “Considerations for using Agile in DoD Acquisition.”

Agile methods are typically used for small, low risk projects. However, some large DBS ERP programs have recently begun to incorporate agile principles to some degree of success, such as using Scrum or Sprints as part of their normal software development practices.

Table 4: A Comparison of Software Development Methods



Best Used For




  • Uses independent development phases that are completed sequentially
  • Serial, “big-bang” solution with one long cycle times
  • Programs where the requirements are very well understood at the onset of the project
  • Functionality to be delivered is mature and static
  • Best fits with Model 5, though also Model 1 (not described here)
  • Typically low risk of not meeting contractual requirements if applied correctly
  • All functionality is delivered at the same time
  • Easiest delivery schedule management
  • High risk of user dissatisfaction
  • Requires a complete set of requirements at the onset
  • Difficult to incorporate user feedback
  • Experimental code or prototypes are discarded after use


  • Development phases can be completed concurrently
  • Generally 60-80% of product is initially delivered with incremental deliveries delivered later
  • Projects where all requirements are not known at beginning of project
  • Best fits with Models 2, 3, and 6, and the DoDI 5000.75
  • Users can provide feedback earlier
  • Developers have opportunity to identify potential problems earlier
  • Does not require a complete set of requirements at onset of project
  • Overlapping deployments or tasks produce usable functionality earlier
  • Schedule with concurrent tasks is difficult to manage
  • If well managed, project can be delivered earlier
  • Experimental code or prototypes are discarded after use


  • Customer satisfaction is highest priority
  • Can be thought of as both a set of software development best practice as well as a software development method
  • Requirements are prioritized, multiple, rapidly executed Increments are developed and capabilities are released to the customer as soon as possible
  • Prototypes may be used as a starting place
  • It utilizes a modular, open-systems approach.
  • Documentation is kept to an absolute minimum
  • Small- to mid-sized applications
  • Best fits with Models 3, 4, 6, and the DoDI 5000.75
  • Customers get a workable product more quickly
  • Less documentation, more usable code
  • Continual involvement of the end user
  • Developers are able to easily course correct
  • Scope creep virtually eliminated
  • Requires dedicated on site customer collaboration
  • Difficult to resolve Agile’s lack of documentation required and the DoD’s statutory and regulatory documentation requirements
  • Difficult to price because all requirements are not scoped at beginning of project

CH 6–3.4.4 Approach to IT Acquisition

The Department’s six acquisition models are high-level processes that encompass the acquisition of a system in the DoD. As described in Section 3.3, Models 2, 3, 5, 6, and the business systems model (i.e., BCAC) are the most commonly used for IT acquisition. However, any one of the acquisition models could potentially be tailored and used to acquire IT. The following diagram breaks down a “notional” DoD acquisition model and explains various activities that may occur for a generic IT acquisition; it also points out some specialized activities that might occur during a business system acquisition, for example. The notional model certainly isn’t a one-size-fits-all concept – for example it should be noted that business systems, as outlined in the DoDI 5000.75, use Authority to Proceed (ATP) decision points rather than milestones.

Figure 2: “Notional” DoD IT Acquisition Model

Figure 2: “Notional” DoD IT Acquisition Model

CH 6–3.5 DOTMLPF-P Capabilities

As described in paragraph 5.b.(2) of DoDI 5000.02, all acquisition programs respond to validated capability requirements. The Department defines capability requirements from a holistic, end-to-end perspective across the Doctrine, Organization, Training, Materiel, Leadership, Personnel, Facilities, and Policy (DOTMLPF-P) spectrum. A DOTMLPF-P capability includes the ability to perform specific actions that, when taken as a whole, solve a validated requirement (i.e., need, business need, problem, gap, etc.).

DOTMLPF-P capabilities are always based on a business or mission function need as opposed to IT or materiel components. The capabilities are also prioritized based on their ability to solve the problem (i.e., operational effectiveness) as well as the anticipated benefits of the capability. Capabilities should be forward-looking; they describe the business or mission functions that must be executed in the future state and they serve as the foundation from which the future requirements are derived and the future system (if one is necessary) is developed and executed.

The capability requirements process for most non-IT programs is called the Joint Capabilities Integration and Development System (JCIDS) process. Non-Business System IT programs use the JCIDS IT Box process, while business systems validate capability requirements using processes described in the DoDI 5000.75 and supplemental guidance.

Figure 3 illustrates the general interaction between the capability requirements and acquisition processes. This interaction is also depicted in Figure 2, the Notional DoD IT Acquisition model.

Figure 3: Interaction between Capability Requirements and Acquisition Processes

Figure 3: Interaction between Capability Requirements and Acquisition Processes

CH 6–3.5.1 JCIDS IT Box

The JCIDS process supports identifying, assessing, validating, and prioritizing joint military capability requirements. The JCIDS IT Box was created to provide an agile and responsive capability requirements process and enable rapid development of IT capabilities.

Figure 4: IT Box Process

Figure 4: IT Box Process

IT Box Applies To

IT Box Does Not Apply To

  • Information Systems (IS) with software development only
  • Includes integration of COTS hardware
  • Program costs that exceed $15 million
  • Defense Business Systems (DBS)
  • Systems that are an integral part of a weapon or weapon system
  • IS with a developmental cost less than $15 million

The Information System (IS)-Initial Capabilities Document (IS-ICD) and the IS-Capabilities Development Document (IS-CDD) are the main requirements documents used in implementation of the IT Box. These are variants of the standard ICD and CDD used in the JCIDS process and are designed to focus on facilitating more efficient and timely software development efforts. The major difference between the IS-ICD and the IS-CDD is that the capabilities outlined get refined and presented as Key Performance Parameters (KPPs), Key System Attributes (KSAs) with specific threshold requirements, and objective targets. CDDs are not required as successor documents for non-MDAP IS-ICDs and Capability Production Document (CPD)s are not required as successor documents for IS-CDDs. CH 7 - Section also discusses JCIDS documents from an intelligence support and acquisition perspective.

Detailed guidance for the IS-ICD and the IS-CDD are provided in the JCIDS Manual and DAU’s IT Box Primer. The JCIDS Manual also includes examples of potential IS-ICD and IS-CDD follow-on documents such as the following:

  • Requirements Definition Package (RDP) – identifies KPPs and non-materiel changes.
  • Capability Drop (CD) – lower-level document that specifies the characteristics of a “widget” or “app” for partial deployment of the system.
  • Readers should note the IS-ICD and IS-CDD only streamline the applicable requirements processes; therefore the capability’s Functional Sponsor must still ensure compliance with acquisition policy and processes in DoDI 5000.02.

CH 6–3.5.2 Defense Business Systems

Business Systems support DoD business activities such as acquisition, financial management, contracting, logistics, strategic planning and budgeting, installations and environment, and human resource management. They do not follow the IT Box and do not generally utilize IT Box or traditional JCIDS process documentation. Instead, business systems follow processes governed by Title 10 U.S.C. section 2222 and the DoDI 5000.75, “Business Systems Requirements and Acquisition”, which depicts a process model called the Business Capability Acquisition Cycle, or “BCAC”. BCAC has five phases and is intended to be cyclical and flexible with steps repeating as necessary in order to drive rapid achievement of intended business outcome(s) based on a validated capability need (see Figure 5). BCAC implements a unique business systems governance and management structure; assigns responsibilities to the functional and acquisition communities; provides direction for the identification of business needs and for the development of capability requirements and their supporting IT; and emphasizes continuous process improvement as part of ongoing business capability support.

Figure 5: BCAC Circular Model

BCAC incorporates the following guiding principles throughout the business system lifecycle:

  • Work as a Team: Work together as one team with functional, acquisition, and IT members involved throughout the lifecycle.
  • Plan to Evolve: The lifecycle is continual and flexible and tailoring of program documentation and milestones is encouraged. System sustainment requires criteria and triggers that define on-ramps back into BCAC to restart the cycle.
  • Adopt Best Practices: Don’t reinvent the wheel. Be willing to prioritize requirements, deploy the 80% solution, change processes to minimize customization, and stop the effort if it is not going to achieve the outcome.
  • Show the Money: Increase transparency by allocating and tracking funding for all activities across the DOTMLPF-P spectrum, including the cost of requirements development and system sustainment.
  • Do Work Once: Avoid bottlenecks and eliminate competing processes. Work products are for the use of the process operators – eliminates extraneous documentation for documentation’s sake.
  • Deliver Value: Deliver a capability that addresses the entire DOTMLPF-P spectrum –not just an IT system. Increase value by reducing time to deliver capability.

The biggest differences from the previous state of practice under the DoDI 5000.02 include:

  • Alignment of acquisition, functional, infrastructure, and IT investment governance to streamline decision-making.
  • Information-centric approach to evaluating programs rather than reliance on acquisition and requirements documentation. Many separate documents that were once required under DoDI 5000.02 are no longer required under the DoDI 5000.75; however the information contained in them should be generated as necessary to inform decisions.
  • Reflects elimination of statutory MAIS requirements (effective September 30, 2017).

BCAC practitioners and stakeholders should visit the MilSuite-based Business Systems Community of Practice (DoD CAC-required) for emerging guidance and other resources.

Other important BCAC resources are as follows:

  • BCAC Process Definition Document – This document clarifies aspects of DoDI 5000.75 by providing more in-depth descriptions of BCAC activities. This document is meant to be a continuous work in progress as BCAC best practices emerge from community discussion.
  • BCAC CONOPs – This document describes the background to and purpose of developing a lifecycle process for business capabilities and systems.

The Defense Business Council (DBC) is the governing body who oversees defense business operations on behalf of the Secretary under the authority of Title 10 U.S.C. section 2222 and the DBC Charter.

The DBC serves as the:

The DBC is co-chaired by the Deputy Chief Management Officer (DCMO) and the DoD Chief Information Officer (CIO). More information is available on the DCMO’s DBC webpage.

Governance for business capabilities is not a one-size-fits-all model and must be adaptive, transparent, and inclusive of key stakeholders to enable rapid decision making on key matters such as requirements, cost, schedule, performance, and risk. Simplified and effective governance driven by clear outcomes throughout the capability life cycle is encouraged, as is delegating governance decisions to the lowest practical possible levels.

CH 6– Capability Requirements

Generation of capability requirements, which may occur in the form of a Capability Requirements Document (CRD) but may take on other formats depending on how each Service / Component has chosen to implement the DoDI 5000.75. These artifacts will replace the Problem Statement for business systems. The intent is that the documented requirements will be the outcome of a thorough analytical process during which the business need and end state are identified and business processes and performance measures are clearly defined; this process will also include analysis of other organizations with similar capability needs. The business need is based on the desired end state, the problem(s) preventing it, and the future capabilities required to achieve it. These types of initial requirements documents are not intended to be IT solutions documents.

DBS generally do not use the JCIDS process for defining requirements unless the requirement is deemed joint interest. At that point, the Joint Staff will provide guidance for any additional processes or documentation needed.

Business systems practitioners can visit the Business Community of Practice – Requirements Community for example requirements documents and capability requirements-related discussion.

CH 6– Authority to Proceed (ATP) Decisions

As business systems transition from the DoDI 5000.02 to the BCAC process in DoDI 5000.75, they will use event-based decision points called ATPs. Figure 6 displays a linear BCAC model with ATP decision points.

Figure 6: BCAC Linear Model with Decision Points

An ATP is a “milestone-like” event. It is possible to map some of the BCAC ATPs to traditional acquisition milestones, but the intent was not to make them equivalent. Table 4 of DoDI 5000.75 identifies the statutory requirements that are aligned to ATPs. In addition, the entrance criteria in Table 5 of DoDI 5000.75 —which can be further tailored—help point to what may need to be accomplished for an ATP.

Some key points about ATPs include:

  • ATP meetings or decision reviews should include participation/input from all relevant stakeholders and decisions should be based on timely and relevant capability or program information.
  • Chief Management Officer and MDA roles both exercise decision authority at:
    • Functional Requirements ATP, during which it is determined if there is a valid requirement and/or if a business system is needed
    • Acquisition ATP, during which it is determined whether or not to acquire a particular system and where the CMO initially certifies funds
  • The leading community recommendation is to capture both investment and acquisition decisions in a single memo with two signatures; discussion will continue on the Business Systems Community of Practice regarding ATP procedures and documentation.
  • Although separate reviews for Clinger-Cohen Act Compliance are no longer required under BCAC, some organizations may choose to include a CIO signature on ATP documentation beginning with the Acquisition ATP.

CH 6–3.5.3 Business Process Reengineering (BPR)

Business process reengineering (BPR), as defined by the U.S. Government Accountability Office (GAO), is a systematic, disciplined improvement approach that critically examines, rethinks, and redesigns mission-delivery processes in order to achieve dramatic improvements in performance in areas important to customers and stakeholders.

BPR employs a logical methodology for assessing process weaknesses, identifying gaps, and implementing opportunities to streamline and improve the processes in business operations. The Department’s approach to BPR is an iterative process which begins with a focus on the business activities / work and the information used. Processes are then further refined and adapted as the Information Technology requirements are modeled. This approach aligns with the principles of Doctrine, Organization, Training, Materiel, Leadership and Education, Personnel, Facilities, and Policy (DOTMLPF-P) analysis. BPR is a companion activity to defense business system implementation, is a key tenet in the DoDI 5000.75, and should be practiced throughout the entire business systems lifecycle.

One of the most important reasons for performing sufficient BPR is to avoid modifying the core code of a commercial-off-the-shelf (COTS) product at all costs. In industry, customization is most often focused on processes that will give a company competitive advantage over or set them apart from other companies. Since the federal government is not profit-driven and is rather being mandated by Congress to not customize products, the push should be to utilize BPR and to adhere to the out of the box products as much as possible, which is an industry best practice. A 2015 report by Panorama Consulting found that of the 562 companies they surveyed:

  • The majority (66%) did little to no customization (defined as modifying one-quarter or less of the solution).
  • 34% did “significant” (22%), “extreme” (7%), or “complete” (5%) customization to their ERP implementation.

Ultimately, Functional Sponsors and Program Managers should try to find ways to modify existing business processes rather than customizing commercial software products to meet their needs. Discussions on common standards (Section 3.7) and requirements and configuration management (Section 3.5.5) are important to being successful in this area.

While it is possible to add code in the form of Reports (R), Interfaces (I), Conversions (C), Enhancements (E), Forms (F) and Workflows (W) (RICE-FW), this practice significantly increases program costs and should be minimized as much as possible through BPR. In many cases there will only be a few instances where BPR is not possible. For example, due to policy or law, it may be necessary to build or acquire needed reports, interfaces, conversions, and extensions. In these cases, adding to the product must be done under strong configuration control.

The Functional Sponsor, representing the needs of the user, leads the BPR effort. BPR may include eliminating non-value added processes, consolidating separate functional tasks into end-to-end cross-functional processes, and integrating business functions as much as possible to improve business operations and to achieve the desired outcome(s). BPR is a continuous process and requires a rethinking of why the "As-Is" process came to be and how it can be improved to achieve efficiencies.

Ideally BPR will begin prior to the start of the Acquisition process to understand the picture of “what good looks like”. However, BPR truly cannot be completed until a solution is selected to understand the underlying business processes of the product.

Major duties and responsibilities of BPR stakeholders:

  • The Functional Sponsor (or Sponsor), informed by input from the corresponding DoD Military Component, is responsible for BPR.
  • The PM is responsible for analyzing and considering the results of the BPR and using the goals of the reengineered process to shape the program.
  • Technical SMEs (including test and engineering), to understand the impact of process changes vs. technical changes
  • Cost SMEs, to understand the cost impacts of process changes vs. technical changes

CH 6–3.5.4 Developing Relevant Outcomes

Successful capability delivery in IT programs relies upon the ability to track progress toward completion. Generally, Performance Measures/Attributes are used to determine the degree to which a DOTMLPF-P capability has been successfully implemented. Measures and Attributes are tied to each Capability in order to answer the question: how will we know if this Capability has been fulfilled? The Performance Measures are defined at a mission or business level and can be broken down into process or system metrics later in the transformation effort. Outcomes define “what good looks like” to indicate when success has been achieved at varying levels (strategic, business, program, KPPs, KSAs, etc.) – and, to indicate when failure may be on the horizon.

Performance measures identify the performance-based metrics that provide visibility to the outcomes progress towards completion. IT programs should initiate a top-down decomposition process of outcomes and performance measures development, where high-level outcomes are developed early on and then decomposed further into business and program outcomes as more detail is learned throughout.

Any outcome should explicitly state the business value of the resources to be invested and to allow leadership to prioritize and weigh investments. The outcome provides strategic alignment and clear criterion against which to evaluate potential approaches. It always starts with the desired result and is used to focus behaviors and results by answering the "what's in it for me?" question. Corresponding measures must be specific, actionable, measureable, relevant, and timely operational capabilities that can be achieved against their corresponding outcomes.

It is important to note that the Functional Sponsor (who represents the needs of the user[s] that originally identified the problem, need, or requirement) is ultimately responsible for declaring whether the needed capability has been delivered.

Integrated teams should develop measures and metrics – while the exercise may be led by a Functional Sponsor or representative, it requires involvement from the Program Manager or key representatives from the program office, as well as SMEs from the test and engineering communities to ensure that measures are realistic, relevant, and testable from the beginning.

CH 6–3.5.5 Requirements Management

Documenting and managing requirements is one of the biggest challenges in DoD IT systems, and is critical to ensure effective delivery of a comprehensive DOTMLPF-P capability. For example: A 2009 GAO audit found that DoD and service officials responsible for conducting Analysis of Alternatives (AoAs) indicated that often proposed capability requirements are so specific that they effectively eliminate all but the service sponsor's preferred concepts instead of considering other alternatives (GAO-09-655, September 2009).

The process of requirements and configuration management is described in CH3, Systems Engineering and also in Enclosure 3, Section 8 of DoDI 5000.02. The bottom line is that ensuring strong requirements and configuration management processes will ensure traceability and insight into all levels of development and design of the DOTMLPF-P solution. It is critical to establish and maintain consistency of a system’s functional, performance, and physical attributes with its requirements, design, and operational information throughout a system's life cycle.

Effective control processes will allow a PM to better manage cost, schedule, and performance; and enable the PM to deliver a product that the Functional customer had envisioned:

  • Configuration Control Boards (CCBs)
    • The use of CCBs is one of the most common (and effective) ways to control and manage requirements on IT programs. CCBs are most commonly partnerships between the functional and programmatic communities, involving tradeoffs of software requirements – depending on what level the CCB is held at in the organization. They may be referred to as Enterprise (or Executive) CCBs, Software CCBs, Requirements CCBs, or by other nomenclatures.
  • Baseline Management
    • Depending on the type of IT implementation, many programs manage the implementation of the software baseline (and changes to it) separately from the modernization program. This can offer both challenges and benefits, but managing separately can become unwieldy on a large program if the efforts are not in sync with one another.
  • Tools
    • Many DoD IT programs, most often due to the volume of requirements they must contend with, use automated tools to manage different parts of the requirements process – and some are customized for the type of software development process that is being followed. The scope of tools available include: Issue Management, Agile, Project Management, Product Management, Requirements Development, Requirements Management, Visual Modeling, Testing, User Interface/User Experience (UI/UX) Mockup, etc.

CH 6–3.6 Managing IT Program Investments

The overarching Planning, Programming, Budgeting, and Execution process is described in CH 1 Section 3.2.2 and Cost Estimation in CH 1 Section Defense Budget Materials are available on the DoD Comptroller’s website and are updated every Fiscal Year. Finally, DAU offers a continuous learning module, CLB 023 Software Cost Estimating. Annual IT Budget Submission guidance is published by the DoD CIO to adjust the submission process outlined in the FMR to ensure currency with OMB guidance. Contact DCIO-R&A or your Component budget office for the most current guidance.

More specifically, there are two major budget submission requirements for DoD IT investments: IT Budget Estimate Submission (BES) and the Congressional Justification submission or President’s Budget (PB) Request. Instructions for submitting IT specific budgets can be found in DoD 7000.14-R Financial Management Regulation Volume 2B, Chapter 18 Information Technology (Including Cyberspace Operations) dated September 2015.

DoD utilizes several systems to capture and maintain IT investment information including Department of Defense Information Technology Investment Portal (DITIP) and the Select & Native Programming Data Input System for Information Technology (SNaP-IT).

During the first phase in the annual budget cycle, the Office of the Director, Cost Assessment and Program Evaluation (D, CAPE) and the Office of the Under Secretary of Defense (Comptroller) (USD(C)) are responsible for conducting an annual Program Budget Review PBR on all DoD resources and require a data submission from all DoD Components.

Components are also required to submit supplemental PBR data on their Major Defense Acquisition Programs (MDAPs) and Major Automated Information System (MAIS) programs. This supplemental submission of MDAP and MAIS data supports ongoing OUSD(A&S) data transparency and data alignment efforts initially directed in the Fiscal Year 2011 Integrated Program Review Resource Management Directive 700 study.

Data submission is required for all current MDAPs and MAIS programs, as well as acquisition program concepts and Unbaselined MAIS programs that will achieve Milestone B prior to the end of the calendar year, or have been certified under the provisions of section 2366a of title 10 United States Code. The MDAP and MAIS program data must include all acquisition costs (RDT&E, Procurement, MILCON, Acquisition O&M, Working Capital Funds, or Other Financing with an explanation) and MDAP quantities (RDT&E and Procurement) for the full acquisition cycle of each MDAP and each MAIS program (by fiscal year and funding appropriation). For MAIS programs, the total life-cycle cost is the development cost plus ten years of Operation and Support (O&S) costs following Full Deployment declaration. For MDAP programs, the full acquisition lifecycle and associated funding is defined by the Director of CAPE and USD(C) PBR Submission Guidance.

All MDAPs and MAIS programs submit annual PBR data that has been coordinated with and approved by the appropriate Component Acquisition Executive (CAE) into their Component’s acquisition information system. For efficient information sharing, the CAE systems publish the data to Acquisition Visibility (AV) using the Defense Acquisition Management Information Retrieval (DAMIR) system Web Services. Components without access to one of the Component acquisition information systems use the DAMIR “Create or Edit a Budget Report” module. Notwithstanding the method of transmission, exposure, or publication, the CAE-approved PBR data is be available for consumption by AV and AV subscribers as determined by annual guidance.

CH 6–3.6.1 Federal IT Dashboard

The Federal IT Dashboard (ITDB) displays general information on over 7,000 Federal IT investments and detailed data for over 700 ‘major” investments. DOD’s IT investments on the Federal ITDB span the investment lifecycle (planning and budgeting, acquisition, management in-use). A general overview and tutorial of the Federal IT Dashboard can be accessed here. The DoD CIO ratings process is conducted semiannually and was designed in accordance with Office of Management and Budget (OMB) and internal DoD policies, processes, and procedures.

The Federal ITDB has high visibility with GAO, OMB, and now even Congress, who all use it as a tool to identify troubled investments. The Federal Information Technology Acquisition Reform Act (FITARA) now requires the DoD CIO to review any DoD investment on the ITDB that receives a high risk rating for four consecutive quarters and provide a report to relevant House and Senate committees, in addition to OMB.

The DoD CIO publishes guidance on how to assess investments that must be reported on the Federal IT dashboard and utilizes a CIO Ratings Recommendations submission page (CAC-enabled), which contains the latest reference documents, approved ratings, stakeholder ratings recommendations, and POCs for completing the ratings process. Guidance is provided in the "Department of Defense Chief Information Officer (DoD CIO) Ratings Process for the Federal Information Technology (IT) Dashboard," dated March 25, 2014 and available within the above linked site.

CH 6–3.6.2 IT Budget Estimate Submission (BES)

Guidance and formats for the preparation and submission of the Information Technology Budget Estimate Submission (BES) to the DoD CIO are provided in DITIP and through SNaP-IT.

CH 6–3.6.3 President’s Budget (PB) Request

The President's Budget request for the DoD is submitted to Congress by the President. All DoD Components that require funding for IT programs and/or Cyberspace operations submit budget requests that are authorized by the DoD Component, OSD, the Office of Management and Budget (OMB), the President, and ultimately by Congress. Budget requests are prioritized based on the mission objectives of the Component, DoD and the President. General guidance for budget request submission requirements is presented in Volume 2A, Chapter 1 of the DoD Financial Management Regulation (FMR) and in the OSD Program/Budget guidance memos.

CH 6–3.6.4 MAIS Annual Report (MAR)

Title 10 U.S.C Chapter 144A formerly required that the Secretary of Defense submit to Congress annual reports on all MAIS and unbaselined MAIS programs.

Note: Sec. 846 of the FY2017 National Defense Authorization Act (NDAA) repealed Title 10 U.S.C. Chapter 144A (MAIS reporting statute) as of September 30, 2017. MAIS reporting is no longer required. (See Table 1 for more information)

CH 6– OMB Policy

OMB Circular A-11 provides guidance to Federal programs on how to prepare and submit materials required for OMB and Presidential review of agency budget requests. The guide to OMB Circular Number A–11 provides a description of the contents of the Circular. Section 25.5 of the Circular provides a table with the required contents of the Budget Request to be submitted to OMB.

Section 55 of Circular A-11 provides high-level guidance pertaining to agency IT investment portfolios and the Agency IT Portfolio Summary (formerly known as Exhibit 53A). FY IT 2019 Budget – Capital Planning Guidance provides more detailed instructions on the components of the Agency IT Portfolio Summary as well as how to submit investment portfolio information.

The policy and specific instructions on managing Federal information resources are provided in OMB Circular A-130, “Management of Federal Information Resources,” The policies in the Circular apply to the information activities of all agencies of the executive branch of the Federal government. The Department of Defense Information Technology Information Portal (DITIP) and/or Select and Native Programming – Information Technology (SNaP-IT) systems are used to gather information requested by OMB.

CH 6– IT Business Case

The Major IT Business Case is one component of the Agency’s total budget justification (see Section 51.2 of Office of Management and Budget (OMB) Circular No. A-11). OMB uses data reported in the Major IT Business Case to make quantitative decisions about budgetary resources consistent with the Administration’s program priorities as well as qualitative assessments about whether the Agency’s programming processes are consistent with OMB policies and guidance. OMB may request additional supporting information from Agencies as necessary. The Agency IT Portfolio Summary and Major IT Business Cases (including Business Case and Business Case Detail) describe the justification, planning, and implementation of an individual capital asset, included in the Agency IT Portfolio Summary and serve as key artifacts of the Agency’s Enterprise Architecture (EA) and Capital Planning and Investment Control (CPIC) processes.

Business Cases are only required for Part 1 (Mission Delivery – Segment 700) and Part 2 (Mission Support Systems – Segment 500) Major IT Investments. OMB does not require Part 3 (IT Infrastructure, IT Security, and IT Management –Segments 600, 610, and 800) Investments to complete Business Cases due to the level of effort required to transition to the new Standard Investment structure and Standard Investment Reports intended to collect relevant information for specific types of commodity IT.

Together, the Major IT Business Case and Major IT Business Case Details provide the budgetary and management information necessary for sound planning, management, and governance of Major IT Investments. These documents help Agencies explicitly align IT Investments with strategic and performance goals, and ultimately provide value to the public by making Investment and management information more transparent.

CH 6–3.6.5 Affordability

The purpose of conducting an Affordability Analysis is to avoid starting or continuing programs that cannot be produced and supported utilizing future budgets. Affordability is relatively straight forward when procuring tanks; however, it can be difficult to determine for some IT investments such as IT Services where there are no specific “units”.

The best opportunity for determining affordability is through tailoring capability requirements before and during the development of an AoA. Components should incorporate estimated funding streams for future programs within their affordability analyses at the earliest conceptual point and specify those estimates at the MDD and beyond to inform system design and alternative selection.

Prior to MS B (or the equivalent ATP), affordability goals are considered targets and are used to help scope the AoA and other required analyses in order to achieve an affordable program to be put on contract at RFP release and to be baselined at MS B. Once requirements and the product definition are firm, affordability caps are established to provide fixed cost requirements that are functionally equivalent to Key Performance Parameters (KPPs).

Additional policy regarding conducting affordability analysis is located in Enclosure 8 of DoDI 5000.02 and Enclosure 10, section 2 of DoDI 5000.02.

CH 6–3.6.6 Lifecycle Cost Estimating for IT

Developing a well thought out Lifecycle Cost Estimate (LCCE) with costs from inception to retirement is crucial for the following:

  • Establishing fiscal feasibility of the program,
  • Informing AoAs,
  • Guiding capability requirements and engineering tradeoffs,
  • Setting realistic program baselines to control life-cycle costs, and
  • Instill more cost-conscious management in the DoD.

Life-Cycle Cost (LCC) estimating represents the total cost to the Government for an IS, weapon system, program and/or investment over its full life. It includes all developmental costs, procurement costs, MILCON costs, operations and support costs, and disposal costs. LCC encompasses direct and indirect initial costs plus any periodic or continuing sustainment costs, and all contract and in-house costs, in all cost categories and all related appropriations/funds.

LCC may be broken down to describe the cost of delivering a certain capability or useful segment of an IT investment. LCC normally includes 10 years of sustainment funding following Full Operational Capability (FOC) or Full Deployment for Automated Information Systems. For investments with no known end date that are beyond FOC, LCC estimate should include 10 years of sustainment.

The Director of Cost Assessment and Program Evaluation (DCAPE) provides policies and procedures for developing LCCEs for all DoD acquisition programs. DCAPE also reviews cost estimates and cost analyses conducted in connection with Major Defense Acquisition Programs (MDAPs) and Major Automated Information System (MAIS) programs.

The DCAPE also conducts Independent Cost Estimates (ICE) and cost analyses for MAIS (if directed by the MDA, or if a program is in a critical change – otherwise an ICE is typically not required) and MDAP programs. The documentation of each MDAP or MAIS program cost estimate prepared by DCAPE and/or Service or Agency includes the elements of program cost risk identified and accounted for, how they were, evaluated and possible mitigation measures.

The DCAPE requires use of a Cost Analysis Requirements Description (CARD). The CARD is a complete description of the system at a level of detail appropriate for calculating costs. DCAPE provides CARD development guidance tailored to the specific review being conducted and the type of system being developed. However, all CARDs, no matter how tailored, will provide a program description that includes a summary of the acquisition approach, expected constraints, system characteristics, quantities, operational factors, operational support strategy, preliminary schedules, test programs, technology maturation and risk reduction plans, and appropriate system analogs. Additional content may be required as requested by DCAPE.

Should the contractor proposed solutions entering the Technology Maturation and Risk Reduction Phase differ significantly from the design reflected in the Milestone A CARD, the Program Manager will report any differences that might alter the basis for the MDA’s Milestone A decision to DCAPE and the MDA. The MDA will determine whether an additional review is required prior to contract award.

At the Development RFP Release Decision Point, the program described in the final CARD will reflect the Program Manager’s and PEO’s best estimate of the materiel solution that will be pursued following Milestone B. The final CARD is updated to reflect all new program information prior to Milestone B.

For DBSs, a Cost Element Structure is required when developing a Business Case. An example of commonly used elements is provided in the DoD Enterprise IT Business Case Analysis Template Appendix B. The Cost Element Structure is the most critical element of the BCA process to ensure consistent, comparable cost estimates on IT.

DoD Components develop a DoD Component Cost Estimate that covers the entire life cycle of the program for all MAIS programs at any time an Economic Analysis is due.

Guidance for developing LCCEs is provided in the Enclosure 10, section 2 of DoDI 5000.02. Additional information on LCCEs can be found in the in DoD 7000.14-R Financial Management Regulation Volume 2B, Chapter 18 Information Technology (Including Cyberspace Operations) dated September 2015.

CH 6– Should-Cost and Will-Cost

The concept of “should-cost” is driven by the DoD culture of cost-consciousness. It is focused on controlling the cost of the actual work that we are doing and expect to do and to identify and eliminate inefficient and non-productive tasks from our programs. Should-cost is a tool to manage all costs throughout the lifecycle, and it operates in parallel with the effort to constrain requirements in order to costs all the way through to sustainment of the capability. In particular, should-cost estimates inform negotiations with industry over contract costs and incentives. The should-cost approach challenges us to do our best to find specific ways to beat the Independent Cost Estimate (ICE) or Program Estimate (which should already reflect the affordability requirements) and other cost projections funded in budgets (i.e., “will-cost”), when we find sensible opportunities to do so. For example, should-cost does not mean trading away the long-term value of sound design practices and disciplined engineering management for short-term gain.

In 2011, the USD(AT&L) and the Comptroller signed out a memo containing the “ingredients” to should-cost management. Another excellent resources is the April 2014 Issue of the Defense Acquisition Research Journal examined how programs have implemented should-cost, the types of savings identified and realized, and best practices and lessons learned that might be adopted by other programs in the Department.

Should-cost is reported through the DAES review process. For additional information on should-cost and will-cost, visit CH 1 Section 4.2.17.

CH 6–3.6.7 Program Funding Chart

The purpose of the Program Funding Chart is to capture the primary acquisition and sustainment program budgets relative to the previous President’s Budget and latest estimate of funds required to execute the program. Instructions and links to the funding chart are available here and are CAC-enabled. The template is updated as Programming, Planning, Budgeting, and Execution System (PPBE) events occur. The Program Funding Chart features prominently throughout the DAB process.

The basic instructions for the Program Funding Chart are to report all RDT&E, Procurement and MILCON investments supporting the baselined acquisition program, consistent with the Selected Acquisition Report (if applicable). Report all weapon system O&M associated with the program, consistent with the Operating and Support estimates reported in the SAR (if applicable). Other appropriations supporting O&S are not reported.

CH 6–3.6.8 IT Portfolio Management

Portfolios can be based on mission areas or commodity types, and will define a collection of products or capabilities that can be managed together for investment analysis and oversight purposes. Components will normally make tradeoffs within portfolios, but if necessary, can and should make tradeoffs across portfolios to provide adequate resources for high-priority programs

Component level affordability analysis examines all programs and portfolios together, extending over enough years to reveal the life-cycle cost and inventory implications of planned program for the Component. The same analysis is used as individual programs come up for review. Nominally, affordability analysis covers 30 to 40 years into the future.

Authority for portfolio management is found in many locations. For example:

Guidance or best practices on how to conduct portfolio management is more difficult to come by.

CH 6– Defense Business Systems Investment Review (Certification)

Certification of investments are required for covered defense business systems (i.e., those DBSs with funding >$1M over the period of the current Future Years Defense Program (FYDP)). All appropriations require certification. In addition, all funding including funds from another DoD Component must be certified. These rules have changed with the FY2016 NDAA and this guidance will be updated accordingly when the DCMO introduces updated policy.

As part of the DBS certification process, DoD Components (e.g., MILDEPS and Defense Agencies) annually develop Organizational Execution Plans (OEPs). Each OEP is comprised of three elements: the Portfolio Certification Request, the OEP briefing, and views of authoritative data from DoD Information Technology Portfolio Repository (DITPR) and Select & Native Programming Data Input System for Information Technology (SNaP-IT). DoD Defense Business Council (DBC) members assess Component OEPs and provide recommendations to the Chair on certification of funds. The DCMO approves OEP certifications and records the outcomes in investment decision memoranda (IDMs).

Current DBS certification instructions are provided in the DCMO’s Guidance for Review and Certification of Defense Business Systems, version 4.0, April 2017.

Specific instructions for utilizing the Defense Information Technology Investment Portal (DITIP) for DBS certification management can be accessed from the DITIP webpage. Select the link “DITIP Instruction-DBS Certification Management” in the Documents section.

CH 6– Integrated Business Framework

The Integrated Business Framework provides the overarching structure used to govern and manage the Department’s business operations from the creation of aligned business strategies and investment plans, to the measurement of outcomes. A description of the framework is provided on Page 5 of the DCMO’s Guidance for Review and Certification of Defense Business Systems, version 4.0, April 2017. The framework is also designed to facilitate a cross-functional, enterprise-wide view for the governance of portfolios of DBSs investments over the FYDP for review and certification. The DoD’s Strategic Management Plan (SMP) is as an enterprise plan for improving DoD's business operations. The Department is currently transitioning toward incorporating the business strategy into an Agency Strategic Plan (ASP) that will provide a more comprehensive plan and measures.

CH 6– Clinger-Cohen Act

The Clinger-Cohen Act, or Title 40 U.S.C. Subtitle III (formerly known as Division E of the Clinger-Cohen Act (CCA), referred to as "Title 40/CCA", applies to all IT investments, including National Security Systems (NSS). Title 40/CCA requires Federal agencies to focus more on the results achieved through its IT investments, while streamlining the Federal IT procurement process. Specifically, this Act introduces much more rigor and structure into how agencies approach the selection and management of IT projects.

Title 40/CCA generated a number of significant changes in the roles and responsibilities of various Federal agencies in managing the acquisition of IT. It elevated oversight responsibility to the Director of the Office of Management and Budget (OMB) and established and gave oversight responsibilities to the departmental Chief Information Officer (CIO). Also, under this Act, the head of each agency is required to implement a process for maximizing the value and assessing and managing the risks of the agency's IT acquisitions.

In DoD, the DoD CIO has the primary responsibility of providing management and oversight of all Department IT to ensure the Department's IT systems are interoperable, secure, properly justified, and contribute to mission goals.

The basic requirements of the Title 40/CCA, relating to DoD's acquisition process, have been institutionalized in DoDI 5000.02, in particular, Enclosure 11. The requirements delineated in this section must also be considered and applied to all IT investments, regardless of acquisition category, and tailored commensurate to size, complexity, scope, and risk levels. CCA for DBS is addressed in DoD 5000.75.

Figure 7: Title 40 – Clinger Cohen Act Compliance

Figure 5: Title 40 – Clinger Cohen Act Compliance

PMs, program sponsors/domain owners, members of the joint staff, and DoD Component CIO responsibilities are further explained and detailed in the IT Community of Practice knowledge center which also contains a vast array of information pertinent to specific aspects of Title 40/CCA compliance.

A comprehensive compilation of Federal laws, OMB and Budget circulars, DoD directives and instructions, and OSD policy memorandums, relevant to all aspects of Title 40/CCA compliance, is available in the CCA Policy Folder of the Acquisition Community Connection. The Title 40/CCA Compliance Table details actions required to comply with Title 40/CCA regulatory requirements, mandatory DoD policy, and the applicable program documentation that can be used to fulfill the requirement.

The requirements delineated in this table must also be considered and applied to all IT investments, regardless of acquisition category, and tailored commensurate to size, complexity, scope, and risk levels.

CH 6–3.6.9 Contracting - Special Circumstances and Best Practices

Fundamentally, there is no one “best fit” type of contract for the acquisition of information technology. Many program offices have found that having a contracting officer integrated into the program planning activities up-front to gain subject matter expertise into the IT capability enables more appropriate contracting vehicles to be applied.

When acquiring IT and developing requests for proposals (RFPs) and contract statements of work (SOWs), they should be reviewed as part of the acquisition process to ensure that IT standards established in a program’s requirements document are translated into clear contractual requirements.

Various methodologies, toolsets, and information repositories have been developed to assist the Program Manager (PM) in the implementation of COTS software-based programs. The remainder of this section provides the PM descriptions of best practices, available tools and methods, and critical success factors for use in the acquisition of commercially-based solutions.

CH 6– Enterprise Software Initiative

The DoD Enterprise Software Initiative (DoD ESI) is a joint, Chief Information Officer (CIO)-sponsored project designed to: "Lead in the establishment and management of enterprise COTS information technology (IT) agreements, assets, and policies for the purpose of lowering total cost of ownership across the DoD, Coast Guard and Intelligence communities." DoD ESI is a key advisor to the DoD Strategic Sourcing Directors Board. With active working members from OSD, Department of the Army, Department of the Navy, Department of the Air Force, Defense Logistics Agency, Defense Information Systems Agency, National Geospatial-Intelligence Agency, Defense Intelligence Agency, Director of National Intelligence, and Defense Finance and Accounting Service, the DoD ESI team collaborates to create Enterprise Software Agreements (ESA) for use by DoD, the Intelligence Community, and U.S. Coast Guard IT buyers. ESA negotiations and management activities are performed by IT acquisition professionals within participating DoD Components, who are designated ESI "Software Product Managers (SPM)." SPMs are supported by experienced IT contracting experts.

The DoD ESI can use the Defense Working Capital Fund to provide "up-front money" for initial wholesale software buys and multi-year financing for DoD customers. This funding process assures maximum leverage of the combined buying power of the Department of Defense, producing large software cost discounts.

On-line resources include the DoD ESI website listing general products, services and procedures the Defense Federal Acquisition Regulation Supplement Subpart 208.74; and Enclosure 11 section 10 of DoDI 5000.02.

CH 6– Defense Federal Acquisition Regulations

The Defense Federal Acquisition Regulations (DFARS) contains contractual requirements for IT. Subsections of interest include subpart 239.71 regarding security and privacy for computer systems, subpart 208.74 on enterprise software agreements and subpart 227.72 for policy on the acquisition of commercial computer software and commercial computer software documentation.

CH 6– Defense Information Systems Agency (DISA) Support

Purchasing telecommunications and IT products and services for the military is one of DISA's key roles within the DoD. The DISA Contracts Guide (CAC Only) is provided by Defense Information Technology Contracting Organization (DITCO); it contains a list of Premier Contracts as well as ordering instructions. In addition:

  • DISA provides Enterprise Acquisition Services (EAS) for purchasing telecommunications and information technology (IT) products and services from the worldwide commercial sector to meet Department of Defense (DoD) and authorized non-defense customers' needs. Services include acquisition planning, procurement, tariff surveillance, cost and price analyses, and contract administration. DISA is the mandated single source for procuring DoD long haul telecommunications requirements.
  • DISA establishes large contract vehicles available to DoD for essential IT services such as engineering, hardware, equipment and maintenance, integration and support, information security, computer technology, satellite bandwidth, and Defense Information System Network (DISN) access.
CH 6– Strategic Sourcing

Strategic Sourcing is about buying smartly and collaboratively in an effort to reduce costs and maximize the use of available funds. While this concept is most often thought of in the context of supply chain management, it has strong applicability to information technology in terms of buying bulk software, licenses, and / or services. Resources for Strategic Sourcing assistance include:

  • In an effort to enhance collaboration and integration, the OSD Office of Defense Procurement and Acquisition Policy (DPAP) provides multiple resources for Strategic Sourcing opportunities and best practices and sits on the government-wide Strategic Sourcing Leadership Council (SSLC), whose objective is to lead the government's efforts to increase the use of government-wide management and sourcing of goods and services.
  • DPAP also has a DoD-Wide Strategic Sourcing (DWSS) CONOPS available to explain how to use the DWSS program.
  • Finally the DAU Acquisition Community Connection has a Community of Practice for Strategic Sourcing available with many best practices.
CH 6– Data Rights

Data Rights is a shorthand way to refer to the Government's license rights in major categories of valuable intellectual property, and it factors critically into how a capability is contracted for and how data is managed for the life of a program. Data Rights are also discussed in CH 4 Section

Data Rights for technical data and computer software fall into eight categories:

  • Unlimited Rights. Developed exclusively at Government expense, and certain types of data (e.g., Form, Fit, and Function data [FFF]; Operation, Maintenance, Installation, and Training [OMIT]), these rights involve the right to use, modify, reproduce, display, release, or disclose technical data in whole or in part, in any manner, and for any purpose whatsoever, and to have or authorize others to do so.
  • Government Purpose Rights. This right involves the right to use, duplicate, or disclose technical data for Government purposes only, and to have or permit others to do so for Government purposes only. Government purposes include competitive procurement, but do not include the right to permit others to use the data for commercial purposes.
  • Limited Rights. A limited rights agreement permits the Government to use proprietary technical data in whole or in part. It also means that the Government has to obtain the expressed permission of the party providing the technical data to release it, or disclose it, outside the Government.
  • Restricted Rights. Developed exclusively at private expense
  • Specifically Negotiated License Rights. This right pertains whenever the standard license arrangements are modified to the mutual agreement of the contractor and the Government. In this case, the exact terms are spelled out in a specific license agreement unique to each application.
  • Small Business Innovative Research (SBIR) Data Rights. All technical data or computer software generated under a SBIR contract. Government users cannot release or disclose outside the Government except to Government support contractors.
  • Commercial Technical Data License Rights. Applies to technical data related to commercial items (developed at private expense). Managed in the same manner as Limited Rights.
  • Commercial Computer Software Licenses. Applies to any commercial computer software or software documentation. Managed as specified in the commercial license offered to the public.

Only under very unique circumstances does the Government acquire title to or ownership of technical data or computer software developed under DoD contracts – even if the Government funded 100% of the development. Instead, the Government acquires a license to use, release, or disclose that technical data or computer software to persons who are not Government employees. Therefore, the DoD often negotiates over license rights and not ownership of technical data or computer software to be delivered under a contract. A Program Manager must ensure that all Technical Data and Computer Software and related license rights required for procurement and sustainment of a system are available throughout a system’s life cycle.

The DFARS, subpart 227.71 (rights in technical data) prescribes policies and procedures for the acquisition of technical data and the rights to use, modify, reproduce, release, perform, display, or disclose technical data. Statutory references Title 10 U.S.C. section 2320 and Title 10 U.S.C. section 2321 also provide additional information. Other resources for learning about data rights include:

CH 6–3.7 Common IT Standards

The DoDI 8310.01, "Information Technology Standards in the DoD” is the overarching policy for IT standards in order to promote interoperability, information sharing, reuse, portability, and cybersecurity within the DoD. It is policy that DoD-approved and adopted standards are listed in the DoD IT Standards Registry (DISR), which enables centralization and transparency of available and applicable standards across the Department. To request an account, access the GTGF web site at:

The Federal Government and DoD recommend industry-based standards whenever possible (Revision of OMB Circular No. A–119, ‘‘Federal Participation in the Development and Use of Voluntary Consensus Standards and in Conformity Assessment Activities’’). However, each program must balance the use of industry based standards against unique military standards that are essential to many tactical systems and international/NATO standards in order to meet operational requirements. There are also Federal government and DoD standards-based approaches that must be considered (i.e., the National Information Exchange Model (NIEM) as outlined in DoDI 8320.07, “Implementing the Sharing of Data, Information, and Information Technology (IT) Services in the Department of Defense”. Use of these standards-based approaches are compatible with the DoD-approved standards list in the DISR.

CH 6–3.7.1 Enterprise Architecture

All DoD architectures, including warfighter, intelligence, business, and component enterprise architectures, are part of the DoD Enterprise Architecture (EA). The DoD EA is defined as a federation of descriptions that provide context and rules for accomplishing the mission of the Department. These descriptions are developed and maintained at the Department, Capability Area, and Component levels and collectively define the people, processes, and technology required in the "current" and "target" environments, and the roadmap for transition to the target environment. As the Secretary of Defense's principal staff assistant for IT and information resources management, the DoD Chief Information Officer (DoD CIO) develops, maintains, and facilitates the use of the DoD EA to guide and oversee the evolution of the Department's IT-related investments to meet operational needs.

To comply with the enterprise architecture:

  • Follow the DoD Architecture Framework (DoDAF) guidance in creating architectural views. This guidance is met by creating an architecture that captures the specific data needed to support decision making. The specific data is predicated by explicitly identifying the intended use and scope of the architecture in question. DODAF guidance can be accessed through the Office of the Deputy Chief Management Officer’s DODAF webpage.
  • Meet the DODAF Meta-model (DM2) Physical Exchange Specification (PES) requirements for sharing/reusing architecture data. DODAF Meta-model (DM2) guidance can be accessed from the DCMO’s DODAF Meta-model webpage.
  • When building systems, requests for proposals (RFPs) and contract statements of work (SOWs) should be reviewed as part of approved acquisition processes to ensure IT standards established in ICDs, CDDs, CPDs or Problem Statements are translated into clear contractual requirements.
  • Meet the purpose and intent of the DoDI 8320.02, "Sharing Data, Information, and Information Technology (IT) Services in the Department of Defense" and DoDI 8320.07 for securely sharing electronic data, information, and IT services and securely enabling the discovery of shared data.
  • DoD Enterprise Services are common, globally-accessible services identified by the DoD CIO; it is expected that all programs and initiatives will use them over developing their own capability.
CH 6– Open Systems Architecture

PMs are responsible for applying open systems approaches in product designs where feasible and cost-effective. Open systems and modular architectures provide valuable mechanisms for continuing competition and incremental upgrades, and to facilitate reuse across the joint force. PMs should use open systems architecture design principles to support an open business model (see paragraph 6a(4) in Enclosure 2 of the DoDI 5000.02).

CH 6– Business Enterprise Architecture (BEA)

The Business Enterprise Architecture (BEA) is the enterprise architecture for the DoD Business Mission Area and reflects DoD business transformation priorities; the business capabilities required to support those priorities; and the combinations of enterprise systems and initiatives that enable those capabilities. It also supports use of this information within an End-to-End (E2E) framework.

The purpose of the BEA is to provide a blueprint for DoD business transformation that helps ensure the right capabilities, resources and materiel are rapidly delivered to our warfighters – what they need, when they need it, where they need it, anywhere in the world. The BEA guides and constrains implementation of interoperable defense business system solutions as required by Title 10 U.S.C. section 2222. It also guides information technology investment management to align with strategic business capabilities as required by the Clinger-Cohen Act, and supports Office of Management and Budget (OMB) and Government Accountability Office (GAO) policies.

The Strategic Management Plan (SMP), Functional Strategies as developed by the appropriate DoD Principal Staff Assistants and the Organizational Execution Plans (OEP) as developed by DoD Components are the drivers of BEA release content.

CH 6–3.7.2 Audit Readiness and Audit Standards

DOD's financial management has been on GAO's High Risk List since 1995 because of pervasive deficiencies in financial and related business management systems, processes, and controls. Congress has mandated a full audit of DOD’s FY2018 financial statements, the results of which must be submitted to Congress by March 31, 2019. A critical piece in aiding the Department to achieve financial auditability is the Comptroller’s Financial Improvement and Audit Readiness (FIAR) Plan and the accompanying FIAR Guidance. The FIAR Guidance serves as a standard reference guide for existing and new users involved in all audit readiness initiatives across the Department. The DoD Comptroller’s FIAR Directorate has also published an extensive and helpful resource of tools, templates and work products.

The FIAR Guidance contains discussion of common critical standards in order to aid the Department in achieving auditability, which ultimately impacts the requirements and configurations of IT systems as they are developed, deployed and managed:

CH 6–3.7.3 Standard Financial Information Structure (SFIS)

The Standard Financial Information Structure (SFIS) is a comprehensive data structure that supports requirements for budgeting, financial accounting, cost/performance, and external reporting needs across the DoD enterprise. SFIS standardizes financial reporting across DoD and allows revenues and expenses to be reported by programs that align with major goals, rather than basing reporting primarily on appropriation categories. It also enables decision-makers to efficiently compare programs and their associated activities and costs across the department and provides a basis for common valuation of DoD programs, assets, and liabilities. SFIS compliance ultimately is determined by how compliant a system is with the SFIS business attributes; areas of SFIS compliance include

  • Reporting and Posting Chart of Accounts
  • Posting Logic
  • DDRS SFIS Trial Balance with edits/validations (e.g.Tie-Points Recons)
  • Interfaces (e.g. SLOA)
  • Independent third party assessment of FFMIA compliance

Another critical financial standard is the DoD Standard Line of Accounting (SLOA), which is used to identify the funding source associated with an organization’s budget and to ensure accurate accounting transactions. Many of the FFMIA Requirements are written to support SFIS and SLOA. SLOA objectives include:

  • All SLOA data elements are attributes in SFIS
    • For Ex: An object class is a SLOA Data Element and a SFIS attribute
  • SLOA will reduce 100 plus different LOA’s to one standard line of accounting.
  • SLOA contains data elements required for
    • Treasury and OMB Reporting (at the Appropriation Level)
    • DFAS Reporting and Reconciliation and Component Reconciliations (at the Appropriation Level)

There are 67 total SFIS attributes. Of the 67 attributes, 26 are SLOA data elements.

CH 6–3.7.4 Item Unique Identification

Item Unique Identification (IUID) is an international standards-based approach adopted by the DoD and its implementation is driven by and required by DoDI 8320.03, "Unique Identification (UID) Standards for Supporting DoD Net-Centric Operations". IUID makes the acquisition, repair, and deployment of items faster and more efficient through achievement of information sharing, visibility, assurance, and interoperability. IUID is required for all new DoD acquisitions; items the government already owns (i.e., legacy items); and government furnished property meeting any one of the following criteria:

  • the item has a line item acquisition cost in its contract of $5,000 or more
  • the item is or will be serially managed by the DoD
  • the item is or will be controlled or mission essential
  • permanent identification is or will be wanted for any other reason

IUID rules may apply differently for embedded systems. Items requiring IUID must be assigned a globally unique, permanent unique item identifier, or UII, and the UII registered, along with other item identifying information, in the DoD IUID Registry. Tools and guidance for implementing IUID are available in the IUID Toolbox.

CH 6–3.8 Interoperability

Interoperability, guided by the DoDI 8330.01, "Interoperability of Information Technology (IT), Including National Security Systems (NSS)", is the ability of systems, units, or forces to provide data, information, materiel, and services to, and accept the same from, other systems, units, or forces and to use the data, information, materiel, and services so exchanged to enable them to operate effectively together. Information Technology (IT) and NSS interoperability includes both the technical exchange of information and the end-to-end operational effectiveness of that exchange of information as required for mission accomplishment. Interoperability is more than just information exchange. It includes systems, processes, procedures, organizations and missions over the life cycle, and it should be balanced with IA.

Supportability for IT systems and NSS is the ability of systems and infrastructure components, external to a specific IT or NSS, to aid, protect, complement, or sustain the design, development, testing, training, or operations of the IT or NSS to achieve its required operational and functional capabilities.

IT and NSS interoperability and supportability needs, for a given capability, be identified through:

  • The Defense Acquisition System (as defined in DoDI 5000.02 and DoDD 5000.01)
  • The Joint Capabilities Integration and Development System (JCIDS) process
  • The Business Capability Acquisition Cycle (BCAC) process for business systems
  • The Doctrine, Organization, Training, Materiel, Leadership and Education Personnel and Facilities (DOTMLPF) change recommendation process

CH 6–3.8.1 Interoperability Requirements and Verification

For all information technology, measurable interoperability requirements must be identified, formally validated through NR KPP certification, and then formally tested through an interoperability certification process. The Joint Interoperability Test Command (JITC) produces an Interoperability Process Guide which outlines the procedures and documentation required for Joint Interoperability Test and Certification, waiver processing, and associated processes and procedures. It also addresses interoperability test and certification based on the Net-Ready Key Performance Parameter (NR KPP). More on the role of JITC can be found in CH 8 Section

Interoperability requirements must be documented in a succinct, measurable, and testable manner as an NR KPP. The NR KPP must describe a set of performance measures (MOEs and MOPs). The NR KPP must assess information requirements, information timeliness, and net-ready attributes required for both the technical exchange of information and the end-to-end operational effectiveness of that exchange.

The ISP is a key document in achieving interoperability certification. The ISP describes IT and information needs, dependencies, and interfaces for programs. It focuses on the efficient and effective exchange of information that, if not properly managed, could limit or restrict the operation of the program in accordance with its defined capability. Interoperability testing is further described in CH 8 Section 3.7.6.

CH 6– Net-Ready KPP

Net-ready attributes determine specific criteria for interoperability, and operationally effective end-to-end information exchanges which are traceable to their associated operational context, and are measurable, testable, and support efficient and effective T&E.

  • The NR KPP identifies operational, net-centric requirements in terms of threshold and objective values for MOEs and MOPs. The NR KPP covers all communication, computing, and EM spectrum requirements involving information elements among producer, sender, receiver, and consumer. Information elements include the information, product, and service JCIDS Manual 12 February 2015 D-E-3 Appendix E Enclosure D exchanges. These exchanges enable successful completion of the warfighter mission or joint business processes.
  • The NR KPP includes three attributes derived through a three step process of mission analysis, information analysis, and systems engineering. These attributes are then documented in solution architectures developed according to the current DODAF standard.
    • Attribute 1: Supports military operations
    • Attribute 2: Is entered and managed on the network
    • Attribute 3: Effectively exchanges information

The most recent JCIDS Manual added a Certification Guide for the Net-Ready KPP (NR KPP) and expanded the Content Guide for the NR KPP to include the majority of the content from CJCSI 6212.01F, "Net Ready Key Performance Parameter (NR KPP)". Remaining content from CJCSI 6212.01F related to roles and responsibilities is consolidated into CJCSI 5123.01G, "Charter of the Joint Requirements Oversight Council".

CH 6–3.8.2 Interface Design and Management

One of the most challenging aspect of IT system development in DoD deals with system interfaces. In a net-centric environment, the shift is to a "many-to-many" exchange of data, enabling many users and applications to leverage the same data-extending beyond the previous focus on standardized, predefined, point-to-point interfaces. Hence, the objectives are to ensure that all data are visible, available, and usable-when needed and where needed-to accelerate decision cycles. Many-to-many exchanges of data occur between systems, through interfaces that are sometimes predefined or sometimes unanticipated. Metadata is available to allow mediation or translation of data between interfaces, as needed.

PMs should have written agreements (e.g., service-level agreements (SLA) and interface control agreements (ICA)) with any interface partners (i.e., such as between DFAS-DLA, or among the Air Force, Army, Navy, and DFAS) that indicate the agreement made and document the requirements for the subject program and those programs necessary for information support. These agreements need to be published/registered in the DoD-approved registry as outlined in the Department of Defense Net-Centric Services Strategy, DoDI 8320.02, and DoDI 8320.07). See CH 3 Section 2.3 for more information.

Typically, these interface dependencies will be documented in Information Support Plans (ISPs) for both System A (the information recipient) and System B (the information provider) though could be documented differently depending on the program’s document tailoring strategy. More information on the interface management process is located in CH 4 Section 4.1.8.

CH 6–3.8.3 Modeling & Simulation

DoD Directive 8000.01, "Management of the Department of Defense Information Enterprise (DoD IE)" encourages pilots, modeling and simulation (M&S), experimentation, and prototype projects, appropriately sized to achieve desired objectives, and not be used in lieu of testing or acquisition processes to implement the production version of the information solution. This concept equally applies to IT systems, which may pilot and prototype differently than weapons systems but may find it just as beneficial.

M&S tools can be used by multiple functional area disciplines during all life-cycle phases. Modeling is essential to aid in understanding complex systems and system interdependencies, and to communicate among team members and stakeholders. Simulation provides a means to explore concepts, system characteristics, and alternatives; open up the trade space; facilitate informed decisions and assess overall system performance.

The Director, Systems Analysis within the Office of the Deputy Assistant Secretary of Defense for Systems Engineering guides the M&S community. More detailed M&S procedures are described in detail in CH 3 Section 2.4.2. Another resource is the DoD Modeling and Simulation Coordination Office, or M&SCO. M&S specific to test and evaluation is located in CH 8 Section 3.7.7.

CH 6–3.9 Enterprise Services

The DoD CIO is accelerating and synchronizing efforts that create enterprise-wide capabilities and Enterprise Services while eliminating the unnecessary duplication of capabilities. With this department’s rapid movement towards an enterprise cloud environment, use of enterprise services should be ubiquitous. Program managers and SEs should consider the use of available enterprise services as part of software development. Use of an enterprise service that is available across an enterprise is intended to increase interoperability and reduce cost for the program.

All IT services must be cataloged in the DoD approved registry in order for DoD to understand the breadth and inventory available on and to the enterprise information environment. For registry information contact DoD CIO A&E or IE/EC.

CH 6–3.9.1 Joint Information Environment

DoD, through the CIO’s Strategy for Implementing the Joint Information Environment (JIE) is transitioning to a single, joint, secure, reliable and agile command, control, communications and computing (C4) enterprise information environment.

The JIE is a construct that facilitates the convergence of the DoD’s multiple networks into one common and shared global network. The intent is to provide enterprise services such as email, Internet/Web access, common software applications, and cloud computing. Primary objectives behind this transition are increased operational efficiency, enhanced network security and cost savings through reduced infrastructure and manpower.

The JIE is a fundamental shift in the way the DoD will consolidate and manage IT infrastructure, services, and assets in order to realign, restructure, and modernize how the Department’s IT networks and systems are constructed, operated, and defended. JIE will consolidate and standardize the design and architecture of the Department’s networks. The JIE represents the DoD migration from military service-centric IT infrastructures and capabilities, with their mixture of disparate networks and applications, to enterprise capabilities based on common infrastructure and shared services to support Joint needs. These needs include networks, security services, cyber defenses, data centers, and operation management centers. Consolidation and standardization will result in a single, reliable, resilient, and agile information enterprise for use by the joint forces and mission partners. The key attributes of the JIE include:

  • Shared JIE technology infrastructure: a network that is defendable and virtually accessible from any location globally, strategic to tactical locations; DoD level consolidation of data centers and network operations centers; a single security architecture; and the use of enterprise services.
  • The JIE infrastructure will look, feel and operate by common standards regardless of service provider and/or use (i.e., mission specific utilization) and will apply common tactics, techniques and procedures developed at the enterprise level.
  • Capabilities required across DoD to enable information sharing, collaboration and interoperability will be provisioned as enterprise services. Email, Web access, mass data storage and data analytics for decision support will be provided to any access point.
  • The JIE effort does not preclude the Navy, for example, or any other Service from becoming a service provider for one or more designated enterprise services or infrastructure capabilities. As such, the Navy could be called upon to support the provisioning of enterprise service(s) for the entire DoD.
  • Services and Agencies are beginning to adopt JIE standards for existing programs of record and adapt to JIE standards and requirements in future IT modernization.
  • Services and Components that operate and maintain portions of the shared IT infrastructure (i.e., switches, servers, routers, etc.) will do so in accordance with the appropriate IT Technical Authority through the Joint Information Environment Technical Synchronization Office (led by the Defense Information Systems Agency), and with operational direction provided by U.S. Cyber Command.
CH 6– Joint Regional Security Stacks (JRSS)

DISA’s joint regional security stacks (JRSS) represents a single security architecture; it constitutes a suite of equipment that performs firewall functions, intrusion detection and prevention, enterprise management, virtual routing and forwarding (VRF), and provides a host of network security capabilities. JRSS is a cornerstone of JIE implementation and part of a larger modernization effort to upgrade the bandwidth capacity of the Defense Information Systems Network (DISN). Installation is in progress at ten of the eleven JRSS sites planned in the continental United States (CONUS) and five sites planned outside CONUS (OCONUS). JRSS familiarization training is available through DISA. The benefits for PMs and other implementers of IT are as follows:

  • JRSS offers increased visualization into the network. Deploying JRSS enables the department to inspect data, retrieve threat and malware data on the network and troubleshoot, and then patch, protect, and defend the network.
  • JRSS will improve the effectiveness and efficiency of the network by ensuring that there is sufficient capacity to support the transition of services and capabilities from being hosted locally by the military departments.
  • JRSS will support the concepts of the JIE and specifically will reduce duplication of security standards.

CH 6–3.9.2 Cloud Computing

Commercial cloud vendors provide commercial virtual data storage and computing capabilities which are typically more efficient and innovative solutions when compared to traditional approaches; consequently, cloud should be considered and employed when found to be cost effective and secure.

Cloud is a service and is delivered by Cloud Service Providers (CSPs) who provide a set of capabilities referred to as cloud service offerings (CSOs).

A formal definition of Cloud is provided in the National Institute of Standards and Technology (NIST) in their special publication (SP) 800-145, which states: “Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.” SP 800-145 al describes three “service models”, four “deployment models,” and five “essential characteristics” a Service should exhibit in order to be considered a cloud service.

As applications and capabilities are moved to the Cloud, PMs can select CSOs that are offered in the models and with the characteristics defined by NIST:

NIST-defined Service Models:

  • Infrastructure as a Service (IaaS): Processing, storage, networks, and other fundamental computing resources. Purchaser generally still has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls).
  • Platform as a Service (PaaS): Applications created using programming languages, libraries, services, and tools supported by the CSP. (This capability does not necessarily preclude the use of compatible programming languages, libraries, services, and tools from other sources.) The purchaser does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.
  • Software as a Service (SaaS): Applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email), or a program interface. The purchaser does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

NIST-defined Deployment Models:

  • Public cloud infrastructures operate in a multi-tenant environment whose resources are allocated for the general public. Public clouds tend to be large and provide economies of scale for their customers. However, security and privacy concerns are heightened because any individual or organization can potentially access the same cloud infrastructure.
  • Private cloud infrastructures are operated only for an individual organization. The organization can leverage the scalability and performance aspects of cloud computing, but the infrastructure is isolated from that of other organizations, improving security and privacy. Because of their specialized nature, private clouds can be just as costly as dedicated data centers.
  • Community cloud infrastructures are private clouds provisioned for a specific community of interest with shared concerns, such as a government-only cloud.
  • Hybrid cloud infrastructures are combinations of any two or more of the other cloud infrastructures.

The NIST-defined essential characteristics are: on demand self-service, broad network access, resource pooling, rapid elasticity, and measured service; a description and explanation of use follows in the next section.

In the past, DoD Components have used inconsistent interpretations of NIST’s essential characteristics to determine if a given Service should be considered a cloud service. To improve consistency and aid in making this decision, the DoD CIO has established objective and threshold criteria. PMs should, at a minimum, use the threshold criteria when making a cloud characteristic assessment.

Note: CSOs listed on the DISA maintained DoD Cloud Service Catalog have already been determined to be a cloud service and do not require characteristic assessment.

NIST Defined Essential Characteristic:

  • On-demand self-service: SP 800-145 states, “A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.”
    • Threshold: The consumer uses an automated interface to request and track the service, but the provider may use manual processes to provision the service internally. Rather than an individual, the consumer can be a DoD organization that governs provisioning of the cloud service to their individual users.
    • Objective: Fully automated service provisioning.
  • Broad network access: SP 800-145 states, “Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, and workstations).”
    • Threshold: Available over a network that is accessible from the access points required by a DoD Component.
    • Objective: Available over the Internet or the DISN as required by the Component IAW DoD policies
  • Resource pooling: SP 800-145 states, “The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, and network bandwidth.”
    • Threshold: The capability to serve multiple tenants exists, regardless of how many tenants are actually served.
    • Objective: Two or more consumers can securely share resources using a multi-tenant model.
  • Rapid elasticity: SP 800-145 states, “Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.”
    • Threshold: Resource allocation modification is not fully automated, but fast enough to meet a Component’s projected usage rate while minimizing the need to pay for underutilized service. Components can govern use to ensure it does not exceed the financial, and other resources, obligated to the service.
    • Objective: Resource allocation modification is automated and near-real-time.
  • Measured service: SP 800-145 states, “Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.”
    • Threshold: The computing capability can meet the continuous monitoring requirement specified in the DoD Cloud Computing Security Requirements Guide (CC SRG) and resource usage is measured with enough detail to support a Component’s requirements
    • Objective: The computing capability employs an automated metering capability to automatically control and optimize resource use.
CH 6– Interpreting Cloud Policy and Guidance

DoD Cloud Computing Security Requirements Guide (CC SRG) was built upon the Risk Management Framework (RMF) for DoD Information Technology to integrate with the DoD RMF Authorization Process and Office of Management and Budget (OMB) policy regarding federal government use of cloud computing. The RMF is described in DoD Instruction 8510.01, “Risk Management Framework”.

The CC SRG is an essential guide to identify the cybersecurity controls and information impact levels (IILs) for hosting DoD missions in CSOs up to and including SECRET, based on the type of data to be hosted in the CSO. The CC SRG establishes the baseline security requirements for DoD PMs and their Authorizing Officials (AOs) and must be followed when contracting for and implementing systems and applications using DoD and non-DoD CSOs regardless of service or deployment models. The CC SRG also identifies the roles and responsibilities that DoD Mission Owners, PMs, CSPs, and the DoD PM’s Cybersecurity Service Provider (CSSP) play in operating and securing cloud hosted systems. DoD PMs that offer DoD owned and operated cloud services are subject to the same regulations as all DoD information systems, and must comply with the DoD CC SRG.

DISA is the Department’s Risk Management Executive and uses the CC SRG to oversee the required DoD cybersecurity assessment of a CSP’s CSO that results in the issuance of a DoD Provisional Authorization (DoD PA). The DoD PA is an assessment indicating that the CSO is potentially suitable for use up to an indicated impact level as defined within the CC SRG.

The DoD CC SRG applies to all DoD Components when using cloud computing services provided by a DoD or non-DoD CSP and should be referred to and complied with when deciding to acquire, use, and/or implement any application, system, or service that utilizes cloud computing services. The CC SRG may be found at Always refer to the latest version of the CC SRG.

DFARS Subpart 239.7 – Cloud Computing Rule implements policy developed within the DoD CIO and the CC SRG for the acquisition of cloud computing services. The provision 252.239-7009, “Representation of Use of Cloud Computing,” must be used in solicitations for information technology services. This allows the offeror to represent their intention to utilize cloud computing services in performance of the contract or not. The clause 252.239-7010, “Cloud Computing Services,” must be used in solicitations and contracts for information technology services. This provides standard contract language for the acquisition of cloud computing services, including access, security, and reporting requirements.

The DFARS states, that the contracting officer should only award a contract to acquire cloud computing services from any CSP (e.g., contractor or subcontractor, regardless of tier) that has been granted a DoD PA with two exceptions: (a) DoD CIO waiver the requirement or (b) CSO is hosted in a DoD facility and has DoD PA prior to operational use.

DoD PMs must provide the Contracting Officer all detailed requirements associated with this clause and others that need to be included in the purchase request when contracting for CSOs.

Additional policy and guidance that must be followed when acquiring and implementing cloud services include:

  • DoD Memorandum, "Updated Guidance on the Acquisition and Use of Commercial Cloud Computing Services," December 15, 2014 that enumerates DoD Component responsibilities when acquiring commercial cloud services
  • DoD Instruction 5000.74, “Defense Acquisition of Services”, January 5, 2016, Enclosure 7 identifies IT considerations in the acquisition of IT services that includes Cloud services.
CH 6– Cloud Service Acquisition Process Steps

There are four major inter-related steps to follow when acquiring cloud services for the DoD.

Step 1: Determine Appropriate Information Impact Levels (IIL) and Categorize Mission and Data Risk.

When acquiring cloud services, DoD PMs need to consider both the impact of data loss/compromise (security) and the priority of the service relative to the primary mission of the DoD (Mission Impact). The focus is on the CSO not the provider of the service who may offer services that are eligible at different information impact levels. The following provides a summary of the four information impact levels defined in the CC SRG coupled with some of the distinguishing requirements and characteristics:

  • IIL-2. The system processes DoD information that has been cleared for public release; information that has been released through the Freedom of Information Act (FOIA); and information available to the public even if it requires a login. Level 2 applies to non- NSS only.
  • IIL-4. The system processes DoD Controlled Unclassified Information (CUI) (i.e., For Official Use Only (FOUO), Moderate and Sensitive Personally Identifiable Information (PII) (i.e., social security numbers, alien ID and other immigration documents, passport numbers, driver’s license numbers, vehicle identification numbers, and license plates), Non-Appropriated Fund (NAF) data, and other non-CUI mission critical systems that are not NSS systems.
  • IIL-5. The system processes CUI requiring higher protection, mission essential, critical infrastructure (military or civilian), deployment and troop movement, International Traffic in Arms Regulation (ITAR) data, or unclassified nuclear data. It also includes highly sensitive PII which could include Protected Health Information (PHI), law enforcement, and other data that contains sexual assault information.
  • IIL-6. Level 6 accommodates information that has been determined: (i) pursuant to Executive Order 12958 as amended by Executive Order 13292, or any predecessor Order, to be classified national security information; or (ii) pursuant to the Atomic Energy Act of 1954, as amended, to be Restricted Data (RD). Only information classified as SECRET, in accordance with the applicable executive orders, is applicable to this level.

Mission risk relates to the information system and functions for which a DoD entity acquires or uses a CSO for that specific mission. Mission Owners categorize mission systems and/or applications in accordance with DoDI 8510.01 defined processes. This may be the direct use of a SaaS CSO in performing an IT-enabled mission, or the instantiation of an IT system or application on an IaaS/PaaS CSO. Data risk relates to the CSO’s ability to meet specific IIL security controls identified in the CC SRG.

Step 2: Identify Approved CSOs and Roles and Responsibilities.

Once the DoD PM and their AO determines what types of cloud services are to be acquired (IaaS, PaaS, or SaaS) and the Information Impact Level the CSP needs to support, the appropriate cloud service alternatives can be evaluated based on: mission requirements; BCA or other cost analysis processes; and cybersecurity requirements as specified within the CC SRG.. DoD PMs then select CSOs based on their security posture and the risk tolerance of the PM and their AO. Always use a CSO that has been granted a DoD PA at the appropriate IIL for their mission information to be processed or stored in the CSO, or meet the exception criteria identified in the DFARS clause. The PM should identify existing approved CSOs that have a current PA from DISA by referring to the DoD Cloud Service Catalog (CAC required to access).

Figure 8 compares a traditional (On-premise) data center model, where the DoD, is responsible for providing all the IT infrastructure and software components, to the three NIST Service Models where the CSP is responsible for providing the IT infrastructure and software components. Note how the responsibility shifts from cloud service consumer (DoD) to cloud service provider (CSP) for the three Service Models.

Figure 8: Cloud Computing Services Models Overview and Responsibilities

Figure 6: Cloud Computing Service Models Overview and Responsibilities

Moving to the cloud underscores the need for PMs to understand the distinction between what is and is not provided and addressed by the CSP. DoD PMs need to clearly identify roles and responsibilities as they will vary depending on the service model as illustrated in Figure 6 above. Therefore, a fundamental consideration for DoD PMs should be determining the appropriate contractual relationships between all parties to ensure that mission capabilities can be met from a holistic systems view

Guidance/support may be needed for migrating applications to cloud services as PMs execute their IT modernization strategies. DoD PMs need to coordinate their planned acquisitions or use of commercial cloud services with their respective ‘cloud support’ organizations:

Step 3: Ensure Cyber Defense

DoD PMs that acquire or use cloud services remain responsible for ensuring end-to-end security and protection of their system/application in accordance with the CC SRG. As the DoD strives to maximize the use of commercial cloud computing, the DoD Information Network (DODIN) perimeter must continue to be protected against cyber threats originating from external sources.

DoD PMs ensure that secure network connections are in place by:

  • Securely connecting all approved CSOs processing or hosting unclassified DoD Information at IIL-4 or II-5 that are not private DoD clouds (restricted DoD-only) to the appropriate DoD network via a DoD CIO approved cloud access point (CAP)/network boundary cybersecurity defense mechanism in order to ensure that the cybersecurity posture of the DoDIN is not compromised
  • Connect approved CSOs hosting unclassified, publically releasable information and low-impact systems/applications (IIL-2) to the Internet, subject to compliance with personnel requirements and other security and integration requirements.

DoD PMs and their AOs must ensure that prior to transitioning to a CSO, a supporting Cyber Defense Service Provider (CSSP) has been identified and confirmed; and the required monitoring capabilities must be functional prior to operational use, in accordance with DoDI 8530.01, “Activities Support to DoD Information Network Operations,” March 7, 2016

Step 4: Cloud Service Registration and Reporting

DoD PMs must report their cloud computing activities as follows:

  • Registration in SNAP: DoD PMs must register all CSOs that they plan on acquiring or are using, regardless of IIL or the network connection or CAP requirement, in the DISA System Network Approval Process (SNAP) system in the Mission Owner (Cloud IT Project) Module available at
  • Registration in DITPR: DoD PMs must register use of the CSP’s CSO in the DoD Information Portfolio Registry (DITPR).
  • Investment Reporting via SNaP-IT: Program Managers must analyze cloud computing options and report cloud service funding investments during the course of DoD budget and acquisition processes for each CSO as follows:
    • Ensure that an investment line item has been created in Select and Native Programming Data Input System – Information Technology (SNaP-IT) for each investment in a CSO;
    • Report all funding related to cloud computing by Deployment Model and Service Model for the Prior Year, Current Year, and Budget Year


CH 6– Contracting for Cloud Services

Contracting for commercial CSOs brings additional risks and concerns that could adversely affect the mission but may not be apparent and are not typically addressed in traditional contracting best practices. For example, typical vendor contract terms and conditions may not be detailed enough concerning items that are expected to be encountered once operations and services begin, i.e., operations, maintenance, and the cybersecurity of the DoD system residing in the CSO. Other concerns include ensuring that the Inspector General and Law Enforcement are able to perform their responsibilities. Each DoD PM should coordinate with their legal counsel, privacy, and procurement offices when they move IT services to the commercial cloud, and ensure compliance with Federal Records Management, and other OMB and DoD requirements.

Identifying and determining risk is an integral factor in cloud contracting decisions. Cybersecurity (relative to cloud) is concerned with risks to the DODIN (CSO/DODIN risks) and risks specific to a mission and its data (CSO/mission risk). The CC SRG is the primary source governing the selection, accreditation, and ongoing accreditation and use of cloud services within the DoD. Although the CC SRG is quite comprehensive, the DoD PM must take the time to comprehend it in order to determine if additional requirements need to be reflected in the service-level agreement (SLA) or contract.

Initial decisions regarding CSO/DODIN risk are normally made through the DoD PA assessment and authorization process. Ongoing adherence to the CC SRG is periodically reviewed and the CSO’s network behavior is being continuously monitored in order to identify if there is an increase in CSO/DODIN risk; the DoD PA and/or access to the CSO may be terminated depending on the severity of risk.

Initial decisions regarding CSO/mission risk are made through the mission owner’s agency ATO process. Remember, a CSO with a DoD PA does not eliminate the requirement for a given application using the CSO to have an ATO (or IATT) prior to commencing operations. For example, prior to contract award the AO should review DoD PA artifacts to understand the risks that the mission may inherit and request that compensating controls be implemented by the CSP prior to obtaining an ATO. The compensating controls must be reflected in the SLA/contract as well as processes to assure they remain valid.

Therefore, it is essential that DoD PMs determine exactly what they are responsible for as well as the roles and responsibilities of all other stakeholders that may include the CSP, the Contractor if not the CSP, Sub-contractor, an outsourced 3rd party integrator or CSP, cybersecurity personnel, or other entities. DoD PMs must fully understand, describe and negotiate their key expectations and ensure that they are specifically addressed in the contract/Task Order (TO), Acquisition Plan, Contract Performance Work Statement (PWS) or SLA for cloud computing contracts.

PMs and appropriate staff should become familiar with the DFARS Subpart 239.76 (Cloud Computing), and the associated DFARS 252.239-7009 Provision and DFARS 252.239-7010 Clause, the supporting Procedures, Guidance and Instructions (PGI) 239.76 – Cloud Computing and the CC SRG.

Table 5, “Information and/or actions required for DoD PMs” should be read in conjunction with the DFARS subpart, provision and clause, PGIs and the CC SRG. It identifies the specific information and/or requirements the PM needs to provide the Contracting Officer (CO) to enable the CO to execute a contract that protects DoD equities and minimizes risk. In addition, activities that require PM coordination and risk assessment decisions with the PM’s AO or other DoD entities are identified.

Table 5: Information and/or actions required for DoD PMs


Information and/or actions required for DoD PMs

General Procedures for Cloud Services

  • Determine Information Impact Level (IIL) as detailed in the CC SRG.
  • Provide written justification as needed by CO.

Government Data & Government-Related Data

  • Identify, document, and provide CO with unambiguous descriptions and formats of Government data and Government-related data need to enforce all terms in clause where, “Government data and Government-related data” are referenced in DFARS 252.239-7010.
  • These descriptions and formats of Government data and Government-related will be required by CO.

Security Requirements –

Change in Representation

DFARS 252.239-7010 (b) (1)

  • Post contract award; if the contractor notifies the CO of a change in DFARS Provision 252.239-7009 then, it is likely that the entire approach will require reevaluation.
  • In collaboration with AO, reevaluate the proposed approach and determine if the change is acceptable.
  • Provide written notice and/or justification to support approval or disapproval decision to CO.

Security Requirements –


DFARS 252.239-7010 (b) (2)

  • Collaborate with AO and DoD CIO to determine and document what specific requirements of the CC SRG may/have been waived.
  • Provide CO with necessary documentation needed to specify extent and conditions of the DoD CIO waiver.

Location of Data –

DFARS 252.239-7010 (b) (3)

  • Collaborate with AO to determine (only for Level 2 or Level 4 data) if it is permitted to maintain Government data at a location outside the 50 States, the District of Columbia, and outlying areas of the United States.
  • Provide written justification as needed by CO.

Limitations on Access, Use and Disclosure

DFARS 252.239-7010 (c) (1)

  • Collaborate with AO to review and determine and unambiguously document if any access to or use of Government Data or Government-related Data requested or specified by contractor is permissible and if so under what limitations and/or conditions.
  • Provide CO with documentation authorizing access.

Cyber Incident Reporting

DFARS 252.239-7010 (d)

  • Identify a Government point of contact (POC) for CO to contact if a cyber-incident occurs in connection with the cloud computing services being provided.

If a cyber-incident occurs:

  • Procedures should be developed (to include, Mission Owner, Cybersecurity Service Provider (CSSP), and Contractor) to collect, preserve and protect Incident Information; these processes will vary depending on service model (IaaS, PaaS and SaaS).
  • With the AO, CSSP, and the Contractor, assess and determine the potential impact of the cyber incident and response.

Malicious Software

DFARS 252.239-7010 (e)

  • Collaborate with AO and other DoD entities to produce detailed instructions on submitting malicious software that was/may-have-been discovered in connection with a reportable cyber incident.
  • Provide the CO with the specific instructions produced.

Cyber Incident –

Requesting Media and Data

DFARS 252.239-7010 (f)

  • Collaborate with AO and other DoD entities to determine if the media that was preserved and/or the data that was collected (when a cyber-incident was discovered) are required by the DoD.
  • If required, instruct CO to request media and data from the contactor

Cyber Incident –

Access to Information or Equipment

DFARS 252.239-7010 (g)

  • Collaborate with AO and other DoD entities to determine if access to additional information or equipment is needed to conduct forensic analysis.
  • If needed, instruct CO to request access to additional information and/or equipment.

Cyber Incident –

Damage Assessment

DFARS 252.239-7010 (h)

  • Collaborate with AO and other DoD entities to determine if damage assessment is required.
  • If damage assessment is required, inform CO to request damage assessment information from contractor.
  • Upon completion of damage assessment activities, provide the CO with a report documenting all findings that will be included in the contract files.

Records Management and Facility Access

DFARS 252.239-7010 (i)

  • When acquiring SaaS, provide a records retention schedule to the CO to be incorporated in the contract that includes, but is not limited to, secure storage, ability to retrieve, and proper disposition of all federal records.
  • When acquiring IaaS/PaaS, maintain a copy of the Contractor’s and/or CSP’s records retention policies for Government related data.

Records Management –Format of Data

DFARS 252.239-7010 (i) (1)

  • Collaborate with AO and all other related DoD stakeholders to provide the CO with unambiguous description of formats of Government data and Government-related data needed to enforce the terms in clause.

Records Management –Contract Closeout

DFARS 252.239-7010 (i) (2)

  • Collaborate with AO and, if necessary, the Component Records Management Officer (CMRO), to determine how Government Data and Government-related data is to be handled during contract closeout.
  • Provide CO with unambiguous description of how contractor is to transfer, retain, or dispose and confirm disposal of Government Data and Government-related data as part of contract closeout needed to enforce the terms in clause.

Records Management – Required Accesses to …

DFARS 252.239-7010 (i) (3)

  • Collaborate with AO and all other stakeholder DoD entities to identify and ensure that all Government or its authorized representatives have determined and documented what physical, system, and/or system-wide accesses and response timeframes the contractor will need to provide in order to support their lawful activities.
  • Provide CO with unambiguous description of all accesses and timeframes required in the contract/SLA.

Notification Of Third Party Access Requests

DFARS 252.239-7010 (j)

  • Identify the government point of contact (POC) responsible for coordinating the response to any subpoena or other third party access received by the contractor providing the cloud service.
  • Provide CO with the government POC.

If third party access request is received:

  • Coordinate the response with the DoD mission or data owner.


DFARS 252.239-7010 (k)

  • Identify the contractor POC and government POC to contact if any spillage occurs regarding the cloud service being provided.
  • Provide CO with the POCs and procedures needed to enforce the terms in clause.
  • Ensure that agency procedures for addressing a spillage are documented.

If spillage occurs:

  • Follow agency procedures.


DFARS 252.239-7010 (l)

  • Provide CO with requirements related to flow down when contracting for PaaS or SaaS which leverages an IaaS or PaaS from a third party CSP

Contractor Terms And Conditions - Terms Of Service

Subpart 239.7601-1 (a)

  • Collaborate with AO to review contractor’s Terms of Service and produce document detailing where they may be found to impede or conflict with mission and cyber security requirements.
  • Provide CO with the document to ensure conflicts are resolved as part of the other processes the CO needs to perform in order to meet the intent of this Subpart.

Inspection, Audit, Investigation Support

Subpart 239.7601-1 (c) (3)

  • Provide CO with requirements to support authorized activities regarding Government Data or Government-related Data, or CSO service model.

Inspection, Audit, Investigation Search & Access

Subpart 239.7601-1 (c) (4)

  • Provide CO with requirements to support and cooperate with authorized activities’ system-wide search and access.

Other Consideration –

Cybersecurity Compliance


  • Collaborate with AO to ensure that cybersecurity requirements or processes not otherwise addressed in the CC SRG and DoD PA assessment are documented. DoD PMs must ensure that issues identified throughout the life of the contract that may adversely impact CSO/mission risk, and thereby jeopardize the validity of the ATO, are addressed in the contract/SLA. For example, if DISA discovers that the CSP is not meeting on-going security requirements they will notify affected Mission Owners/PMs and work with the CSP to develop a corrective Plan of Actions and Milestones (POA& M).
  • Review DISA's assessment of the Contractor's corrective POA&M.
  • Collaborate with AO to make a risk determination with regard to their specific usage of the CSO and ATO.
  • Collaborate with AO and CO to determine if contracting action to incorporate the CSP’s POA&M is needed; annotate contract files as needed.

Change In CSP Ownership


  • Collaborate with AO to determine how to address the impact of a change of ownership of the CSP. If such change necessitates off-boarding and retrieval of information/data, produce document that describes how the Contractor is to transfer, retain, or dispose and confirm disposal of Government Data and Government-related data.
  • Provide CO with the document so that off-boarding processes can be reflected in the contract/SLA.

Disaster recovery (DR) and Continuity of Operations (COOP)

  • As a best business practice, require that the Contractor (CSP or third party) plans for Disaster Recovery (DR) and Continuity of Operations (COOP) and implement their infrastructures to support it

Exit Process

  • Provide CO with unambiguous document describing how contractor is to transfer, retain, or dispose and confirm disposal of Government Data and Government-related data and/or migrate applications upon completion or termination of the contract.
  • Provide CO with the document so that close-out processes can be reflected in the contract/SLA.

In addition to the specific information and/or activities previously identified that DoD PMs need to provide, there are other considerations that could adversely affect the mission. Table 6, “Contracting Considerations for DoD PMs” details areas that should be included in any risk calculus, as well as the cost/benefit tradeoffs and risk analysis that have been identified by developing the business case analysis.

Table 6: Contracting Considerations for DoD PMs


Contracting Considerations for DoD PMs


  • Banner language provides consent for the Department to view any content on the system without a warrant
  • When acquiring software as a service, consider requiring the CSP to display DoD’s approved banner language prior to allowing a user access to the system

Direct Contractual Relationship

  • Contractual liability to the government only exists with the prime contractor. When the DoD PM acquires a commercial service through an intermediary (e.g., system integrator, value added reseller), only the intermediary is accountable to the government. This reduces the contractual liability to the CSP acting as the subcontractor, but increases the risks to the government.

Exit Strategy and Plan

  • Consider developing an interoperable strategy to move systems/applications from one CSP to another


  • Consider requiring the CSP to indemnify the government against lawsuits; this protects the government when third parties sue the government for a tort when the CSP, not the government, was liable.


  • Consider requiring a CSP to use insurance services to pay for any costs stemming from a breach of DoD data (e.g., PII or PHI) or to replace any damages to the DoD system, including credit monitoring

Ownership Rights

  • Consider if any third party will own any aspects of assets that are applied for service provisioning


  • Consider whether a training and change management program might be needed to optimize implementation of security and cyber defense changes


DoD PMs should negotiate required service levels and expected performance with a key objective to reduce areas of potential conflict. Responsibilities and the appropriate support levels to meet requirements related to operations and maintenance of the environment, system management and administration services, logistics, performance, reliability/back-ups and disaster recovery functions should be clearly defined. DoD PMs should identify appropriate specific service level requirements and performance expected from a provider, how that performance will be measured, and what enforcement mechanisms will be used to ensure the specified performance levels are achieved in a SLA.

Table 7, “Requirements to be incorporated into SLAs” identifies the key requirements to be incorporated in DoD Cloud Contract SLAs, to help ensure the Contractor (and the CSP) meet the DoD’s contract objectives and CSOs perform effectively, efficiently, and securely:

Table 7: Requirements to be incorporated in SLAs


Requirements to be incorporated in SLAs

Roles And Responsibilities

  • Define roles and responsibilities for the DoD, CSP, Contractor, Sub-contractor, 3rd party integrator or others to include:
    • PMs, PM’s System Administrators
    • NetOPS/Tier 2 & 3 support
    • PM’s Cybersecurity (CS) entities, Cybersecurity Service Providers (CSSPs- Mission & Boundary CS)
    • CSPs CS entities, Trusted Internet Connection (TIC) support
    • CSP’s or Contractor Audit or Forensic support
    • Contractor’s Operations and Maintenance support


  • Provide a glossary of the key terms to supplement DFARS and CC SRG definitions to include continuity, outage, emergency, planned outage, unplanned outage, high availability, recovery, breach of service agreement, and other terms related to service performance and service reliability


  • Identify the dates when the contract/SLA is active or when measurement of the SLA will begin


  • Provide a list of the accessibility standards, policies and regulations that must be met by the service


  • Identify availability requirements, e.g. percentage of time that the system or data will be available and usable

Data Location

  • Data location – list the geographic locations that data may be processed and stored, and if the Government can specify location requests

Data Examination

  • If the Government data is co-located with non-Government data, identify:
    • how the Contractor, and the CSP if not the Prime Contractor, will isolate the Government data into an environment where it may be reviewed, scanned, or forensically evaluated in a secure space
    • How access will be limited to authorized Government personnel identified by the CO, and without the Contractor’s involvement

Records Management

  • Records management – How and when the Contractor will retain or dispose of DoD records in the format specified as directed by the Contracting Officer

Protection Of Personally Identifiable Information (PII) And Personal Health Information (PHI)

  • Protection of Personally Identifiable Information (PII) is covered in the CC SRG. However, the table, “Privacy Overlay C/CE Not Included in FedRAMP M or FedRAMP+” identifies PII/PHI requirements that are not covered in the current DoD PA assessment.
  • In collaboration with the AO, define and produce document with requirements for the identified PII/PHI controls associated with: Access Control, Audit and Accountability, Security Assessment and Authorization; System Interconnections – Enhancement, Configuration Management, Incident Response, Media Protection, Personnel Screening, Risk Evaluations, System and Communications Protection, etc.
  • Provide CO with the document so that additional requirements can be reflected in the SLAs or contracts.

Information Security;

Security Performance

To Include: Data Protection, Continuous Monitoring / Vulnerability Management, Incidence Response

  • The DoD PA does not assess certain security controls/control enhancements (C/CEs) that are identified in the CC SRG (e.g. availability of information related to continuous monitoring, incident response, vulnerability management, etc.).
    • Define and produce document describing responsibilities associated with the identified C/CEs for Access Control, Audit and Accountability, Device Identification and Authentication Enhancement and System and Communications Protection.
    • Provide CO with the document so that identified responsibilities can be reflected in the SLAs or contracts.

Service Performance

To include: Capacity, Elasticity, Service Monitoring, Exception Criteria, Response Time

  • Identify Service performance measures with all responsible parties including those that are responsible for measuring performance. These should include capacity and capability of the CSO, elasticity, service monitoring, exception criteria, response time
  • Additional system quality measures for service performance include accuracy, portability, interoperability, standards compliance, reliability, scalability, agility, fault tolerance, serviceability, usability, durability, etc.

Service Reliability

To include: Resilience / Fault Tolerance, Backup & Restoration, Continuity of Ops

  • How Service reliability measures with all responsible parties are performed differs between IaaS, PaaS and SaaS services provided.
  • As appropriate to the cloud service model, specify requirements for service resilience, preservation, protection, and secure back up of all audit trails and transaction logs of the system/network operations
  • For SaaS providers, specify requirements for continuity of operations, and management of outages

Attestation, Certification, & Audits

  • Identify attestation and certification requirements to include FedRAMP Authorizations, DoD PA, and all requirements to comply with DoD policies

Exit Strategy

  • Identify exit details/procedures for ensuring continuity with minimal disruption in the case of exit/termination of service when catastrophe or failure to perform/early termination, or completion of contract occur to include:
    • The level of Contractor assistance in the exit process and any associated fees
    • How and when the DoD data and networks will transition back to the DoD
    • How the data will be transmitted and completely removed from the Contractor’s environment once the exit process is complete.


  • Identify a range of enforceable penalties and remedies, such as termination, for non-compliance with SLA performance measures. These penalties may be already included in FAR and DFAR standard clauses (i.e., Charge back approaches for unexcused performance failures)

CH 6–3.9.3 Internet Protocol Version 6 (IPv6)

Existing U.S. Government (USG) / DoD policy and the Federal Acquisition Regulation (FAR) require acquisition of Internet Protocol (IP) version 6 (IPv6) capable products and services. The IPv6 capable definitions, and associated terms stated below, require support for both Internet Protocol Version 4 (IPv4) and IPv6 (i.e. dual stack) and IPv6-only environments. Acquisitions must enable the necessary people, process and technology preparations to build and operationalize an IPv6-capable enterprise that needs to support IPv4 legacy capabilities with a limited lifecycle expectation. The Department’s IPv4 address space reserves must be retained due to requirements of our Warfighting platforms’ mission system modernization and replacement timelines.

The Department is committed to moving forward to adopt IPv6 within its networks to meet OMB and Federal Acquisition mandates and to achieve significant benefits of IPv6 Implementation. Implementing IPv6 is a Strategy Element in the Department’s Digital Modernization Strategy and supports the Joint Information Environment (JIE) Network Modernization capability objective. Access to DoD Information Network (DoDIN) applications or services will be accomplished via native IPv6 from within the DODIN, as well as access to native IPv6 Internet content from DoDIN workstations. All Component public-facing servers and services must be accessible and functional using IPv6 internet enabled platforms and devices.

DoD Components must execute the actions specified in the DoD Chief Information Officer’s (CIO) “Internet Protocol Version 6 Implementation Direction and Guidance memorandum” of February 27, 2019. DoD Program Managers/Requiring Activities (PMs/RAs) and Contracting Officers (COs) must actively advance DoD’s forward movement through precise and detailed IPv6 capable requirements and contract actions. DoD PMs/RAs are responsible for ensuring requirement documents fully address IPv6 requirements.

Contract Specialists/COs need to work with the PM/RA to ensure the acquisition of equipment, software and services that use IP comply with all IPv6 requirements.

CH 6– Background

IPv6 is the Internet's next-generation protocol, designed to replace IPv4 that has been in use since 1983. IP addresses are the global numeric identifiers necessary to uniquely identify entities that communicate over the Internet. Every computer, mobile phone, tablet, sensor and other networked device used by the Department needs an IP address to communicate with other devices and exchange data over the Internet. IP acquisitions can include the procurement of equipment (e.g., hosts, routers, electronic devices, and network protection devices), software and services, such as, those performed by an Internet Service Provider (ISP), commercial cloud or mobile device services.

There are fundamental limitations of IPv4 in meeting near/far-term DoD mission needs, as well as global exhaustion of unallocated IPv4 address space. The pace of IPv6 adoption is accelerating. Emerging IPv6-dependent technologies, such as 5G, smart infrastructure, and cloud services, are already leveraging IPv6 and will expand its applications and influence. With acceleration of the Internet of Things, the increasing proliferation of IP-addressable devices, including billions of IP-enabled mobile devices, this problem is becoming more acute. It is essential that the Department expand and enhance its strategic commitment to accelerate the operational deployment and use of IPv6.

CH 6– Definitions
  • IPv6 Capable Products - Products (whether developed by commercial vendor or the government) that can create or receive, process, and send or forward (as appropriate) IPv6 packets in Dual Stack environments. IPv6 Capable Products shall be able to interoperate with other IPv6 Capable Products on networks supporting IPv4 Only, IPv6-only, or Dual Stack.
  • IPv6 Capable Networks - Networks that can receive, process, and forward IPv6 packets from/to devices within the same network and from/to other networks and systems, where those networks and systems may be operating with IPv4 only, IPv6-only, or Dual Stack. An IPv6 Capable Network shall be ready to have IPv6 enabled for operational use, when mission need or business case dictates.
  • IPv6 Enabled Network - An IP network that is supporting operational IPv6 traffic, through the network, end-to-end.
  • IPv6/IPv4 Equivalency - Any function that is defined in the Internet Engineering Task Force (IETF) IPv4 standards and can be implemented on an IPv4 network, which is also defined in the IETF IPv6 standards and can be implemented on an IPv6 network with demonstrated connectivity, interoperability, security, and performance at least equal to, if not exceeding, that function on an IPv4 network. It requires a level of effort to acquire, implement, maintain, and operate that is expected to be less than, or at most equal to, that required to acquire, implement, maintain, and operate that function on an IPv4 network. (Network Address Translation (NAT) is an example of a function that is NOT defined in the IETF IPv6 standards.)
  • IPv4 only - An IPv4 only system or product is one that can process IPv4 packets and can receive from or forward IPv4 packets to other IPv4 Only and Dual Stack systems, but cannot process, receive, or forward IPv6 packets.
  • IPv6-only - An IPv6-only system or product is one that can process IPv6 packets and can receive from or forward IPv6 packets to other IPv6-only and Dual Stack systems, but cannot process, receive, or forward IPv4 packets.
  • Dual Stack (IPv6/IPv4) - A Dual Stack system or product is one that can process both IPv6 and IPv4 packets, receive from or forward IPv6 packets to other IPv6-only and Dual Stack systems, and receive from or forward IPv4 packets to other IPv4 Only and Dual Stack systems.
  • Native IPv6 - The transition to IPv6 without the use of translators, tunnels (IPv4 carrying IPv6). End users can communicate entirely via IPv6.
CH 6– IPv6 Benefits for DoD

IPv6 provides performance benefits, management efficiencies, and support for new capabilities and services. Benefits of IPv6 include reduced complexity and improved operational efficiencies and services, enterprise network performance and management. By reducing the size of routing tables, IPv6 makes routing more efficient and supports a simplified packet header that streamlines packet processing. IPv6 supports an integrated, well-architected networking platform. It also provides expanded address space, eliminates address conflict issues common under IPv4, and enables more streamlined connections. It also provides dynamic addressing for mobile forces and ad hoc networking and peer-to-peer (p2p) communication tools that can improve interagency collaboration.

CH 6– DoD and Federal IPv6 Policies and Guidance

DoD PMs/RAs and COs must consider a wide array of policies, guidance and references to be compliant and successfully implement IPv6 capable and IPv6-only products and services.

Table 8: DoD and Federal IPv6 Policies and Guidance



DoD CIO: Internet Protocol Version 6 Implementation Direction and Guidance memorandum,” February 27, 2019

Identifies DoD’s goal to provide secure and reliable IPv6 services in support of DoD missions. It provides the initial direction and guidance to reinvigorate preparations and planning to operationalize IPv6.

OMB Memorandum M-05-22, Transition Planning for Internet Protocol Version (IPv6), August 2005 and OMB Directive, Transition to IPv6, September 2010*

Federal guidance on the government’s IPv6 implementation with direct IPv6 actions identified to prepare for widespread IPv6 use and need.

* OMB is currently working on rescinding the “Transition to IPv6, September 28, 2010 Memo with a new Memo “Completing the Transition to IPv6”

OMB Memo M-17-06 Policies for Federal Agency Public Websites and Digital Services; Nov 8, 2016

Reiterates requirements for public/external facing servers and services upgrade to use native IPv6 and compliance with IPv6 FAR requirements for procurements of networked information technology

USGv6 Program

(update in progress)

The technical infrastructure (standards, testing, guidance and tools) necessary to support wide-scale adoption of IPv6 in the US Government (USG).

USGv6 Technical Standards Profile (NIST SP 500-267)

Set of protocol specifications published by Internet Engineering Task Force (IETF) for basic IPv6 functionality, specific requirements and key optional capabilities for routing, security, multicast, network management, and quality of service. NIST defined requirements for IPv6 aware firewalls and intrusion detection systems

USGv6 Test Program

(NIST SP 500-281)

Established testing infrastructure to enable testing IPv6 products for compliance, to profile requirements, for interoperability by accredited laboratories using standardized test methods, as well as NIST developed test and measurement tools

Guidelines for Secure Deployment of IPv6 (NIST SP 800-119)

Security guidance to organizations that are planning to deploy IPv6

Federal Acquisition Regulations – Case 2005–041, FAR IPv6 Final Rule (December 10, 2009)

Contract requirements for IPv6 acquisitions using the U.S. Government IPv6 (USGv6) Program to include use of the USGv6 Profile and Test Program for the completeness and quality of their IPv6 capabilities: FAR Part 11.02 (g) unless a granted a CIO waiver

FAR Requirement:

FAR 11.002(g) [Describing agency needs/Policy]

Requirements documents must include reference to appropriate technical capabilities defined in the USGv6 Profile (NIST Special Publication 500-267) and corresponding USGv6 Test Program (NIST SP 500-281) declarations of conformance unless a CIO waiver has been granted

In accordance with existing IPv6 FAR acquisition policy, DoD PMs/RAs and COs must:

  • Include explicit requirements for IPv6 capabilities in all acquisitions of common networked information technology and services. These requirements should be expressed using the USGv6 Profile (NIST Special Publication 500–267) and include the requirement to demonstrate compliance with those requirements through the USGv6 Test Program (NIST SP 500-281); and
  • Obtain DoD Chief Information Officer (CIO) written approval for any waiver from IPv6 requirements in cases which requiring demonstrated IPv6 capabilities would pose undue national security and cybersecurity risks on an acquisition action. In such cases, request documentation from vendors detailing explicit plans (e.g., timelines) to incorporate IPv6 capabilities into their offerings.

DoD PMs/RAs and contracting specialists must leverage the NISTv6/USGv6 profiles and USGv6 Test Program as a common basis for expressing procurement requirements and to conduct conformance and interoperability testing of commodity product to consensus standards. Further, acquisition specific testing should focus on detailed systems integration, performance and cybersecurity testing not covered in the USGv6 Test Program.

Additionally, DoD PMs/RAs and COs must ensure all acquisitions of IPv6 capable and IPv6-only products and services adhere to:



DoD’s IPv6 Address Plan V 1.2 of Sept 2017

DoD’s IPv6 Address Plan V 1.2 Sept 2017 to coordinate directly with the Network Information Center (NIC) to acquire and manage all respective IPv6 addressing resources, at

DoD Information Network (DoDIN) Approved Product List (APL)

DoD Information Network (DoDIN) Approved Product List (APL)

Security Technical Implementation Guidelines (STIG) and Security Requirements Guides (SRG)

Located on the DoD Cyber Exchange site for security requirements for all IPv6-capable devices, systems, services, and networks at for public access (non-FOUO docs), and for internal CAC access to (FOUO docs)

CH 6– Planning for IPv6 Capable and IPv6-Only Deployment

The Department is using an agile, discovery-learning approach to IPv6 capable and IPv6-only deployments. This iterative modernization approach is essential to ensure IPv4 dependencies are understood, while planning and executing IPv6 deployments. Although not an exhaustive list, the following are actions that DoD PM/RAs will need to consider to accelerate the operational deployment and use of IPv6, and plan for the phased retirement of IPv4.

  • Determine service offering requirements that contain IPv6 criteria (e.g. Software development, ISP, VPN, WAN, Cloud, Data Center Consolidation, Convergence, BYOD, Webhosting); identify opportunities for IPv6 pilots
  • Only purchase IPv6 capable products and services that have passed the USGv6 Testing process, unless they receive an advanced, written DoD CIO waiver
  • Determine the inventory of applications running on IPv4 that:
    • Are able to deploy but will need to be tested in IPv6 developmental and operational test environments for performance, interoperability and cybersecurity
    • Are moving to available DoD cloud environments; ensure all applications and systems migrated to commercially hosted cloud services are IPv6-only capable
    • Must be refactored requiring lengthy IPv4/IPv6 planning and testing
    • Will remain in consolidated data centers, Installation Processing Nodes (IPNs) or retired. A schedule for replacing or retiring these systems that cannot be converted to use IPv6 should be developed
  • IPv6-enable all commercially hosted public facing unrestricted services
  • Transition public-facing servers/services supporting networks and internal systems/applications/clients (e.g., Web, DNS, e-mail) to IPv6
  • Identify (ID) all Unrestricted, public-facing services (Web sites, Email, SMTP, FTP servers) hosted by commercial Cloud Service Providers (CSPs)
  • Conduct IPv6-enabled access tests for public-facing servers/services in both commercially hosted and DoD Data Center environments
  • Assess the IPv6 capabilities of Mobility program products (e.g., tablets, phones, apps) and replace any non-compliant products
  • Identify DoD hosted public facing unrestricted services and planned upgrades/updates and dependencies to enable IPv6
  • Ensure all applications and systems that have migrated to commercially hosted cloud services are IPv6-only capable; if provider limitations exist, obtain a resolution roadmap
  • Ensure new products provide equivalent IPv4/IPv6 capabilities. Factors that are needed to evaluate functional equivalence with IPv4 products include:
    • Planning and executing Dual Stack interoperability test and certification
    • Standards activities (Internet Engineering Task Force (IETF), IPv6 profiles, test equipment and test plans, and approved product lists, and test beds
  • Ensure that plans for full support for production IPv6-capable services are included in all IT security plans, architectures and acquisitions
  • Obtain the vendors’ Suppliers Declaration of Conformity (SDoC) to analyze their product’s IPv6 capabilities as captured on an SDoC. The SDoC is a legal document that specifies and certifies the product’s IPv6 capabilities. Perform an analysis between the IPv6 requirements and the product’s capabilities. Make sure your source selection teams know how to evaluate the SDOC and other vendor information when they receive a proposal, in accordance with the approved acquisition evaluation criteria.
  • Ensure that systems supporting security services (e.g., identity and access management systems, firewalls and intrusion detection/protection systems, end-point security systems, security incident and event management systems, access control and policy enforcement systems, threat intelligence and reputation systems) are IPv6 capable and capable of operating in IPv6-only environments
  • Verify existing cybersecurity systems provide equivalent IPv4/IPv6 capabilities and resolve gaps. Create Program Objectives Activities and Milestones (POA&Ms) for any unresolved gaps
    • Configure IPv6 support in the monitoring system. IPv6 has the same importance as IPv4, so any system that allows viewing the traffic quality, quantity, stability, visibility of their prefixes, etc. (either from inside or outside the network), must support both IPv4 and IPv6 with the same conditions
  • Identify all roles and responsibilities for execution and reporting problems for Network and Security operations that include:
    • Diagnosing network problems and broken functionality
    • Maintaining a security infrastructure (firewalls, Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS) devices or software applications that monitor the network or systems for malicious activity or policy violations, missing or non-functioning)
  • Identify required IPv6 Cybersecurity workforce training and certifications, gaps, and resources needed
  • Identify any additional resources required to support IPv6 acquisitions and incorporate into Program Objective Memorandum FY22 submissions. Refocus existing technology and technology-refreshment funds for the deployment and the POM process for future resources that will be needed to enable:
    • Planning, engineering, technical assessments, and training to execute IPv6 implementation and projected timelines; as well as the specific training and certification requirements to support a coherent IPv6 deployment
    • Pilot IPv6 deployments and IPv6 capable test beds necessary to minimize transition risks and demonstrate deployment readiness, including necessary infrastructure
    • Modifications to current development efforts to become IPv6 Capable
    • Selective equipment and/or software replacements/modifications where timely technology-refreshments are not programmed
    • Existing/new contracts that do not include explicit IPv6 capabilities requirements that will require resources to renegotiate and absorb potential additional costs for enabling IPv6 capability
  • Work with mission partners’ IPv6 deployment efforts and capability plans; leverage existing engagement forums where possible.
  • Leverage the General Services Administration’s (GSA) contracts for IPv6 capable equipment, applications, transition support, and integrated solutions. The GSA offers far reaching information on IPv6 that include sample contractual language found at:
CH 6– Defense Research and Engineering Network (DREN) IPv6 Successes

The DoD’s Defense Research and Engineering Network (DREN) has successfully demonstrated and continues to achieve IPv6 capable and IPv6-only compliance. The DoD High Performance Computing (HPC) Modernization Program’s DREN IPv6 Knowledge Base offers wide-ranging information, articles and specific documentation on IPv6 that can be accessed at:

Detailed information on DREN IPv6 deployment can be found on the DREN IPv6 Knowledge Base (KB) at:

DREN IPv6 Overview of Lessons Learned can be found at: This site references original documents pertaining to lessons learned, and best practices in areas that include applications, infrastructure, IP transport, network management, security, and testing.

CH 6–3.10 Protecting Information Technology

The Department released its Cybersecurity Strategy on April 17, 2015. It identifies the DoD’s three primary cyber missions.

  • The DoD must defend its own networks, systems, and information
  • DoD must be prepared to defend the United States and its interests against cyberattacks of significant consequence.
  • Third, if directed by the President or the Secretary of Defense, DoD must be able to provide integrated cyber capabilities to support military operations and contingency plans.

The DoD’s networks and systems are vulnerable to intrusions and attacks, and it is critical to develop and implement strong cybersecurity and program protection strategies and plans.

CH 6–3.10.1 Cybersecurity

Cybersecurity risk management tasks should begin early in the system development life cycle and are important in shaping the security capabilities of the system. If not effectively performed early, the tasks, undertaken later in the lifecycle, will be more costly and time consuming to implement, and could negatively impact the performance of the system and its overall cybersecurity.

There are two general categories of cybersecurity operations – defensive and offensive.

  • Defensive Cybersecurity. The protection of information against unauthorized disclosure, transfer, modification, or destruction, whether accidental or intentional.
  • Offensive Cyber Operations. Joint Publication 3-12 (R) defines Offensive Cyberspace Operations as “Cyberspace operations intended to project power by the application of force in or through cyberspace. However, for SNaP-IT and OMB taxonomy purpose, Offensive Cyberspace Operations are activities that actively gather information, manipulate, disrupt, deny, degrade, or destroy adversary computer information systems, information, or networks through cyberspace.

All acquisitions of systems containing IT, including NSS, must produce a Cybersecurity Strategy. Beginning at Milestone A, PMs will submit the Cybersecurity Strategy to the cognizant CIO for review and approval prior to milestone decisions or RFP release per Enclosure 1, Table 2 of the DoDI 5000.02. The Cybersecurity Strategy is attached as an appendix to the Program Protection Plan (PPP) for submittal. More information on the Cybersecurity Strategy is located in CH 8 Section 3.5.7.

CH 6– Responsibility

Cybersecurity is both a functional and acquisition responsibility due to its criticality. Both PMs and Functional Sponsors or Managers should be familiar with statutory and regulatory requirements governing cybersecurity, and understand the major tasks involved in developing an cybersecurity organization, defining cybersecurity requirements, incorporating cybersecurity in a program's architecture, developing a Cybersecurity Strategy, conducting appropriate cybersecurity testing, and achieving cybersecurity certification and accreditation for the program.

DoD recently revised several of its policies to more explicitly address the integration of cybersecurity into acquisition processes:

  • DoDI 8510.01, Risk Management Framework (RMF) for DoD Information Technology (IT), March 12, 2014; cancels the previous DoD Information Assurance Certification and Accreditation Process (DIACAP) and institutes a new, risk-based approach to cybersecurity through the Risk Management Framework
  • DoDI 5000.02, Operation of the Defense Acquisition System, January 7, 2015, as amended; includes regulatory cybersecurity requirements such as the Cybersecurity Strategy artifact and risk management activities involving Authorizing Officials (AO)
  • DoDI 8500.01, Cybersecurity, March 14, 2014; establishes that cybersecurity must be fully integrated into system life cycles

CH 6–3.10.2 Program Protection Planning

For the acquisition of software-intensive IT, especially IT used in National Security Systems, PMs should consider the significant operational threat posed by the intentional or inadvertent insertion of malicious code. The risks associated with these supply chain risk management (SCRM) issues are being managed within the context of program protection planning. CH 9 Section 2.3 regarding Program Protection Plan requirements as well as key practices and intelligence support from the Defense Intelligence Agency SCRM Treat Assessment Center (TAC).

For IT systems, areas of particular interest are protection and assurance activities undertaken during the integration and development of commercial off-the-shelf (COTS) components activities designed to mitigate attacks against the operational system (the fielded system); and activities that address threats to the development environment.

Additional information on program protection planning is provided in:

CH 6–3.10.3 Risk Management Framework for IT

The RMF informs the entire acquisition process, beginning with requirements development and programs should be converting from the DoD Information Assurance Certification and Accreditation Process (DIACAP). A DIACAP and RMF knowledge portal (CAC required) is available in addition to a number of other resources:

While the RMF and requirements and acquisition hierarchies are distinct, they share a common baseline of security system engineering documentation and coordination among decision authorities. Engagement between the cybersecurity and acquisition communities is critical to management of cybersecurity-related risks to system performance.

CH 6– Categorizing Information Technology for Security

DoD Instruction 8510.01, Risk Management Framework (RMF) for DoD Information Technology (IT) Enclosure 6 establishes the process to categorize IT, select security controls, implement those controls, assess the controls, achieve authorization of the system and monitor the security controls. In the categorization process, the PMs/ ISO identifies the potential impact (low, moderate, or high) resulting from loss of confidentiality, integrity, and availability if a security breach occurs. For acquisition programs, this categorization will be documented as a required capability in the initial capabilities document, the capability development document, the capabilities production document, and the cybersecurity strategy within the program protection plan (PPP).

CH 6–3.11 Test and Evaluation for Information Technology

On September 14, 2010, the Director, Operational Test and Evaluation, signed a memorandum entitled "Guidelines for Conducting Operational Test and Evaluation of Information and Business Systems." The guidelines help streamline and simplify COTS software testing procedures. They assist in tailoring pre-deployment test events to the operational risk of a specific system increment acquired under OSD oversight. For increments that are of insignificant to moderate risk, these guidelines streamline the operational test and evaluation process by potentially reducing the degree of testing. Simple questions characterize the risk and environment upon which to base test decisions, for example, "If the increment is primarily COTS, or government off-the-shelf items, what is the past performance and reliability?"

CH 8 describes various testing policies and practices.

CH 6–3.11.1 Prototyping and Piloting

Risk reduction prototypes will be included if they will materially reduce engineering and manufacturing development risk at an acceptable cost. Risk reduction prototypes can be at the system level or can focus on sub-systems or components.

The OSD office of Emerging Capability and Prototyping may be able to assist in guiding your prototyping activities.

  • Proof-of-principle prototyping validates the technical feasibility of a capability and explores its operational value.
  • Pre–engineering and manufacturing development prototyping advances capabilities that have already demonstrated some technical and operational promise.

Typically this type of activity is done on items that are not COTS; however, prototyping and piloting may still hold value in a tailored manner for information technology in the risk reduction phase in order to see real-time application of technology to down-select.

CH 6–3.11.2 Developmental Testing

Developmental Test & Evaluation (DT&E) is used to verify that the system under test meets all technical requirements. MDAP ACAT I and MAIS ACAT IA programs are supported by a chief developmental tester and a governmental test agency that serves as the lead DT&E organization. The PM, who is ultimately responsible for all aspects of system development, selects a Chief Developmental Tester. The Chief Development Tester is a highly experienced T&E professional, authorized by the PM to conduct all duties in the area of T&E for the program. Inputs from the Chief Developmental Tester to the contract, engineering specifications, systems engineering efforts, budget, program schedule, etc., are essential if the PM is to manage T&E aspects of the program efficiently.

For IT programs, one of the most critical aspects of developmental test is to ensure an operationally-representative DT environment.

Additional guidance on developmental testing is available in the DoDI 5000.02 Enclosure 4 as well as CH 4 Section

CH 6–3.11.3 Operational Testing

The appropriate operational test organization will conduct operational testing in a realistic threat environment. The threat environment will be based on the program’s System Threat Assessment Report and appropriate scenarios. For MDAPs, DBS, MAIS and other programs on the DOT&E Oversight List, DOT&E will provide a report providing the opinion of the DOT&E as to whether the program is operationally effective, suitable, and survivable before the MDA makes a decision to proceed beyond LRIP. For programs on the DOT&E Oversight List, operational testing will be conducted in accordance with the approved TEMP and operational test plan. The Department’s independent operational test agencies likely have guides or other training available on how to conduct operational testing, especially tailored to Service requirements. The Air Force Operational Test and Evaluation Center (AFOTEC), for example, has a detailed operational test guide available.

Additional guidance on operational testing is available in the DoDI 5000.02 Encl. 5 Sec 7 as well as CH 8 Section 3.2.

CH 6–3.11.4 Cybersecurity Test and Evaluation

Per the DOT&E Cybersecurity T&E Guidebook, “Potential cyber vulnerabilities, when combined with a determined and capable threat, pose a significant security problem for the DoD and its warfighters. Cybersecurity test and evaluation (T&E) assists in the development and fielding of more secure, resilient systems to address this problem.” The Guidebook outlines steps for planning, analysis, and implementation of cybersecurity T&E. Fundamentally, cybersecurity T&E consists of iterative processes, starting at the initiation of an acquisition and continuing throughout the entire life cycle.

The critical piece of documentation is typically a Test and Evaluation Master Plan (TEMP). The RMF may also drive cybersecurity testing requirements.


Develop a strategy and budget resources for cybersecurity testing. The test program will include, as much as possible, activities to test and evaluate a system in a mission environment with a representative cyber-threat capability. CH 8 Section 3.2.4 discusses survivability and cybersecurity testing as well.

  • Beginning at Milestone A, the TEMP will document a strategy and resources for cybersecurity T&E. At a minimum, software in all systems will be assessed for vulnerabilities. Mission critical systems or mission critical functions and components will also require penetration testing from an emulated threat in an operationally realistic environment during OT&E.
  • Beginning at Milestone B, appropriate measures will be included in the TEMP and used to evaluate operational capability to protect, detect, react, and restore to sustain continuity of operation. The TEMP will document the threats to be used, which should be selected based on the best current information available from the intelligence community.
  • The Program Manager, T&E subject matter experts, and applicable certification stakeholders will assist the user in writing testable measures for cybersecurity and interoperability.
  • The Program Manager and Operational Test Authority will conduct periodic cybersecurity risk assessments to determine the appropriate Blue/Green/Red Team, and operational impact test events in alignment with the overall test strategy for evaluating the program for real world effects. Defense business systems will undergo Theft/Fraud operational impact testing.

CH 6–3.12 Sustaining Information Technology

CH 6–3.12.1 Post Implementation Reviews

The requirement for a PIR is outlined in the DoDI 5000.02 Enclosure 11 section 4 and is directed by Title 40 U.S.C. section 11313.

The Functional Sponsor, in coordination with the Component CIO and Program Manager, is responsible for developing a plan and conducting a PIR for all fully deployed IT, including NSS. PIRs are intended report the degree to which DOTMLPF-P changes have achieved the established measures of effectiveness for the desired capability; evaluate systems to ensure positive return on investment and decide whether continuation, modification, or termination of the systems is necessary to meet mission requirements; and document lessons learned from the PIR. If the PIR overlaps with Follow-on Operational Test and Evaluation, the sponsor should coordinate planning of both events for efficiency. The basic high-level process for conducting a PIR is:

  • Plan for the PIR and document in a PIR Plan
  • Conduct the PIR, ensuring discussion of items such as ROI, measures met / not met, lessons learned, benefits achieved, etc.
  • Conduct analysis based on the PIR findings
  • Document the results in a PIR Report for feedback into the sustainment program

CH 6–3.12.2 Operations and Sustainment of IT

The purpose of O&S for IT is to execute the product support strategy, satisfy materiel readiness and operational support performance requirements, and sustain the system over its life cycle (to include disposal). The O&S Phase begins after the production or deployment decision and is based on an MDA-approved Lifecycle Sustainment Plan (LCSP). DoDI 5000.02 Enclosure 6 includes a broader discussion of sustainment planning to include LCSPs and metrics. Sustainment planning is discussed throughout CH 4 beginning in Section 2.1. LCSPs are also discussed in CH 8 Section 3.5.12.

The phase has two major efforts, Sustainment and Disposal. The LCSP, prepared by the Program Manager and approved by the MDA, is the basis for the activities conducted during this phase.


During this phase, the Program Manager will deploy the product support package and monitor its performance according to the LCSP. The LCSP may include time-phased transitions between commercial, organic, and partnered product support providers. The Program Manager will ensure resources are programmed and necessary IP deliverables and associated license rights, tools, equipment, and facilities are acquired to support each of the levels of maintenance that will provide product support; and will establish necessary organic depot maintenance capability in compliance with statute and the LCSP.


At the end of its useful life, a system will be demilitarized and disposed of in accordance with all legal and regulatory requirements and policy relating to safety (including explosives safety), security, and the environment.

CH 6–3.12.3 Upgrades

Upgrades on business capabilities and system occur on a relatively regular basis and throughout the lifecycle. This includes:

  • Ongoing maintenance to correct existing processing, performance and implementation defects.
  • Regular enhancements based on user feedback
  • Preventive maintenance for software efficiency and to prevent corruption (e.g., anti-virus tools).
  • Identification of new requirements or upgrades to improve performance, maintainability, and add functionality. If the changes are major in terms of cost, schedule, and or / performance, it may require the instantiation of a new program increment.

CH 6–4. Additional Planning Considerations

Additional best practices or other unique process requirements for the development and implementation of IT programs are discussed throughout this section.

CH 6–4.1 Best Practice and Lessons Learned

The following best practices for IT acquisition were originally introduced in 2010 through the Better Buying Power (BBP) initiative and built upon through successive BBP iterations. The principles of BBP apply to all acquisitions, and are being adopted through the IT acquisition community to improve affordability and delivery outcomes in IT acquisition. Many of the BBP principles that have translated throughout programs are:

Furthermore, the USD(AT&L) has solicited feedback from individuals actually acquiring and implementing systems in the Department – and published it for others to read and learn from. For example, in 2015 the USD asked Program Managers of various ACAT I programs to submit assessments to him. With permission, he compiled some of them into a report which is available for viewing here. Taking this theme even a step further, the USD(AT&L) solicited feedback from Program Executive Officers (PEOs) regarding their portfolios and any suggestions they might have for improving results. Those results, which are mostly unedited, were published in the July-August 2016 Issue of DAU’s Defense AT&L Magazine.

Finally, the Government Accountability Office (GAO) has identified a set of essential and complementary management disciplines that provide a sound foundation for information technology (IT) management. These include: IT strategic planning, Enterprise architecture, IT investment management and Information Security; additional information is available through the GAO’s website on the issue summary.

CH 6–4.2 Root Cause Analysis

One of the issues the Department faces with successfully fielding IT capabilities is making the leap from problem to solution too quickly, resulting in a solution that doesn't meet the fundamental need but rather provides temporary "band-aids" for its symptoms. The tendency to "do something now!" must be appropriately balanced with a process that mitigates the risk of fixing a symptom vs. its root cause(s). Root Cause Analysis is a structured approach to determining a problem's causal factors and identifying what behaviors, actions, inactions, or conditions need to be changed in order to eliminate the problem.

There is no single methodology for performing Root Cause Analysis and various approaches can yield satisfactory results. Different approaches to identify potential root causes include:

  • Affinity Diagram
  • Fishbone Diagram
  • Five Whys Analysis
  • Pareto Diagram
  • Value Analysis

Your Service / Component may have a specific preference toward root cause analysis methodology. The results of a root cause analysis will eventually lead to the definition of a requirement, which will be documented in a Problem Statement or an ICD, depending on the type of requirement.

CH 6–4.3 General Management Practices for IT Programs

The following are best practices for management of IT programs. Some are controllable at the individual Program Management level, while some are more strategic in nature and will require involvement of a PEO-type leader to ensure the right level of strategy and management oversight of a program:

  • Ensure linkage to an IT strategic planning process, which typically occurs at the agency level (but may be derived and managed at lower levels in an agency or Service).
  • Document a process to integrate IT management operations and decisions with organizational planning, budget, financial management, human resources management, and program decisions.
  • Require that cyber security management processes be integrated with strategic and operational planning processes.
  • Institute a process to account for all IT-related expenses and results.
  • Prepare an enterprise wide strategic information resources management plan. At a minimum, an information resources management plan should (1) describe how IT activities will be used to help accomplish agency missions and operations, including related resources; and (2) identify a major IT acquisition program(s) or any phase or increment of that program that has significantly deviated from cost, performance, or schedule goals established for the program.
  • Ensure its performance plan required under the Government Performance and Results Act of 1993 (GPRA), as amended by the GPRA Modernization Act of 2010 (GPRAMA) (1) describes how IT supports strategic and program goals; (2) identifies the resources and time periods required to implement the information security program plan required by FISMA; and (3) describes major IT acquisitions contained in the capital asset plan that will bear significantly on the achievement of a performance goal.
  • Have a documented process to (1) develop IT goals in support of agency needs; (2) measure progress against these goals; and (3) assign roles and responsibilities for achieving these goals.
  • Establish goals that, at a minimum, address how IT contributes to (1) program productivity, (2) efficiency, (3) effectiveness, and (4) service delivery to the public (if applicable).
  • Establish IT performance measures to monitor actual-versus-expected performance. Measures should align with the GPRAMA performance plan.
  • In an annual report, to be included in the budget submission, describe progress in using IT to improve the efficiency and effectiveness of agency operations and, as appropriate, deliver services to the public.
  • Benchmark IT management processes against appropriate public and private sector organizations and/or processes in terms of costs, speed, productivity, and quality of outputs and outcomes.

CH 6–4.3.1 Risk Management and Mitigation

Successful risk management requires thoughtful planning and resourcing, and should be implemented as early as possible in the life cycle beginning with the Materiel Solution Analysis phase. The goal is to identify risks to inform decisions and handling strategies before the risks become issues. DAU has a risk management course available for basic training as well.

Risk management needs to be both top-down (embraced by the PM and others) and bottom-up (from working-level engineers) to be successful. PMs should encourage everyone on their program to take ownership of the risk management program and should be careful not to cultivate a “shoot the messenger” culture. All personnel should be encouraged to identify risks, issues, and opportunities and, as appropriate, to support analysis, handling, and monitoring activities.

Organizational implementation and process quality are equally important in determining a program’s risk management effectiveness. A poorly implemented risk management process will not contribute to program success and may lead to program inefficiency. It is essential that programs define, implement, and document an appropriate risk management approach that is organized, comprehensive, and iterative, by addressing the following questions:

1. Risk Planning: What is the program’s risk management process?

2. Risk Identification: What can go wrong?

3. Risk Analysis: What are the likelihood and consequence of the risk?

4. Risk Handling: Should the risk be accepted, avoided, transferred, or mitigated?

5. Risk Monitoring: How has the risk changed?

Figure 9: Risk Management Process

Figure 7: Risk Management Process

CH 6–4.4 Process Support Tools

Table 9: Process Support Tools - Examples




DoD Information Technology Portfolio Repository

The unclassified authoritative inventory of IT systems. It contains information on DoD’s mission critical and mission essential information technology systems and their interfaces including the following: system names, acronyms, descriptions, sponsoring component, approval authority, points of contact, and other basic information. The information stored in DITPR provides DoD decision makers an over-arching view of DoD’s IT capabilities for making resource decisions. It is the responsibility of the Program Manager (PM) to ensure that IT is registered and follows all applicable DoD Component Chief Information Officer (CIO) procedures and guidance.

Additional information about DITPR can be accessed from here.

DITPR can be accessed here.

A DITPR account can be requested here.


DoD Information Technology Investment Portal

DITIP provides a centralized location for IT investment portfolio data, is the authoritative data source for DoD IT Header information, and aligns IT systems information in the Defense IT Portfolio Registry (DITPR) with budget information in the Select and Native Programming Data Input System for IT (SNaP-IT). A DITIP account can be requested here. For additional guidance on managing DBS using DITIP, access the DITIP website and select “DITIP Instructions – DBS Certification Management”.


Select & Native Programming Data Input System for Information Technology

SNAP-IT the is the authoritative Department of Defense (DoD) database used for publishing the DoD Information Technology (IT) Budget Estimates to Congress, the Circular A-11 Section 53 and Section 300 exhibits to the Office of Management and Budget (OMB), and for monthly IT performance reporting to the Federal IT Dashboard.

you can access SNaP-IT guidance for these work products within the in DoD 7000.14-R Financial Management Regulation Volume 2B, Chapter 18 Information Technology (Including Cyberspace Operations) dated September 2015) or within annual budget guidance issued by OUSD(C), D,CAPE, and DoD CIO. SNAP-IT can be accessed here.


Program Resources Collection Process

DoD web-based application designed to prepare and manage direct program budget details. All MDAPs shall submit PBR data at the sub-program level, and all MAIS programs shall submit at the Increment level as appropriate, consistent with the Track-to-Budget rules established for the data submission to PRCP, per the program/budget transparency requirements of the Fiscal Year Integrated Program/Budget Submission Guidance. PRCP is available on SIPR.


Defense Acquisition Management Information Retrieval

Provides enterprise visibility to Acquisition program information. DAMIR streamlines acquisition management and oversight by leveraging web services, authoritative data sources, data collection, and data repository capabilities. DAMIR identifies various data sources that the Acquisition community uses to manage Major Defense Acquisition Programs (MDAP) and Major Automated Information Systems (MAIS) programs and provides a unified web-based interface through which to present that information. DAMIR is the authoritative source for Selected Acquisition Reports (SAR), SAR Baseline, Acquisition Program Baselines (APB), and Assessments. It is a powerful reporting and analysis tool with robust data checks, validation, standardization and workflow leveling. It has extensive security capabilities as well as both classified and unclassified versions. One component of DAMIR, Purview, is an executive information system that displays program information such as mission and description, cost & funding, schedule, and performance. The DAMIR site, with directions for obtaining an account, can be accessed here.


Acquisition Information Repository

A searchable document repository for final milestone documents for Pre-Major Defense Acquisition Programs, Unbaselined Major Automated Information Systems, Acquisition Category (ACAT) ID, ACAT IAM, and Special Interest Programs. PMs are not responsible for uploading reports directly, but programmatic reports, such as an Analysis of Alternatives or Clinger Cohen Act compliance confirmation will be uploaded by the responsible agency. To access the AIR site, with directions for obtaining an account, go here.


DAE Action Tracker

DAT is a System that tracks action items from Acquisition Decision Memorandums (ADMs) and their status. The decisions and direction resulting from each acquisition milestone and other major decision point reviews are documented in an ADM. ADMs are ultimately signed by the MDA. The status of all ADM-directed actions for MAIS, MDAP, and Special Interest programs are tracked in DAT. As a PM it is important to pay close attention and work to quickly rectify any ADM actions because of their high visibility.

DAT can be accessed here.


Enterprise Mission Assurance Support Service

A web-based tool that automates and integrates services for cybersecurity managements and maintains an enterprise baseline for security controls. It manages several services including scorecard measurement, dashboard reporting, generation of Risk Management Framework (RMF) for the DoD and DOD Information Assurance Certification and Accreditation Process (DIACAP) Package Reports, and reporting of applicable Federal Information Security Management Act (FISMA) reports. eMass also manages all cybersecurity compliance activities from system registration through system decommissioning. PMs are responsible for following the RMF process for the selection and specification of security controls for an information system.

eMass can be accessed at

Directions for obtaining an eMASS account can be found at

CH 6–4.5 Data Sharing Tools

This section addresses those tools, technology standards and specifications that are key enablers in driving data and information sharing. The section attempts to be comprehensive; yet, acknowledges the difficulty in keeping pace with rapidly evolving technologies. All of these enablers are recommended for use, as applicable. PMs should recognize that some are mandated in different policies and guidance documents and use as required.

The following table provides a brief description of some sample tools that can be used when implementing the sharing of data, information, and IT services.

Table 10: Data Sharing Tools - Examples



Access Controls

Provides the mechanism to validate the rights or privileges (authorization) and claims of identity (authentication) for a user and matches those user credentials to defined access policies in order to make the grant or deny decision that is enforced through the policy enforcement point.

Adapter Services

Provides transformation or mediation of data assets and exchange formats. To be used for legacy system or data integration and federated domain transportation.

Cryptographic Binding

Creates a relationship between data objects and metadata tags by hashing the data object(s) and metadata and signing over the hashes with a signature using cryptography as a technique to ensure the integrity and authentication of data (i.e., no modifications, deletions or insertions by unauthorized sources).

Data Services Environment (DSE)

Provides an on-line repository enabling developers to reuse, understand, and share existing data assets. It addresses structural and semantic metadata such as schemas, web service description language, stylesheets, and taxonomies; descriptive metadata about proposed and approved ADSs, including their relationships and their responsible governance authorities; and descriptive, semantic, and structural metadata about services and other functional capabilities, including service definitions and specifications that can be discovered for subsequent use.

Data Tagging User Interface (UI)

Adds metadata tags to a data asset on the backend via a general Web UI, portal or local tagging tool. It is primarily used in a thin client or cloud environment.

DoD Information Technology (IT) Standards Registry (DISR)

The DISR is an online repository of IT standards. It defines the service areas, interfaces, standards (registry elements), and standards profiles applicable to all DoD systems. Use of the registry is mandated for the development and acquisition of new or modified fielded IT systems throughout the DoD.

DoD Storefront

Provides an access point for end-users to discover data assets.

Enterprise Authoritative Data Source (EADS)

Provides a registry of DoD data needs, data sources authoritative bodies (ABs) and AB-approved assertions on the context upon which a given data source is authoritative. EADS is part of the Data Services Environment (DSE).

Enterprise Catalog

Provides a repository for data providers to publish DDMS-compliant discovery metacards.

Enhanced Information Support Plan (EISP)

The Enhanced Information Support Plan (EISP) tool is used to fulfill the requirements for creating an ISP. For more information, see section 7.3.6 of this Guidebook.

Enterprise Messaging

Allows applications to publish and receive information such as special reports, alerts, briefs or section-specific information over specialized logical messaging channels.

Federated Search

Provides the ability to find information across multiple sources without guesswork to use as part of Content Discovery. No special expertise in a complex query language or interface is required.

Enables the collaborative development and use of open source and DoD community source software.

Global Information Grid (GIG) Technical Guidance – Federation (GTG-F)

The GTG-F is a suite of software applications that provides technical guidance. The GTG-F content consists of and is based on GIG net-centric IT standards, associated profiles, engineering best practices and reference implementation specifications.

Metadata Registry (MDR)

Collects, stores, and disseminates structural and semantic metadata artifacts critical to successful development, operation and maintenance of existing and future DoD capabilities. MDR is part of the DSE.

Metadata Tagging Tools (e.g., AMTT)

Tools that extract information from data assets in order to generate metacards or documents with imbedded metadata.

Net-Centric Publisher (NCP)

Automatically publishes data assets to the Metadata Registry, Service Registry and Enterprise Catalog. NCP is part of the DSE.

Search Widgets and Applications

Leverages services for search and discovery of metadata cards and assets for various widgets and applications, primarily during the development and design phases.

Secure Data Tagging Tool (SDTT) Suite

NSA data tagging toolset. It includes reusable components that allow analysts and stakeholders to create metadata tags, validate them for conformance and reasonability to Controlled Access Program Coordination Office (CAPCO) or other standards, and perform cryptographic binding of the metadata to the data asset(s).

Security Mechanisms

Provides security implementations, configurations and protocols aimed at mitigating or stopping security threats throughout the enterprise. Includes mechanisms such as IdAM, XML Gateways, PKI, etc.

Service Discovery (SD)

Searches the Enterprise Service Registry for service providers and services. SD is part of the DSE.

Service Registry (SR) (Universal Description Discovery and Integration [UDDI])

Provides the information required for an application developer to locate an appropriate service, determine the features and functions provided by that service, identify how to invoke the service, and determine where the service resides.

Smart Data

Tags all the data so users can track it, know the sensitivity, and apply access control values, provenance and smart routing.

Transport Protocols

Provide a standardized means for routing and transportation across a net-centric environment. Can be any of the technical protocols used for transportation and routing such as Hyper Text Protocol (HTTP), SOAP/HTTP, SOAP/Java Message Service (JMS), FTP, etc.

User Authentication and Authorization Services

Provides dynamic and account based access control to support the automated provision of web services and attribute-based access to data and resources using policy decision points and policy enforcement points. This is the foundation for access control throughout the Joint Information Environment (JIE).

CH 6–4.6 Acquisition Policy Evolution to an Adaptive Acquisition Framework

In Fiscal Year 2020, USD(A&S) will issue new acquisition guidance. This includes a Change 2 update to the DoD 5000.75 for Defense Business Systems and new instructions and guides to govern the middle tier of acquisition, software acquisition, and intellectual property.

A restructured DoD Instruction (DoDI) 5000.02 will improve process effectiveness, streamline content, implement key changes to statute, and capitalize on Defense Acquisition University digital resources to improve acquisition community access to related policy and business practice. Forthcoming new content will provide guidance on operation of the Adaptive Acquisition Framework (AAF). Figure 10 depicts the current version of the AAF model.

Figure 10: Adaptive Acquisition Framework

CH 6–Version and Revision History

The table below tracks chapter changes. It indicates the current version number and date published, and provides a brief description of the content.

Version #

Revision Date




Chapter 6 initial upload



CH 6–3.9.2 Cloud Computing – links validation



Chapter links validated/updated and “shortcut” where appropriate.



  • Updates to DoDI 5000.75/Business Capability Acquisition Cycle (BCAC)
  • Updates to cloud, enterprise services, and interoperability content.



  • Updates to MAIS language per repeal of Chapter 144A in the FY2017 NDAA.
  • Updates to MAIS/DBS language per removal of MAIS/DBS from MDAP definition in FY2018 NDAA.
  • Link updates and other standard formatting updates.



  • Adds Chapter 6-3.9.3, Acquisition of Internet Protocol Version 6 (IPv6) Capable Products
  • Adds Chapter 6-4.6 Acquisition Policy Evolution to an Adaptive Acquisition Framework
  • Updates Figure 6, BCAC for DBS
  • Minor edits for currency