mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-08-06 09:26:52 +01:00
bfda67a95a
* Promote security knowledge from community to Microsoft layer Pure git-mv relocation of the SECURITY domain from the community layer to the Microsoft layer. No content changes. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Address review feedback on security knowledge promotion - do-not-grant-rights-beyond-a-users-entitlement.md: drop the See sample reference to a .good.al file that does not exist - Remove the 'Contributions welcome' boilerplate line from compose-permission-sets, prefer-oauth2, and protect-sensitive-data - protect-sensitive-data-in-temporary-tables: remove the pointless DeleteAll on the locally scoped temp buffer in the good sample and reword Best Practice to note local buffers are cleaned up automatically - Drop guard-bulk-operations-with-istemporary from the promotion; it stays in the community layer pending a decision on whether it is security Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Remove Contributions welcome boilerplate from do-not-grant article for consistency Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Jesper Schulz-Wedde <jesper.schulzwedde@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
26 lines
1.8 KiB
Markdown
26 lines
1.8 KiB
Markdown
---
|
|
bc-version: [all]
|
|
domain: security
|
|
keywords: [dataclassification, gdpr, privacy, euii, compliance]
|
|
technologies: [al]
|
|
countries: [w1]
|
|
application-area: [all]
|
|
---
|
|
|
|
# Classify every field with DataClassification
|
|
|
|
## Description
|
|
|
|
Every field on every AL table and table extension must have a resolved `DataClassification` value, either declared directly on the field or inherited from a table-level default. The value drives GDPR tooling, data-subject requests, retention policies, and audit reporting — all of which rely on the field metadata to know what data to include, anonymize, or delete. A field with no field-level property and no table-level default resolves to `ToBeClassified`, which is a compliance gap, not a neutral state.
|
|
|
|
## Best Practice
|
|
|
|
Choose the narrowest value that accurately describes the field's content: `EndUserIdentifiableInformation` for data that directly identifies a person, `EndUserPseudonymousIdentifiers` for indirect identifiers, `CustomerContent` for business operational data, `SystemMetadata` for system-generated housekeeping, `AccountData` for tenant/billing, `OrganizationIdentifiableInformation` for organization-level identifiers. Use a table-level default for homogeneous tables, and override individual fields whose content differs from that default. When uncertain between two values, pick the stronger protection.
|
|
|
|
See sample: `classify-every-field-with-dataclassification.good.al`.
|
|
|
|
## Anti Pattern
|
|
|
|
Leaving `DataClassification = ToBeClassified` on a field, omitting classification when the table has no default, or relying on a table-level default that understates a field's actual content. Code in this state fails compliance audits and breaks the subject-access-request and retention tooling that depends on the property being set correctly.
|
|
|
|
See sample: `classify-every-field-with-dataclassification.bad.al`.
|