Data in Motion

What is Data-in-Motion?

Data-in-motion, also called data in transit, is data actively being transmitted across a network. It includes data moving between internal systems, files uploaded to cloud storage, email attachments being sent, API calls transferring records between applications, database query results being returned to a client, and any other data crossing a network boundary.

It's one of three data states. Data-at-rest is stored and not moving. Data-in-use is actively being processed in memory. Data-in-motion is everything in between: data that has left one system and hasn't yet arrived at another.

The moment data moves, it crosses boundaries. Boundaries are where protection controls are applied. And boundaries are where most modern data loss actually occurs.

How data-in-motion is protected

Two distinct controls address different threat vectors for data-in-motion.

Transport encryption: TLS (Transport Layer Security) 1.2 and 1.3 are the current standards for encrypting data in transit. TLS establishes an encrypted channel between two endpoints before any data is exchanged. Data transmitted over the channel is encrypted in transit, making interception by network-layer attackers — packet sniffing, man-in-the-middle attacks, network tap attacks — cryptographically infeasible without the session keys.

TLS is broadly deployed: HTTPS is TLS on top of HTTP. SFTP, FTPS, encrypted email (STARTTLS), and VPN tunnels all implement transport encryption. PCI DSS Requirement 4 mandates strong cryptography for cardholder data transmitted over open, public networks. GDPR Article 32 lists encryption as an appropriate technical measure for security of processing. Most cloud providers encrypt data in transit by default.

The coverage is good. The gaps are real. But they're not where most people expect.

DLP content inspection at egress: Transport encryption protects against external interception. It does nothing to prevent an authorised insider from sending sensitive data to an unauthorised destination over a perfectly encrypted connection.

An employee uploading a customer database export to a personal Dropbox account uses HTTPS. The connection is encrypted end-to-end. The content is leaving the organisation. The encryption didn't stop the data loss — it encrypted it.

That's the critical distinction. Protecting data-in-motion against external interception is a solved problem for most organisations. Protecting data-in-motion against authorised misuse over approved channels is where most real data loss happens and where most programmes have gaps.

Data-in-motion vs data-at-rest vs data-in-use

The three states are not sequential. The same piece of sensitive data moves through all three during normal operation: it sits at-rest in a database, moves in-motion when a query result is transmitted to an application, is held in-use while the application processes it, and may move in-motion again when the result is sent to a user or another system.

Protecting data through all three states requires controls appropriate to each state, applied to all three simultaneously.

Why approved channels are the real data-in-motion risk

Traditional network security assumed that protecting the perimeter would protect data-in-motion. Block outbound connections to suspicious IPs. Monitor for unusual protocols. Scan traffic for known malware signatures.

That model broke when data loss shifted from covert channels to approved ones.

MITRE ATT&CK documents exfiltration over web services (T1567) and cloud storage (T1567.002) as common techniques precisely because they use channels that are already allowed. Uploading to Dropbox, Google Drive, OneDrive, SharePoint, or any enterprise-approved file sharing service uses the same HTTPS connection as legitimate business use. The traffic is indistinguishable at the network layer. The content is what differs.

So blocking based on destination domain doesn't work — the destination is approved. Blocking based on protocol doesn't work — it's HTTPS. Blocking based on volume is imprecise and generates false positives on legitimate large uploads.

What works is content inspection: understanding what data is in the transmission before it leaves, whether that data is sensitive, and whether the destination is an authorised recipient for that specific data. A 50MB upload to a corporate SharePoint folder from a finance analyst is normal. The same upload to a personal OneDrive from the same analyst at 11pm is anomalous. The channel is identical. The content and context are what produce the risk signal.

That's where DLP at egress points connects to classification: DLP policies can only inspect data effectively when they know what sensitivity the data carries. Unclassified data-in-motion receives no content-based DLP enforcement regardless of how sophisticated the DLP product is.

Data-in-motion and the exfiltration sequence

Most significant data loss incidents don't consist of a single large transmission. They consist of a sequence: data is accessed, staged locally, transformed or compressed, then transmitted in one or multiple egress events.

Each transmission is a data-in-motion event. The individual upload might not trigger a DLP rule because it's within normal size parameters. The sequence — access, stage, compress, upload — only becomes a meaningful signal when the events are evaluated together across the access and movement chain.

That's why data-in-motion security can't be fully solved at the egress point alone. The transmission event at the end of the sequence is the last opportunity to intervene. Detecting the sequence earlier, before the transmission, requires visibility into the data access and staging events that preceded it. A single large upload to cloud storage is an event. The same upload, preceded by a database query against sensitive customer records and followed by local compression, is evidence of an exfiltration sequence.