Data classification for Dynamics 365

Different data has different protection needs — public marketing content vs employee compensation vs customer credit card data. Data classification assigns each data element a sensitivity tier, driving security controls, retention rules, and compliance decisions. For Dynamics 365 deployments, classification is a programme spanning Dataverse, F&O, integrations, and the broader Microsoft Purview ecosystem.

Classification tiers. Most organisations use 3–4 tiers:

• Public — intentionally shared externally.
• Internal — for employees, not external.
• Confidential — restricted internally; need-to-know.
• Highly Confidential / Restricted — most sensitive; minimal access.

Some add a "Personal" or "Regulated" tier for GDPR / HIPAA / PCI data.

Where classification lives.

• Microsoft Purview Information Protection — central labelling for M365 content (files, emails).
• Dataverse column-level classification — Dataverse columns can be flagged with a data classification.
• F&O table / field properties — some F&O fields are flagged as personal data for GDPR purposes.
• Custom classification fields — extension fields capturing sensitivity per record.

The challenge: making classification consistent across these surfaces.

Classification at the column level. In Dataverse, columns can be marked with a classification:

• Personal data.
• Financial data.
• Health data.
• Other regulated data.

The classification surfaces in:

• GDPR reports — what personal data does this table hold?
• DLP policies — sensitive columns trigger additional protection.
• Audit logs — access tracked.

Personal data identification. GDPR and similar regulations require identifying personal data:

• Names, addresses, emails.
• Identifiers (employee IDs, customer IDs).
• IP addresses.
• Behavioural data (clicks, purchases tied to a person).

Dataverse provides a Personal Information flag at column level. Mark every personal data column; report compiles automatically.

Classification at the record level. Beyond column-level, individual records may have different sensitivity:

• A customer account flagged as VIP — sensitive.
• A standard customer — internal.
• A test customer — public-equivalent.

A Sensitivity choice column on records captures this; downstream filtering and access logic respects it.

Microsoft Purview integration.

• Purview sensitivity labels can be applied to Dataverse rows via integration.
• Labelled content triggers Purview policies (DLP, retention, expiration).
• Records can inherit labels from related content.

The integration is still maturing; capabilities expand each wave.

Driving controls from classification.

• Access — restricted classifications require elevated roles.
• Audit — high-classification access logged in detail.
• Encryption — at-rest and in-transit; everything in Dataverse is encrypted, but additional keys for higher classifications via CMK.
• Retention — different retention periods per classification.
• Geographic — some classifications cannot leave specific regions.
• Sharing — restricted classifications can't be shared externally.

Implementation pattern.

1. Define the classification tiers — leadership decision; documented.
2. Identify regulated categories — GDPR personal data, PHI, PCI, etc.
3. Inventory current data — which Dataverse tables and F&O entities hold what.
4. Map data to tiers — every meaningful field classified.
5. Implement controls — security, retention, encryption.
6. Train staff — what each tier means operationally.
7. Monitor — periodic reclassification, drift detection.

Common pitfalls.

• Over-classification. Everything marked highly confidential; controls so strict business can't function.
• Under-classification. Sensitive data not identified; exposure when later discovered.
• Classification static. Classifications set at deployment, never reviewed; data nature changes but classification doesn't.
• No enforcement. Classification exists in metadata; nothing actually limits behaviour.
• Cross-system inconsistency. Same data classified differently in Dataverse vs F&O vs SharePoint.
• Training gap. Staff don't understand what each classification means; behavioural inconsistency.

Regulated data specifics.

• PCI (credit card) — credit card numbers must never enter Dynamics directly; gateway tokenisation only.
• HIPAA (health) — strict access controls; audit logs reviewed; encryption with CMK considered.
• GDPR (EU personal) — right to erasure, right to access, right to portability — all need data inventory.
• SOX (financial) — controls over financial systems; segregation of duties.

Each regulated category has specific operational requirements beyond classification.

Data residency. Some classifications trigger residency:

• "EU customer data" — must stay in EU regions.
• "China data" — must stay in China.

Dynamics 365 supports multi-region deployments; the classification tells you where the data should live.

Right to erasure / data subject requests. GDPR-style rights require:

• Find all data about a subject.
• Compile in portable form.
• Delete after retention obligations exhausted.

This is hard without classification — if you don't know which fields hold personal data, you can't fulfill the request.

Operational rhythm.

• At record creation — classification assigned (default or explicit).
• Quarterly review — sampling-based classification accuracy check.
• Annual full audit — comprehensive review.
• At policy change — reclassification when new regulations or business rules emerge.

Strategic positioning. Data classification is the foundation of information security in Dynamics 365. Without it, every security and compliance decision happens reactively. With it embedded into the data model and processes, decisions become systematic. The investment is substantial — multi-month classification programme is typical — but the payback in compliance posture, breach prevention, and operational clarity is high. Most regulated organisations cannot defend their posture to auditors without it.