Control Packs · DAT-006 · v1.0.0
Protected Transit Between Components
Name the hops that carry data worth protecting, state what protects each one, verify the far end is the intended one, and refuse an unprotected fallback.
Status: review · Review: not independent. This is design guidance; review status does not establish independent verification or compliance.
What this safeguard addresses
Name every hop that carries data worth protecting, state what protects it and how the far end is verified, and make an unprotected attempt fail rather than proceed.
- Data crosses a boundary without a confirmed protected pathA hop between two components carries data over a path nobody chose, silently falls back to an unprotected one, or reaches an endpoint whose identity was never verified.
Versioned applicability rule
{
"any": [
{
"characteristic": "SENSITIVE_DATA",
"equals": true
},
{
"characteristic": "EXTERNAL_DEPENDENCY",
"equals": true
},
{
"characteristic": "DATA_EXPORT",
"equals": true
}
]
}Decisions for the project owner
Leave a decision open when its value is unknown. Suggested values become confirmed only through an explicit user decision.
- Which connections carry data worth protecting, and what is at the far end of each?The service cannot tell which hops matter from the feature description. An internal hop between two services is as much a decision as a public one.DAT-006-Q1 · scope
- What should happen when a protected connection cannot be established?This is the decision that makes the protection real. A fallback to an unprotected path turns a safeguard into a preference, and it usually happens on exactly the day something is wrong.DAT-006-Q2 · choice
Requirements for the coding agent
- DAT-006-R1Record every connection that carries data worth protecting, including internal service-to-service and background jobs, and state for each what protects it and how the far end's identity is verified.
- DAT-006-R2Make a failed protected connection take the confirmed failure path rather than continuing over an unprotected one, and record the failure without recording the payload.
Tests and evidence to retain
- TRANSIT_PROTECTION_TESTFor each recorded connection, verify the protected path is the one used and that an endpoint failing identity verification is refused.
- TRANSIT_DOWNGRADE_TESTPresent a connection that cannot be protected and verify the confirmed failure path runs instead of an unprotected attempt succeeding.
- configuration_or_policy
- implementation_location
- test_result
Passing a published example shows that example's behavior. A coding agent's implementation report remains a claim until its evidence is independently checked.
Related guidance
- SC-8 · Transmission Confidentiality and IntegrityNIST_SP_800_53_5_2_0 · partially addressesNaming protected hops, verifying the far end, and refusing an unprotected fallback address a design boundary. They do not cover cryptographic algorithm selection, key distribution, or deployed configuration.
- SC-23 · Session AuthenticityNIST_SP_800_53_5_2_0 · partially addressesVerifying the far end before sending addresses session authenticity at the design boundary only; it does not cover session management or replay protection generally.
Mappings indicate contextual relevance or partial support. They do not establish equivalence, certification, government endorsement, or complete framework implementation.