The Program Protection Plan (PPP) is a living document, required at Milestones A, B, C, and the Full-Rate Production decision through a July 18, 2011 Principal Deputy Undersecretary of Defense for Acquisition, Technology, and Logistics (USD(AT&L)) policy memo. It is a best practice to also update the Program Protection Plan (PPP) prior to export decisions, and in order to report progress at each Systems Engineering Technical Review (SETR) event. The Program Protection Plan (PPP) is the single focal point for all program protection and system security activities on the program. It:

Can serve as a focal point for capturing critical System Security Engineering (SSE) analysis and assessment results as it gathers and matures.
Will provide previously-missing coverage of Systems Security Engineering (SSE) activities and associated analyses.
Should contain either references to where the information can be found or the actual information.

The Program Protection Plan (PPP) is a plan – a forward-looking document according to which the execution of protection will be performed. But it is also a report, which gathers the analysis and assessment results for effective program protection and system security as the plan is executed.

In this manner (plan + report), the Program Protection Plan (PPP) serves to provide the Security “Assurance Case” (reference International Organization for Standardization (ISO) Standard 15026 - Part 2 for a discussion on Assurance Cases), in which the preferred system concept represents the assurance claims, the system design represents the assurance arguments and the test plan results and Requirements Traceability Matrix (RTM) is the assurance evidence that can be traced to the system requirements.

All the pieces of an Assurance Case (Claims/Arguments/Evidence) are represented automatically by the inclusion of system security in System Engineering artifacts, such as the System Requirements Document (SRD), the system/subsystem specs, the preliminary and detailed design documents, the Requirements Traceability Matrix (RTM), and the Test Plans and Reports. The Assurance Case is thus built by the traceability of all the Systems Security Engineering (SSE) artifacts.

The Program Protection Plan (PPP) should tie all these things together. For example:

Table 3.3-1 of the Program Protection Plan (PPP) Outline is used to provide traceability of critical components from mission-level documents (JCIDS (Joint Capabilities Integration Development System) Key Performance Parameters, Key System Attributes, etc.) and Critical Technology Elements (CTE) to the system architecture.
Section 5.3 of the Program Protection Plan (PPP) Outline discusses the requirement to indicate the Request for Proposal (RFP) Contract Line Item Number (CLIN) or Data Item Description (DID) that will be used to ensure that Critical Program Information (CPI) and critical functions/components are protected in the development environment and on the system.
Section 9.3 of the Program Protection Plan (PPP) Outline directs the implementation of Verification and Validation (V&V) to provide evidence that system security has been achieved, including a link to relevant discussion in the Test and Evaluation (T&E) documents.

The last bullet above indicates a method of checking Program Protection Plan (PPP) implementation (i.e., Verification and Validation (V&V)). Audits/inspections are also used; namely, to ensure compliance with applicable laws, regulations, and policies. Engineering reviews are used to ensure that system security requirements are identified, traceable, and met throughout the acquisition lifecycle. These methods of checking Program Protection Plan (PPP) implementation are described in the following subparagraphs.

13.10.1. Audits

Program Protection Surveys and other security audits and inspections check for compliance with protection requirements. These processes check that statutory and regulatory security activities are being performed. Program Managers (PMs) should check with their Component research and development acquisition protection resources for guidance on performing these audits.

13.10.2. Systems Engineering Technical Reviews

Section 9.2 of the Program Protection Plan (PPP) Outline requires that the Program Protection Plan (PPP) answer these questions:

How will system security requirements be addressed in Systems Engineering Technical Reviews (SETR), functional/physical configuration audits, etc.?
What Program Protection entry/exit criteria will be used for these reviews?

The Systems Engineering Technical Reviews (SETR) process provides a key Systems Engineering health and risk assessment tool that is discussed in detail in Chapter 4.

The following subparagraphs provide key Systems Security Engineering (SSE) and Supply Chain Risk Management (SCRM) criteria, recommended as Systems Engineering Technical Reviews (SETR) entry/exit criteria, in order to assess and ensure that an appropriate level and discipline of program protection activities and analyses are conducted across the full system context.

13.10.2.1. Initial Technical Review (ITR)

System security objectives and criteria are in the process of being defined and will be included in the next update.

13.10.2.2. Alternative Systems Review (ASR)

Relevant objectives include:

