Data Classification Settings for Sensitive Fields

Overview
Data Classification in Salesforce is a set of metadata attributes that let administrators tag fields according to who owns them, how sensitive they are, and which compliance regulations they fall under. It lives inside the Auditing and Monitoring domain of the Advanced Administrator exam because its purpose is governance and visibility: it helps you document, audit, and monitor where sensitive data lives in your org so that you can make informed decisions about security, encryption, retention, and compliance.

Why Data Classification Matters
Modern organizations are subject to regulations such as GDPR, CCPA, HIPAA, PCI DSS, and COPPA. Each of these requires a company to know exactly which systems and fields hold regulated or personal data. Without a classification scheme, an admin trying to answer a question like Which fields in our org contain personally identifiable information? would have to inspect hundreds or thousands of fields manually.

Data Classification solves this by:
- Creating a single, consistent inventory of sensitive fields across standard and custom objects.
- Assigning accountability through a named Data Owner for each field.
- Feeding downstream Salesforce tools such as Shield Platform Encryption, Security Center, Privacy Center, and Data Mask, which can use classification to prioritize or automate protective actions.
- Supporting internal and external audits by making classification data queryable and reportable.
- Flagging fields that are candidates for deprecation or that should be hidden, which supports data hygiene and technical debt reduction.

What Data Classification Is (and Is Not)
It is critical to understand that Data Classification is metadata about a field. It does not enforce any access restriction, encryption, or masking by itself. Setting a field to Restricted does not stop any user from viewing it. Actual protection still comes from Field-Level Security, permission sets, sharing rules, Shield Platform Encryption, and similar controls. Classification is the documentation and governance layer that informs those controls; exam questions frequently test whether you understand this distinction.

The Four Data Classification Metadata Fields
When you edit a field in Object Manager, the Data Classification section exposes four attributes:

1. Data Owner
Identifies the user or public group responsible for the field and its data. This creates a clear point of accountability for questions about data use, retention, and access. The owner can be a single user or a public group, which is useful when responsibility belongs to a team such as Compliance or Legal.

2. Field Usage
Describes the lifecycle status of the field. Values are:
- Active: the field is in use.
- Deprecate Candidate: the field is being considered for removal and should be reviewed.
- Hidden: the field should not be exposed to users or integrations.
Field Usage supports data hygiene and helps admins identify fields that are no longer needed, which indirectly reduces the sensitive data footprint.

3. Data Sensitivity Level
Indicates how confidential the data in the field is. The default picklist values, from least to most sensitive, are:
- Public: information that can be shared freely.
- Internal: information for employees and authorized contractors only.
- Confidential: information that could cause harm if disclosed outside the organization.
- Restricted: highly sensitive information with limited access on a need-to-know basis.
- Mission Critical: information whose compromise would cause severe damage to the business.
These values can be customized in Data Classification Settings to match your company's own classification scheme.

4. Compliance Categorization
A multi-select style attribute that records which regulations or data categories apply to the field. The default values are:
- PII: Personally Identifiable Information.
- HIPAA: U.S. health information privacy regulation.
- GDPR: European Union General Data Protection Regulation.
- PCI: Payment Card Industry Data Security Standard.
- COPPA: Children's Online Privacy Protection Act.
- CCPA: California Consumer Privacy Act.
A single field can be tagged with multiple categories; for example, a Social Security Number field might be tagged PII and HIPAA. These values can also be customized.

How It Works: Configuration Steps

Step 1 - Review Data Classification Settings
In Setup, enter Data Classification Settings in the Quick Find box. This page is where you manage the picklist values for Data Sensitivity Level and Compliance Categorization. You can add values that reflect your organizational taxonomy (for example, adding SOX or ITAR as compliance categories, or renaming sensitivity tiers to match an existing corporate policy). Keeping these values aligned with your corporate information security policy is a best practice so that Salesforce classification maps cleanly to classification in other systems.

Step 2 - Classify Individual Fields
Navigate to Setup, open Object Manager, select the object, click Fields and Relationships, select the field, and click Edit. In the Data Classification section, populate Data Owner, Field Usage, Data Sensitivity Level, and Compliance Categorization, then save. This works for both standard and custom fields on standard and custom objects.

Step 3 - Classify in Bulk
Editing fields one at a time is impractical for large orgs. Classification attributes are exposed through the Metadata API on the CustomField type (attributes such as businessOwnerUser, businessOwnerGroup, businessStatus, securityClassification, and complianceGroup), so you can retrieve field metadata, update it in a spreadsheet or source control, and deploy it back. Third-party AppExchange tools and Salesforce DevOps tooling also commonly support bulk classification.

Step 4 - Query and Report
Classification data is stored on the FieldDefinition entity and can be queried with SOQL. Useful fields include SecurityClassification (sensitivity level), ComplianceGroup (compliance categories), BusinessStatus (field usage), and BusinessOwnerId (data owner). A typical audit query would select these fields from FieldDefinition where EntityDefinition.QualifiedApiName equals the object you are reviewing, optionally filtering for SecurityClassification equal to Restricted or ComplianceGroup including PII. This is how an admin produces an inventory of sensitive fields for an auditor without clicking through every field.

