Program Protection Plans

A PPP is the programme's single account of what is worth stealing and what is being done about it. It identifies critical program information under DoDI 5200.39, identifies mission-critical functions and critical components under the trusted systems and networks policy in DoDI 5200.44, and then documents the countermeasures applied to each — Anti-Tamper, supply chain risk management, software assurance, hardware assurance, exportability features, and the cybersecurity approach. DoDI 5000.83 places the whole of it under technology and program protection rather than treating it as a security annex.

It is a milestone artifact, so it is reviewed and updated at the acquisition decision points rather than written once. The practical consequence is that a PPP has to describe a design that exists at the time of the review and be updated when that design changes, which is why programmes that maintain it as a living document spend far less effort at each milestone than programmes that reconstruct it. A PPP that has not changed while the system has is evidence of the second pattern.

Horizontal protection is the requirement that the same critical program information be protected consistently wherever it appears across the Department, so that one programme's protection is not undone by another programme fielding the same technology with weaker measures. It depends on programmes registering their CPI so overlaps can be found — which means it fails silently and asymmetrically: your CPI is exposed by someone else's decision, in a programme you have no visibility into, and nothing in your own documentation shows the problem.

They answer different questions about the same system and are routinely confused. The RMF package asks whether the risk of operating the system is acceptable to an authorizing official; the PPP asks whether the technology inside the system is protected from an adversary who wants to acquire it. Cybersecurity appears in both, which is where the conflation starts, but a system can hold a current ATO and have no protection for its critical components, and the reverse is equally possible.

They need to know the protection requirements that flow to them, which is not the same as receiving the document. A PPP aggregates what is most sensitive about a programme, so distributing it widely creates precisely the exposure it exists to prevent. The workable pattern is to derive supplier-facing requirements from the PPP — this component is critical, this data is CPI, these handling and assurance requirements apply — and flow those down through the contract, keeping the analysis that produced them in the programme.