System security and Supply Chain Risk Management (SCRM) are addressed as part of the alternative systems analysis and the development of the preferred system concept.
The preferred system concept is based on an initial criticality analysis, using current threat data, informed by supply chain risk identification.
Potential countermeasures for candidate Critical Program Information (CPI) and critical functions are identified.
Plans are defined to protect critical functions/components, processes, tools, and data.
The Statement of Work (SOW) for the Technology Development (TD) phase Request for Proposal (RFP) includes appropriate tasks for Systems Security Engineering (SSE) and Supply Chain Risk Management (SCRM).

Recommended Criteria:

Were system security and Supply Chain Risk Management (SCRM) addressed as part of the alternative systems analysis and the development of the preferred system concept?
- Was an initial criticality analysis performed and documented for the Program Protection Plan (PPP)?
- Did it use relevant, current threat data and potential vulnerability information?
- Was the preferred system concept critical function/component alternatives evaluated for supply chain risks through the threat assessment center and used to add constraints to the system requirements?
- Are the preferred concept engineering analysis and Request for Proposal (RFP) requirements being informed by supply chain risk considerations such as limited potential suppliers and defensive design?
- Were criticality analysis results used to determine and evaluate candidate Critical Program Information (CPI) and critical functions, with rationale?
- Have candidate countermeasures and possible sub-countermeasures been identified, with an emphasis on logic bearing components and supply chain risks?
- Did the analysis include the full system context, including the multiple systems that support end-to-end mission threads?
Was Systems Security Engineering (SSE) an integral part of the Milestone A phase systems engineering analysis?
- Did all of the Systems Security Engineering (SSE) and Supply Chain Risk Management (SCRM) considerations and analyses inform the identification of requirements in the preliminary system requirements document (SRD)?
- Have potential subsystem and component alternatives for critical functions been evaluated for potential suppliers, software assurance, and system assurance risks?
- Has the assessment of security risks resulted in system security requirements in the System Requirements Document (SRD)?
- Have residual Systems Security Engineering (SSE) based program protection risks and supply chain risks been identified for mitigation?
Are plans in place to protect critical components, processes, tools, and data?
- Do they promote awareness and provide personnel training on supply chain risks?
- Are plans to define and protect critical processes, including the identity of users and system uses, included?
- What tools are being used, how are they being protected (physically and operationally), and how are tools and data managed (including hardware development tools, software development tools, developer collaboration tools, and configuration management tools)?
Have appropriate tasks been included in the Statement of Work (SOW) for the Technology Development (TD) phase Request for Proposal (RFP)?
- Are specific responsibilities for Supply Chain Risk Management (SCRM) and for updated criticality analyses to assess critical functions and refine the identification of critical components included?
- Is competitive prototyping and design included, as appropriate, for candidate Critical Program Information (CPI) and critical functions?
- Are tasks to develop associated protection countermeasures included, based on the previously identified potential protection countermeasures and the system security requirements in the System Requirements Document (SRD)?
- Are the use of software assurance databases and techniques (e.g., Common Vulnerabilities and Exposures (CVE), Common Attack Pattern Enumeration and Classification (CAPEC), Common Weakness Enumeration (CWE), static analysis, and penetration testing) included?

13.10.2.3. System Requirements review (SRR)

Relevant objectives include:

System security (including criticality analysis and software assurance) and Supply Chain Risk Management (SCRM) concerns are considered in the development of the system performance requirements and non-tailorable design requirements across the full system context (e.g., including SoS).
Initial threat and vulnerability assessments are performed and used in an updated criticality analysis.
Lists are developed for initial Critical Program Information (CPI), critical functions (and potential components), selected countermeasures, and potential sub-countermeasures.
Relevant Supply Chain Risk Management (SCRM) key practices, such as defensive design, are being applied.

Recommended Criteria:

