Why does data in use create more risk than data at rest or in motion?

Data in use creates more risk because the information must be readable to be useful, which means encryption is no longer the main safeguard. At that point, the question is whether a legitimate user should move the data at all. The exposure happens during ordinary tasks, especially when data is pasted into chatbots or copied into unsanctioned tools.

Why data in use is exposed in ways encryption alone cannot prevent

data at rest and data in motion can often be protected primarily by encryption, but data in use must be decrypted or otherwise made intelligible for an application, user, or service to act on it. That changes the problem from protecting stored bits to controlling who can access, view, move, or copy the readable data while it is actively being processed.

The practical difference is that data in use is exposed inside real workflows, where trust decisions are often weaker than the encryption boundary suggests. A user who is legitimately viewing a record can still copy it, paste it into another tool, or move it into a channel the original control owner never intended.

Why ordinary business actions become the main exposure point

Most risk is not created by exotic exploitation. It comes from everyday actions that require data to be visible: editing, analysis, support handling, debugging, approval, collaboration, and automation. Once the data is readable, the security question shifts to whether the current person, process, or system should be allowed to propagate it further.

This is why unsanctioned tools matter so much. Chatbots, browser extensions, personal notes, file-sharing tools, and ad hoc copy-and-paste workflows can bypass the intended control boundary even when the original system is well protected. The exposure is often a misuse of legitimate access, not a break in encryption.

Data in use also creates a larger operational attack surface because the same readable content may be consumed by multiple parties, applications, and sessions. That increases the chance of accidental disclosure, overcollection, and secondary retention in logs, caches, prompts, exports, or screenshots.

Why the control problem becomes governance, not just cryptography

Protecting data in use depends on policy, access design, monitoring, and user behaviour as much as on technical secrecy. Organizations need to define what may be viewed, where it may be processed, which tools are allowed, and when a readable copy must be blocked, redacted, or destroyed.

That makes classification and handling rules essential. Sensitive data may need additional restrictions when it is in a form that humans or agents can read, because once readability exists, confidentiality depends on limiting downstream movement rather than on the encryption layer itself.

Good control design therefore focuses on reducing unnecessary exposure windows. The most effective patterns are to minimise who can see the data, limit where readable data can be pasted or exported, and make unauthorized handling visible quickly enough to intervene before the exposure spreads.

Risk and Threat Considerations

Data in use is riskier because the trusted execution moment is also the moment of maximum exposure. If the readable data can be copied, redirected, or retained in uncontrolled places, the main safeguard shifts from cryptography to governance and user discipline.

Failure mechanism: A legitimate session, application, or workflow reveals the data, then a user or connected tool moves it into a less controlled environment, creating disclosure, retention, or misuse outside the original protection boundary.

Impact: The organization can lose confidentiality even when storage and transport controls are strong, and the resulting exposure can persist through logs, tickets, prompts, local files, screenshots, or third-party services.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Readable data handling depends on limiting who can copy or move it.
	AU-2 — Event Logging	Data-in-use exposure often shows up in copy, export, or tool-use events.
	SC-28 — Protection of Information at Rest	Contrasts storage protection with the extra exposure created once data is readable.
Recommendation — Restrict readable-data access to the minimum roles needed for the task. Log sensitive-data access and movement events for review and response. Use storage encryption as a baseline, then add handling controls for readable data.
ISO/IEC 27001:2022	A.5.12 — Classification of information	Classification determines how strictly readable data must be handled in use.
	A.8.12 — Data leakage prevention	Controls are needed to stop readable data from leaving sanctioned workflows.
Recommendation — Classify data so handling rules match the sensitivity of readable content. Apply DLP controls to block or flag unauthorized copying and export.

Practitioner Guidance

What to prioritise: Treat data in use as a handling problem first and a crypto problem second. The decisive control is often whether readable data can leave the sanctioned workflow, not whether it was encrypted beforehand.

What to verify: Confirm that the data path has explicit controls for copy, export, paste, and third-party tool use. If teams cannot explain where readable data is allowed to go, the policy is not operationally real.

Decision rule: If the data must become readable for work to happen, assume the exposure boundary has already shifted and require tighter authorization, stronger monitoring, and narrower tool allowance before the data is presented.

Practitioner takeaway: The key question is not whether data can be encrypted at rest or in transit, but whether readable data is still being kept inside a controlled, observable, and justifiable use path.