Is data-centric security the same as encryption?

No. Encryption is one possible control; the approach also concerns classification, permissions, handling rules and verification of those rules.

Does a confidential label always restrict access?

No. That depends on configured protection settings and the systems involved. Some labels simply communicate a category.

Can AI-generated summaries need the same protection as their sources?

Yes. A summary can reveal sensitive facts. Its handling should follow the information it contains and the applicable rules.

AI Glossary / Data engineering and architecture / Intermediate

Data-centric security

Definition

Data-centric security is an approach that organizes protection around the information itself: what it contains, how sensitive it is, who may use it and under what conditions. It aims to maintain appropriate protection as data moves between storage systems, applications, devices and organizations, rather than relying solely on its original location.

What it means

A restricted document can leave a well-protected folder through a download, an email attachment or an AI workflow. Its contents remain sensitive even though its address has changed. Data-centric security asks how the handling rules will remain meaningful throughout that journey.

This is a broad security approach, not a single product or guarantee. It connects knowledge about data to enforceable controls. A classification such as confidential communicates a requirement; encryption, access decisions and application behavior help implement it. Network and device security still matter because they support the systems that handle the data.

How it works

Begin by identifying information, its owner and the consequences of inappropriate access, alteration or loss. Assign classifications that staff and systems can interpret consistently. Define handling rules for the relevant activities, such as viewing, downloading, sharing or supplying content to an AI service.

Next, connect those rules to controls at appropriate points. These might include identity checks, restricted access, encryption, monitoring and controls over export. Test the actual journey: a rule that works inside one application may not be enforced after conversion to another format.

Derived information needs attention too. A summary may retain sensitive facts even when it omits the original wording. Reviews should therefore consider new outputs, exceptions and changing access needs. The objective is an effective protection chain, with known limitations, rather than a decorative label attached once and forgotten.

Three practical examples

1. A consulting team shares a proposal with selected collaborators. It tests whether the intended recipients can read the protected document and whether an unrelated account is refused after download.

2. An internal AI assistant retrieves project documents. Its designers check each user's permission before including restricted material in an answer and examine how generated summaries are stored and shared.

3. A product team creates a support dataset containing customer messages. It separates unnecessary identifiers from the analysis copy and applies handling rules appropriate to the remaining content rather than assuming that a new filename makes it harmless.

Think of it this way

Think of a valuable item traveling with a handling card and a suitable locked container. The card explains the requirements; the container and authorized handlers put them into practice. The analogy has limits: digital information can be copied, transformed or photographed, and a receiving system may not understand the card. A label alone is not a lock.

Worked example

Suppose a fictional organization has 100 documents: 30 restricted and 70 public. A pilot applies labels correctly to all 100, so its classification coverage is 100%.

The team then tests three export paths for each restricted document, creating 90 path tests. Protection works on two paths but is lost on the third for all 30 documents. Successful enforcement is therefore 60 divided by 90, or about 66.7%, for this defined test set.

The organization cannot reasonably describe the pilot as fully protected merely because every document has a label. It must address the unsupported export route or change the permitted workflow. These figures measure test outcomes, not an estimated probability of a real breach; different documents and recipient actions could expose other weaknesses.

Illustrative case study

Fictional case: PolicyHarbour equips its proposal library with sensitivity labels and controlled access. A project coordinator then copies several restricted passages into a plain-text meeting note, which is stored in a broadly accessible workspace.

The security team discovers that its tests covered original document downloads but not newly created summaries. It adds review of derived outputs, clearer handling instructions and a supported sharing route for restricted notes. It also tests legitimate access so that collaborators can complete their work.

The lesson is that protecting a source file does not automatically settle the handling of every representation of its contents. The case illustrates a design gap and a response, not a claim of measured commercial success.

Common misconceptions and mistakes

Do not equate classification with enforcement. A label may deliberately provide information without activating encryption or access restrictions. Conversely, encrypted content can still be exposed through overly broad permissions or an authorized user's later actions.

Avoid assuming every application preserves every control. Format conversions, exports and integrations need testing. Also avoid classifying everything at the highest level without considering usability: unclear distinctions can make appropriate collaboration harder. Finally, data-centric security supports risk management; applying a named product does not itself prove that an organization's obligations have been met.

Business use

Businesses can use this approach when valuable information regularly crosses application and organizational boundaries. Start with a consequential workflow, such as proposal collaboration or an internal knowledge assistant, and follow the information from creation through disposal.

Useful measures include classification accuracy, tested control coverage, inappropriate access attempts and the time needed to resolve legitimate access problems. Assign an accountable owner to exceptions. Evaluate whether protection continues through the actual working process, including derived outputs, rather than counting labels as the sole result.

Check your understanding

Every restricted file is labeled, but an export creates an unrestricted copy. What is the most important next check?

Answer: Investigate and test the export path and the resulting copy's controls. Complete labeling coverage does not demonstrate that the information remains protected after transformation.

Related terms

Access Control
Data governance
Identity and access management
Data classification
encryption
data loss prevention
zero trust
information rights management
sensitive data

Learn next

Learn data classification first, then trace one document through download, conversion and summarization. Write the intended handling rule at each step and test it with an authorized account and an unauthorized account. Record unsupported paths and decide how the workflow should handle them.

Sources

NIST, Data Classification Practices: Facilitating Data-Centric Security Management, provides the approach's scope and classification rationale: https://csrc.nist.gov/pubs/pd/2021/07/22/data-classification-practices-datacentric-security/final

Microsoft, Learn about sensitivity labels, explains configurable protection, persistent metadata, scopes and labels without protection settings: https://learn.microsoft.com/en-us/purview/sensitivity-labels

The primary pages were read for these concepts. The workflow, calculations and fictional case are original teaching illustrations; product-specific capabilities should be checked for the intended application and configuration.

Previous: Data-centric programming language Next: Data cleaning