Were system security and Supply Chain Risk Management (SCRM) concerns considered in the development of the system performance requirements and non-tailorable design requirements, across the full system context (e.g., System of Systems (SoS))?
- Are the system security and Supply Chain Risk Management (SCRM) requirements mutually understood between the Government and contractor(s)?
- Are they testable or otherwise verifiable?
- Will they lead to a final system that is operationally secure and consistent with cost and schedule?
Is Systems Security Engineering (SSE) an integral part of the Technology Development (TD) phase systems engineering analysis?
- Have contractor(s) performed and summarized their initial criticality analysis (which updates the Government provided initial criticality analysis, if available)?
- In the absence of contractors, has the Government performed an updated criticality analysis?
- Does it include rationale for the selection of Critical Program Information (CPI) and critical functions and potential components?
- Have lists of initial Critical Program Information (CPI), critical functions (and potential components), selected countermeasures, and potential sub-countermeasures been developed?
- Have initial threat and vulnerability assessments have been performed, tied to the contractor’s initial criticality analysis summary?
Is/are the contractor(s) effectively fulfilling Technology Development (TD) phase Statement of Work (SOW) tasks for Systems Security Engineering (SSE) and Supply Chain Risk Management (SCRM)?
- Are contractor-refined system security requirements derived from the countermeasures, sub-countermeasures, and defensive design or runtime features selected (e.g., design diversity and least privilege)?
- Is there a draft allocation of sub-countermeasures and defensive requirements to preliminary design (architecture)? Does that design (architecture) extend to the full system context (e.g., System of Systems (SoS))?
- Does the Systems Engineering Management Plan (SEMP) describe Systems Security Engineering (SSE) processes, with process updates derived from the countermeasures, sub-countermeasures, and controls selected?
- Is there a draft allocation of process sub-countermeasures to the acquisition time line and to management and Systems Engineering (SE) sub-processes?
- Does the contractor’s review package include planning to address the government provided residual security risk assessment (divided into acquisition, operational, and sustainment sections)?
- Are tasks, funding, and schedule allocated in order to implement the Systems Security Engineering (SSE) and Supply Chain Risk Management (SCRM) requirements for the system and for management and SE sub-processes?
- Are appropriate software assurance databases and techniques (e.g., Common Vulnerabilities and Exposures (CVE), Common Attack Pattern Enumeration and Classification (CAPEC), Common Weakness Enumeration (CWE), static analysis, and penetration testing) being planned and used?
Are relevant Supply Chain Risk Management (SCRM) key practices being applied?
- What development and configuration management tools are being used, how are they being protected (physically and operationally), and how are tools and data managed (including hardware, software, and data configuration management)?
- Is defensive design being used across the full system context to anticipate potential ways that an element, system, or process could fail or be misused, so that the architecture and requirements specification of the element, system, or process can minimize failures and misuse?
- How are critical elements and processes being protected?
- How are trustworthy elements being selected?
- How are supply chain assurance concerns being incorporated into the requirements?
- Does the contract language cover Supply Chain Risk Management (SCRM) considerations (e.g., the right to subcontract, etc.)?

13.10.2.4. System Functional Review (SFR)

Relevant objectives include:

System security and Supply Chain Risk Management (SCRM) concerns are considered in establishing the functional baseline.
An updated criticality analysis is performed, together with updated threat and vulnerability assessments, as required.
Lists are updated for candidate Critical Program Information (CPI), critical functions and components, selected countermeasures, and potential sub-countermeasures.
Relevant Supply Chain Risk Management (SCRM) key practices are being applied.

Recommended Criteria:

Has an updated criticality analysis summary been generated, including rationale for Critical Program Information (CPI) and critical-function selection?
- Does it derive and allocate critical functions?
- Does it update the system design based on critical functions and design trade-offs?
- Are updated threat and vulnerability analyses included, as required?
Have derived Systems Security Engineering (SSE)/protection functional requirements been flowed into updated subsystem and preliminary component specifications?
- Has a draft allocation of sub-countermeasures and defensive functions to preliminary functional and physical design been performed? Does this allocation extend across the full system context?
Have candidate Critical Program Information (CPI) and critical-function countermeasure and sub-countermeasure functional requirements in the system spec been traced to lower level specifications?
- Have Critical Program Information (CPI) and critical-function countermeasure and sub-countermeasure trade-off analyses been conducted with respect to cost, benefit, and risk?
- Have Critical Program Information (CPI) and critical-function residual vulnerability risks been assessed?
Are the cost and schedule of lower-level Systems Security Engineering (SSE) tasks identified and included in the lower level cost and schedule plans?
- Are detailed Systems Security Engineering (SSE) activities in agreement with the Integrated Master Plan (IMP) and Integrated Master Schedule (IMS)?
- Do planning packages include required resources to complete Systems Security Engineering (SSE) tasks?
Are relevant Supply Chain Risk Management (SCRM) key practices being applied?
- What development tools are being used by suppliers, how are they being protected (physically and operationally), and how are tools and data managed (including hardware, software, and data configuration management)?
- Is defensive design being applied to include defensive functions and to maximize resilience? Does this extend across the full system context?
- How are critical elements and processes being protected?
- How are trustworthy elements being selecting?
- How thoroughly are suppliers and their supply chain(s) being evaluated?
- Are the plans to promote awareness and provide personnel training on supply chain risks being executed?

