RED data is data that should be restricted because its exposure would create legal, privacy or operational risk. In practice, this can include payment card data, personal identity records, or sensitive customer content held in a system that must be tightly access-controlled. Classify it, limit access, encrypt it and track who can copy, export or process it.
What counts as RED data in day-to-day operations?
red data is information you treat as highly restricted because exposure could cause legal, privacy, or operational harm. In practice, that usually means the most sensitive records in a business process, not just “important” data. The key question is whether unauthorized disclosure, export, or misuse would create immediate consequences that your team would need to answer for.
That is why RED data is often defined by handling rules rather than by file type alone. A record becomes RED when it combines sensitivity, access restrictions, and potential blast radius, such as payment data, personal identity details, or customer content that should not be broadly visible inside a system.
Which examples usually fit RED data?
Common examples include payment card data, government-issued identity details, account records tied to a person, and sensitive customer communications. The label can also apply to internal material when it would be damaging if copied out of a controlled environment, such as regulated case notes, security investigations, or confidential customer support transcripts.
What matters is the handling context, not only the content category. The same dataset may be ordinary in one workflow and RED in another if the second workflow increases exposure, combines it with more sensitive identifiers, or makes export and replication easier.
For organisations trying to formalise the label, a Data Classification Guide is useful because it shows how levels, labels, and handling rules work together instead of treating classification as a one-word tag.
How should RED data be handled once it is identified?
RED data should be tightly access-controlled, encrypted, and monitored so that only approved users and systems can process it. The practical controls are usually the familiar ones that limit who can see it, where it can move, and which actions are permitted, such as copy, export, download, or bulk query.
In mature environments, the most important control is often not storage protection alone but movement control. If people can pull RED data into spreadsheets, tickets, exports, or unmanaged analytics tools, the classification loses value even if the source system is well protected.
EU General Data Protection Regulation (GDPR) is relevant where the RED dataset includes personal data, because it reinforces the expectation that sensitive personal information must be protected by design and processed with appropriate security controls.
Risk and Threat Considerations
RED data becomes risky when classification exists on paper but copy, export, and downstream use remain easy in practice. The main exposure is that one overly broad permission, one misplaced export, or one improperly shared report can turn a restricted dataset into a widely distributed one.
Failure mechanism: Weak access governance, excessive export rights, or unsecured replicas allow sensitive records to be copied beyond the intended trust boundary, often without immediate visibility.
Impact: The result can be privacy harm, regulatory exposure, contractual breach, customer trust damage, or operational disruption if the data is misused, leaked, or used outside approved processes.
Where RED data is tied to authentication material, customer identity data, or regulated records, the exposure can also become a broader access problem rather than a simple confidentiality issue. The system may not only leak information, it may reveal enough about users, workflows, or controls to enable further abuse.
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 | RED data handling depends on limiting who can access and export restricted records. |
| SC-28 — Protection of Information at Rest | RED data should be encrypted when stored to reduce disclosure risk if systems are exposed. | |
| Recommendation — Restrict RED datasets to the minimum roles and permissions needed. Encrypt RED data at rest wherever it is stored. | ||
| ISO/IEC 27001:2022 | A.5.12 — Classification of information | The question is fundamentally about identifying and labelling restricted data for special handling. |
| Recommendation — Define RED data classes and attach handling rules to each class. | ||
Practitioner Guidance
What to verify: Confirm that your RED label maps to concrete handling controls, not just a policy glossary. If a user can export the data, cache it elsewhere, or re-share it through another tool, the control set is incomplete.
What practitioners underestimate: The highest-risk path is often secondary use, not the primary system. A dataset that is protected in production can still become unsafe when copied into testing, analytics, support, or ad hoc reporting environments.
Practitioner takeaway: RED is not just “sensitive data”, it is data whose movement must be actively constrained, because the real risk appears when the information leaves the system that originally protected it.