Protecting data as it moves.
CC6.7 is about restricting and protecting the transmission and movement of data: data in transit should be protected, and movement of data outside a boundary should be controlled. Much of it is decided by transport configuration and by where new data flows are wired, which makes it a pull-request concern.
The shapes the same control failure takes.
CC6.7 weakens when a transport stops being protected or when data starts moving somewhere new without the expected controls. The recurring shapes:
A TLS floor drops
A minimum TLS version is lowered, a strong-cipher requirement is relaxed, or a downgrade becomes possible on a path that carries sensitive data.
An internal hop goes plaintext
A service-to-service call that carried sensitive data is changed to plain HTTP, or an internal endpoint stops requiring TLS, on the assumption the network is trusted.
Certificate verification is disabled
Verification is turned off to work around a certificate problem, so the channel is no longer authenticated and can be intercepted.
A new export sends data out
A webhook, sync, or third-party integration starts moving data outside its boundary without the controls the criterion expects on that movement.
A protected field becomes loggable
Sensitive data that was kept off a transport starts being sent to a sink (a log shipper, an analytics pipeline) that was not in scope to carry it.
An internal call that falls back to plain HTTP.
A new internal client is added for a service that exposes both HTTP and HTTPS. To get it working quickly the call is wired to the plain-HTTP port. It works, and the sensitive payload it carries now crosses the network unprotected.
- const BILLING_URL = "https://billing.internal:8443"+ const BILLING_URL = "http://billing.internal:8080"const res = await post(`${BILLING_URL}/charge`, { card, amount })The charge payload now crosses the network in plaintext. CC6.7 expects data in transit to be protected, and 'it is only the internal network' is not the control the criterion describes. Point the client at the HTTPS endpoint and keep TLS on every hop that carries sensitive data.
Transit protection is checked end to end.
An assessor does not just confirm your public endpoints use TLS; they look at where sensitive data moves and whether it is protected the whole way, including internal hops and new integrations. A single call quietly moved to plain HTTP, or a new export with no controls on it, is the kind of gap a configuration review surfaces. The change that introduced it was a diff, which is the cheapest place to have caught it.
A review, not a network audit.
heygrc flags changes that touch CC6.7 and cites the criterion so the fix happens in the pull request. It does not map your whole data-flow topology or run your assessment. It catches the moment a transport stops being protected, at the diff. heygrc is in early access.