13.10.2.5. Preliminary Design Review (PDR)

Relevant objectives include:

System security and Supply Chain Risk Management (SCRM) concerns are considered in establishing the system allocated baseline.
Preliminary system design, including security, is ready to proceed into detailed design; and, stated security performance requirements can be met within cost, schedule, risk, and other system constraints.
An updated criticality analysis is performed and an updated list of Critical Program Information (CPI), critical functions and components, selected countermeasures, and sub-countermeasures is produced, with rationale.
Relevant Supply Chain Risk Management (SCRM) key practices are being applied.

Recommended Criteria:

Have system security and Supply Chain Risk Management (SCRM) concerns been considered in establishing the system allocated baseline?
- Has an updated criticality analysis summary been generated, with rationale for Critical Program Information (CPI) and critical component selection?
- Was an updated threat and vulnerability assessment summary, with respect to the updated criticality analysis summary, included, and were supply chain risks included? Does this extend across the full system context (e.g., System of Systems (SoS))?
- Does the updated Critical Program Information (CPI)/critical component list include countermeasures and sub-countermeasures?
- Are inherited Critical Program Information (CPI) and horizontal protection adequately assessed, are they being addressed consistently at system and subsystem levels, and are they documented in the updated Acquisition Strategy (AS), Test and Evaluation Management Plan (TEMP), and Program Protection Plan (PPP)?
- Have Systems Security Engineering (SSE) and Supply Chain Risk Management (SCRM) processes been updated, based on the selected countermeasures, sub-countermeasures, and controls?
Does the preliminary system design appropriately include and address security, and is it ready to proceed into detailed design?
- Were System Requirements Document (SRD) security requirements trades based on the Program Manager’s (PM) assessment of cost, schedule, performance, and supply chain risks?
- Were the security requirements specifications, updated for subsystems and components, derived from the countermeasures, sub-countermeasures and defensive design or runtime features selected (e.g., defense in depth)?
- Was an updated residual security risk assessment performed for the summary-level critical functions and Critical Program Information (CPI), covering acquisition, operations, and sustainment activities (for both system and processes, after sub-countermeasures are applied), including supply chain considerations? Does this extend across the full system context (e.g., System of Systems (SoS))?
- Has an Anti-Tamper (AT) plan been generated (if it is a contract deliverable)?
- Are appropriate software assurance databases and techniques (e.g., Common Vulnerabilities and Exposures (CVE), Common Attack Pattern Enumeration and Classification (CAPEC), Common Weakness Enumeration (CWE), static analysis, and penetration testing) used to assess vulnerabilities and exposures to attack, common destructive attack patterns, and weaknesses in the software architecture and design?
- Have Critical Program Information (CPI) and critical components and sub-components that were categorized as Critical Technology Elements (CTE) been demonstrated at a Technology Readiness Level (TRL) 6 or better?
Was an allocation of sub-countermeasures and defensive functions to the design/architecture below the counterintelligence (CI) level performed?
- Was the critical functionality of each Hardware Configuration Item (HWCI) and Computer Software Configuration Item (CSCI) allocated to lower level components?
- Were Systems Security Engineering (SSE) fault isolation tree and system response analysis techniques used to define appropriate sub-countermeasures?
- Does the allocated design effectively implement appropriate sub-countermeasures?
- Were system designs that could expose critical functionality to vulnerability assessed, and were architecture trade-offs evaluated, in order to formulate the allocated baseline?
- Were external and subsystem interface requirements vulnerabilities assessed and used as input to the sub-countermeasure selection?
- Do planned sub-countermeasures for design and implementation include software assurance (e.g., fail-safe defaults, defense in depth, purging of temporary data, avoidance of unsafe coding constructs, secure languages and libraries, and static and dynamic code analysis)?
Are relevant Supply Chain Risk Management (SCRM) key practices being applied?
- What development tools are being used by suppliers, how are they being protected (physically and operationally), and how are tools and data managed (including hardware, software, and data configuration management)?
- How are critical elements and processes being protected?
- How are supplier roles constrained and access limited?
- How thoroughly are suppliers and their supply chain(s) being evaluated?
- Are the plans to promote awareness and provide personnel training on supply chain risks being executed?