Step 5 - Act on the Classification
Once fields are classified, use that information to drive actual controls:
- Review Field-Level Security and permission sets for fields marked Restricted or Mission Critical.
- Evaluate fields tagged PCI or HIPAA as candidates for Shield Platform Encryption.
- Enable Field History Tracking or Field Audit Trail on high-sensitivity fields so changes are captured.
- Use Security Center or Privacy Center, which can surface classification data to help manage data subject requests, retention, and policy compliance.
- Schedule a periodic review with each Data Owner to validate that classifications are still accurate.

Relationship to Other Auditing and Monitoring Features
The exam often places Data Classification alongside related tools, so be clear on the differences:
- Setup Audit Trail records who changed configuration and when; it does not describe data sensitivity.
- Field History Tracking and Field Audit Trail record changes to field values on records; classification describes the field, not its values.
- Event Monitoring captures user activity such as logins, report exports, and API calls; classification can help you decide which objects deserve closer monitoring.
- Shield Platform Encryption actually encrypts data at rest; classification is a planning input, not an encryption mechanism.
- Field-Level Security enforces who can see or edit a field; classification does not change visibility.

Best Practices
- Establish a classification policy with Legal, Security, and Compliance before tagging fields so that definitions of each level are agreed upon.
- Assign Data Owners to groups rather than individuals when possible to avoid gaps when people leave.
- Start with high-risk objects such as Contact, Lead, Account, and any custom objects storing financial, health, or identity data.
- Use Deprecate Candidate to flag unused sensitive fields, then remove them after confirming they are not referenced in automation, integrations, or reports.
- Build a saved SOQL query or report process that lists all fields by sensitivity so audits can be repeated consistently.
- Revisit classification whenever new fields are created; consider making classification part of your change management checklist.

Exam Tips: Answering Questions on Data Classification Settings for Sensitive Fields

1. Memorize the four attributes. Data Owner, Field Usage, Data Sensitivity Level, and Compliance Categorization. If a question asks what Data Classification lets you capture about a field, the answer will be one or more of these four.

2. Know the default picklist values. Sensitivity: Public, Internal, Confidential, Restricted, Mission Critical. Compliance: PII, HIPAA, GDPR, PCI, COPPA, CCPA. Field Usage: Active, Deprecate Candidate, Hidden. Questions may list a distractor such as Secret or Top Secret that is not a default value.

3. Remember that classification is metadata only. If an answer choice implies that setting a sensitivity level restricts access, encrypts data, or masks a field, it is wrong. Look instead for the option that mentions Field-Level Security, permission sets, or Shield Platform Encryption as the enforcement mechanism.

4. Know where to configure it. Picklist values are customized in Setup under Data Classification Settings; individual field tags are set in Object Manager on the field edit page. Bulk changes use the Metadata API.

5. Know how to report on it. When a scenario asks how an admin can provide auditors with a list of all fields containing PII or all Restricted fields, the correct answer involves querying the FieldDefinition object (SecurityClassification, ComplianceGroup, BusinessStatus, BusinessOwnerId) rather than manually reviewing fields or running a standard report.

6. Watch for scenario keywords. Phrases like identify which fields contain regulated data, assign accountability for data, document sensitivity, or prepare for a GDPR or HIPAA audit point toward Data Classification. Phrases like prevent users from seeing, encrypt, or track changes to values point toward FLS, Shield Encryption, or Field History Tracking respectively.

7. Understand Data Owner options. The owner can be a user or a public group. If a question asks how to assign responsibility for a field to the Compliance team, choosing a public group as Data Owner is the intended answer.

8. Connect classification to downstream tools. If a question mentions Security Center, Privacy Center, Data Mask, or planning an encryption rollout, recognize that Data Classification is the input that helps those tools identify and prioritize sensitive fields.

9. Eliminate answers that overstate scope. Data Classification applies to fields, not to records, reports, or dashboards. An answer suggesting you classify a report or a record as Confidential through Data Classification Settings is incorrect.

10. Use the process-of-elimination approach for multi-select questions. Typically the correct answers describe documenting, inventorying, owning, or reporting on sensitive fields, while incorrect answers describe enforcing security or altering data. Pick the governance-oriented choices.

Sample Question Walkthrough
A company must comply with GDPR and wants its administrator to produce a list of every field that stores personal data, along with the person responsible for each field. The administrator also wants to make sure the list can be regenerated each quarter with minimal effort. What should the administrator do?

Correct approach: Enable and customize Data Classification Settings as needed, tag the relevant fields with Compliance Categorization of GDPR and PII and assign a Data Owner, then run a SOQL query against FieldDefinition filtering on ComplianceGroup and returning BusinessOwnerId. This produces a repeatable, auditable inventory. Distractors would include enabling Field History Tracking (tracks value changes, not classification), restricting Field-Level Security (controls access, does not produce an inventory), or reviewing Setup Audit Trail (tracks configuration changes, not data sensitivity).

Summary
Data Classification Settings give Salesforce administrators a structured way to document who owns a field, whether it is in active use, how sensitive its data is, and which regulations apply. It is configured in Setup under Data Classification Settings and on each field in Object Manager, can be bulk-managed through the Metadata API, and is reportable through the FieldDefinition object. For the exam, remember that it is a governance and auditing tool that informs security decisions rather than enforcing them, know the four attributes and their default values, and be ready to distinguish it from Field-Level Security, Shield Platform Encryption, Field History Tracking, Setup Audit Trail, and Event Monitoring.