13.10.2.6. Critical Design Review (CDR)

Relevant objectives include:

System security and Supply Chain Risk Management (SCRM) concerns are considered in establishing the system product baseline.
Detailed system design, including security, is ready to proceed into fabrication/development; and, stated security performance requirements can be met within cost, schedule, risk, and other system constraints.
An updated criticality analysis is performed and updated lists of Critical Program Information (CPI), critical components and sub-components, selected countermeasures, and specific sub-countermeasures are produced, with rationale. This extend across the multiple systems that support the end-to-end mission threads.
Relevant Supply Chain Risk Management (SCRM) key practices are being applied.

Recommended Criteria:

Is Systems Security Engineering (SSE) an integral part of the Engineering and Manufacturing Development (EMD) phase systems engineering analysis?
- Has the contractor updated and summarized their criticality analysis, with rationale, to include a final list of updated Critical Program Information (CPI) and critical components and sub-components, together with associated countermeasures and explicit sub-countermeasures?
- Were inherited Critical Program Information (CPI) and horizontal protection adequately assessed in the updated criticality analysis?
- Were adequately robust Systems Security Engineering (SSE) tools used in establishing the product baseline; e.g., the use of an updated system response matrix and Systems Security Engineering (SSE) fault isolation tree techniques?
- Were appropriate software assurance databases and techniques (e.g., Common Vulnerabilities and Exposures (CVE), Common Attack Pattern Enumeration and Classification (CAPEC), Common Weakness Enumeration (CWE), static analysis, and penetration testing) used to reassess vulnerabilities and exposures and to reexamine weaknesses in the software architecture, design, and code?
- Do sub-countermeasures for implementation and testing include software assurance (e.g., purging of temporary data, avoidance of unsafe coding constructs, secure languages and libraries, static and dynamic code analysis, fault injection, and patch management)?
- Has a residual vulnerability risk assessment been performed to assess, mitigate and re-assess weaknesses in the detailed design, including an assessment of security in the operational environment?
Does the detailed system design include and appropriately address security and Supply Chain Risk Management (SCRM) considerations, and is it ready to proceed into fabrication/development?
- Have all Systems Security Engineering (SSE) requirements been flowed down and mapped to the detailed system design and the lifecycle processes?
- Has an allocation of specific sub-countermeasures to sub-components and lower-level items in counterintelligence (CI) specifications and Statement of Work requirements been performed?
- Have appropriate Systems Security Engineering (SSE) countermeasures and sub-countermeasures been allocated to the design with validation criteria established (e.g., engineering-in-depth for separation and layering of critical elements, addition of defensive function layers, and handling of authentication methods)?
- Does the detailed design incorporate good Systems Security Engineering (SSE) practices, such as minimizing the attack surface, the number of critical components, and/or the number of potential weaknesses? Do these Systems Security Engineering (SSE) practices extend across the full system context (e.g., System of Systems (SoS))?
- Are quantifiable measures being used to assess the detailed design for security and for application of countermeasures (corrective actions) to address identified deficiencies?
- Has manufacturability been assessed, including the availability and identification of accredited suppliers for secure fabrication of Application-specific integrated circuits (ASICs), Field-programmable gate array (FPGAs), and other programmable devices?
- Has validation and verification of system security and Supply Chain Risk Management (SCRM) requirements been finalized and reflected in the Test and Evaluation Management Plan (TEMP), preliminary test plans, Systems Engineering Plan (SEP), and other operational Concept of Operations (CONOPS) documents?
Are relevant Supply Chain Risk Management (SCRM) key practices being applied?
- What development tools are being used by suppliers, how are they being protected (physically and operationally), and how are tools and data managed (including hardware, software, and data configuration management)?
- Was diversification of standard interfaces and defensive design used for architecting the system?
- How will critical elements and processes be protected throughout the lifecycle, including disposal of items?
- How will trustworthy elements continue to be selected throughout the lifecycle?
- How are supplier roles constrained and access limited?
- How thoroughly are suppliers, their supply chain(s), and their delivery processes being evaluated?
- How are Government supply chain delivery mechanisms being protected?
- Are the plans to promote awareness and provide personnel training on supply chain risks being executed?

13.10.2.7. Test Readiness Review (TRR)

Relevant objectives include:

System security and Supply Chain Risk Management (SCRM) concerns are considered in establishing readiness of the system to begin formal acceptance testing, and this extends across the full system context (e.g., System of Systems (SoS)).
The system test plans and objectives, including scope, procedures, and test facilities, are adequate for appropriately verifying all system security requirements.

Recommended Criteria:

Is there a documented, comprehensive mapping of all security requirements to their test/verification methods, to include bi-directional traceability?
- Does it include all system security requirements, clearly defined from threat analysis/modeling, and vulnerabilities identified in residual vulnerability risk assessments? Does this extend to the multiple systems that support the end-to-end mission threads?
- Are all countermeasures for all identified vulnerabilities implemented in the detailed design included and mapped?
- Do system verification and validation plans (including flow-down from the Test and Evaluation Management Plan (TEMP) to test plans and procedures) adequately ensure that coding and fabrication of designed components provide the required system security?
- Is it possible to “pull the thread” from the initial criticality analysis identifying comprehensive security requirements across the lifecycle to the verification/validation efforts (comprising, for example, a set of organized pointers into the Program Protection Plan (PPP), System Requirements Document (SRD), flow-down requirements specifications, design documents, requirements traceability matrix, and the Test and Evaluation Management Plan (TEMP), test plans, and test procedures)?
Are system test plans and objectives, including scope, procedures, and test facilities, adequate for appropriately verifying all system security and Supply Chain Risk Management (SCRM) requirements, across the full system context (e.g., System of Systems (SoS))?
- Are security threat and “attack” scenarios included in testing?
- Does system testing include penetration testing, testing for confidentiality of users and uses, and configuration of elements to limit access and exposure?
- Are appropriate security test facilities and test equipment, schedule, and personnel planned in the Test and Evaluation Management Plan (TEMP) and lower level test plans, Integrated Master Plan (IMP), and Systems Engineering Plan (SEP); and, are they adequate and available?
- Do planned measures for verification testing and operational use include software assurance sub-countermeasures/techniques (e.g., static and dynamic code analysis, fault injection, patch management, white- and black-box testing, penetration testing, sandboxing, and honey pot systems)?
- Have Critical Program Information (CPI) and critical components and sub-components that were categorized as Critical Technology Elements (CTEs) been demonstrated at a Technology Readiness Level (TRL) 7 or better?

13.10.2.8. System Verification Review (SVR) / Functional Configuration Audit (FCA)

Relevant objectives include:

The production system is compliant with all functional baseline system security requirements and provides full functionality, without exploitable vulnerabilities (or with security and supply chain risks mitigated to an acceptable level). This extends to the full system context (e.g., System of Systems (SoS)).
An Updated Program Protection Plan (PPP) is being developed for delivery at Full Rate Production (FRP).

Recommended Criteria:

Is the production system compliant with all functional baseline system security requirements?
- Is full system functionality provided without exploitable vulnerabilities, or with security and supply chain risks mitigated to an acceptable level? Does this include the multiple systems that support the end-to-end mission threads, as defined in the Concept of Operations (ConOps)?
- Are system protection requirements adequate against the system specifications flowed from the Initial Capabilities Documents (ICD)?
- Is there a complete traceability of capabilities to system security requirements to detailed design to protection verification methods to results?
- Has a review of all analysis, inspection, demonstration, and test reports of compliance to meet security and Supply Chain Risk Management (SCRM) requirements been conducted, and do all items meet verification needs?
- Have all planned Systems Security Engineering (SSE) activities/products been implemented, including software assurance, system assurance, and Supply Chain Risk Management (SCRM); and, have the results been documented?
- Has a residual vulnerability risk assessment been performed to assess, mitigate, and re-assess weaknesses in the system, including an assessment of security in the operational environment?
- Are plans in place to update the residual risk assessment periodically during sustainment?

13.10.3. Verification and Validation (V&V)

Some program protection activities have requirements testing, verification, and validation built into their processes (e.g. Anti-Tamper, Information Assurance). Further guidance on more general integration of Program Protection into Verification and Validation (V&V) activities will be provided in the next Defense Acquisition Guidebook (DAG) update.

13.10.4. Sustainment

While the primary emphasis of Program Protection is on the design and acquisition phases of a system lifecycle, some sustainment considerations must be addressed if the protection profile is to survive system delivery. Repair depots, for example, should be aware of Critical Program Information (CPI) and mission-critical functions and components on systems they are maintaining so as to appropriately protect these items from compromise. Further guidance on sustainment considerations for Program Protection will be provided in the next Defense Acquisition Guidebook (DAG) update.

Top of page

Previous and Next Page arrows