Why document your sensitive metadata using MetaFields?
In today’s complex regulatory landscape, Salesforce Orgs must adhere to various compliance frameworks such as GDPR, HIPAA, CCPA, and more. Each regulation has specific requirements for how sensitive information should be classified, accessed, and protected.
Using Elements, you can document and store all those rules regarding who should and shouldn't have access, why, and how data should be handled inside your Salesforce metadata dictionary.
Align compliance and development: you can ensure that rules and policies defined by the legal/compliance team are present front and center to your developers and admins when working on the Org.
Simplify and accelerate audits: Who should have access to sensitive objects and fields? Is 'John Smith' supposed to be able to see that data? These questions are difficult to answer. However, with that information stored directly against the metadata, you empower your admin and audit team to make determinations faster.
When to Use This Guide?
This guide is essential when your organization:
Handles Sensitive Data: If your Salesforce Org stores personal information, health data, payment details, or any other sensitive information subject to regulatory control.
Must Comply with Multiple Regulations: If you operate under various compliance regimes, such as GDPR, HIPAA, CCPA, and PCI, and need a unified approach to managing data classification and access controls.
Needs to Prepare for Audits: If you are preparing for internal or external compliance audits and require a clear, traceable methodology for classifying and handling sensitive data.
Faces Complex Regulatory Overlap: When your organization deals with data subject to multiple regulatory frameworks and needs to ensure that the strictest requirements are consistently applied.
Prerequisites
In order to follow this guide you need:
Salesforce Metadata Management license
Synced Salesforce Org into Metadata Dictionary
This solution guide covers use-case for using MetaFields functionality. You can learn more about setting it up here.
MetaField definitions
It is best practice to let your compliance/ legal team define the categorization of sensitive data to align with internal and regulatory standards. The example below is provided as a guidance but it might differ from your legal team's recommendation.
Create following 9 MetaFields with compliance-specific classifications for standard and custom objects and fields.
Compliance Regime (Picklist):
Values: Not applicable, GDPR, HIPAA, CCPA, PCI, SOX, COPPA, PersonalInfo, and PII
Purpose: Specifies the compliance acts, definitions, or regulations that are related to the metadata's data.
Sensitivity Level (Picklist):
Values: Public, Internal, Confidential, Restricted, MissionCritical.
Purpose: The sensitivity of the data stored in metadata. It drives data handling requirements.
Data Handling Requirements (Multi-Picklist):
Values:
No special data handling requirements
Access Controls (Internal Use)
Monitoring
Access Controls (Confidential)
Data Masking
Access Logging
Access Controls (Restricted)
Data Encryption (At Rest and In Transit)
Data Anonymization
Access Logging and Auditing
Strict Access Controls
Strong Data Encryption (At Rest and In Transit)
Full Data Anonymization
Comprehensive Access Logging and Auditing
Legal Review Required
Purpose: Lists specific data handling requirements based on the sensitivity level.
Access by business function (Multi-picklist):
Values:
Finance: For roles in finance, accounting, and related functions.
Sales: For roles in sales, business development, and account management.
Marketing: For roles in marketing, communications, and brand management.
HR: For roles in human resources, employee relations, and recruitment.
IT: For roles in IT, including system administrators, developers, and cybersecurity professionals.
Legal/Compliance: For roles in legal, regulatory compliance, and data protection.
Operations: For roles in operations, supply chain management, and logistics.
Customer Support: For roles in customer service, support, and client relations.
R&D/Product Development: For roles in research, development, and product management.
Executive Office: For roles directly supporting the executive team, such as executive assistants.
Consultants: For external consultants engaged for specific projects.
Purpose: To help you easily classify departments with interest in having access to that information.
Access by seniority (Multi-picklist)
Values:
System Administrators (Only): For data that should only be accessible by system administrators.
Executive: C-suite, VPs, and other top-level decision-makers.
Director: Department heads and senior managers.
Manager: Mid-level managers responsible for teams or projects.
Senior Staff: Experienced professionals with significant responsibilities but no direct managerial role.
Staff: General employees and team members.
Contractor: External contractors and consultants with specific access needs.
Intern: Interns or temporary staff with restricted access.
Purpose: To help you easily classify whether data should be widely accessible to all employees in a given department or only senior figures.
Access Justification (Long Text):
Purpose: Captures the reason why a particular group needs access. This field should detail the business or legal justification for the access.
Regulatory Compliance Status (Picklist):
Values: Compliant, Non-Compliant, Review Required
Purpose: Indicates whether the data component meets the requirements of the selected compliance regime
Legal Review Status (Picklist):
Values: Approved, Pending, Rejected
Purpose: Tracks whether the data classification has been reviewed and approved by legal or compliance teams
Audit Last Review Date (Date):
Purpose: Document when the classification, controls and access were last reviewed to ensure it is still necessary and appropriate.
Salesforce provides similar capability called 'Data Classification'. It also allows you to document compliance regimes and data sensitivity.
However, it is only limited to fields, not objects or other metadata types, and you can only classify one field at a time. With Elements, you can bulk classify hundreds of components at a time.
Implement Conditional Logic between sensitivity level and data handling requirements
Sensitivity Level | Conditional Data Handling Requirements
|
Public | - No special data handling requirements
|
Internal | - Access Controls (Internal Use): Ensure only authorized internal users can access the data. |
| - Monitoring: Implement basic monitoring to track who accesses the data |
Confidential | - Access Controls (Confidential): Limit access to a specific group within the organization. |
| - Data Masking: Mask data if shared externally to prevent exposure of sensitive information. |
| Access Logging: Log access to the data for auditing purposes. |
Restricted | - Access Controls (Restricted): Access restricted to approved employees or contractors. |
| Data Encryption (At Rest and In Transit): Encrypt data both when stored and during transmission. |
| - Data Anonymization: Anonymize data where applicable to protect identities.
|
| - Access Logging and Auditing: Log and audit all access to the data. |
MissionCritical | - Strict Access Controls: Implement the highest level of access control, limited to a small group of authorized users.
|
| - Strong Data Encryption (At Rest and In Transit): Apply robust encryption measures.
|
| - Full Data Anonymization: Anonymize all identifiable information where feasible.
|
| - Comprehensive Access Logging and Auditing: Log all access attempts and conduct regular audits.
|
| - Legal Review Required: Mandatory legal or compliance review for access and handling of data.
|
Documenting and managing your access controls using Elements
With properly defined MetaFields, you can proceed to classifying objects and fields that hold sensitive information and document who should have access to the data within.
Create custom view of objects in your Org
Start by creating a custom view of metadata that includes all the standard and custom objects in your Org. Ensure you include relevant standard attributes, like API name, label, description, and all of the defined MetaFields.
Then apply sorting alphabetically by name.
Tip: the reason to start by classifying objects, rather than fields, is that there are tends of thousands of individual fields in the Org, and 'only' few hundred objects.
By focusing our attention on the objects first, we can quickly understand where we need to focus our attention and dig deeper to analyze and document field-level information.
Work with legal team to classify objects
Your legal / compliance team should have an understanding of how different compliance regimes and sensitivity levels influence needed data handling requirements and dictate access controls.
Provide them with your categorization definitions, and ask then to provide guidance on how to decide what data handling requirements and access levels are required.
Then organize a workshop with your legal team to review each object in your Org and define whether it falls under a given compliance regime or not and how it should be classified.
You can classify each object one by one using the Assessment tab in the right panel:
You can then export the object classification data from your custom view as a CSV file and provide it to the legal team for review and confirmation in a spreadsheet.
Update fields
After the review of the objects, you should understand which objects:
do not contain any sensitive data and do not fall under any compliance regime
seem to hold some sensitive data and may fall under a compliance regime
You can then create custom views for fields belonging to objects classified as 'Not applicable' and bulk-update them to the same status.
For objects that were classified differently, you might need to schedule separate reviews of individual fields with the legal / compliance department.
Take action
After the review is finished, you will end up with a list of objects and fields classified by their compliance regime, sensitivity level, expected access and other attributes. In many cases the Data Handling Requirements will require to provide masking, encryption or other means of protecting information.
Custom views of metadata come equipped with many single and bulk operations. You can raise user stories and document tasks to encrypt, mask or otherwise protect specified metadata in your custom view. You can then pick up those stories from your backlog and deliver then when there is capacity.
Regular review
Remember to schedule regular reviews of the access controls and sensitivity levels. Using MetaFields defiend earlier, document the date when you plan to do the next review.
We recommend to do a compliance audit of your Org at least once a year, more than that for objects and fields that contain truly business critical data.
Create an event or a reminder in your calendar with that date for you and your team to remember to plan for that review.
You can create a custom view of metadata that includes all components that have a 'Audit Last Review Date (Date)' more than N months ago. That way you will have a single list of all of your to-dos when the time comes.
Audit if the right people have access
The value of documenting compliance, sensitivity, business controls, and expected access in your Metadata Dictionary isn't simply for audit's sake.
It empowers your development team to be more conscious and aware when they are working with sensitive metadata. It also helps them to understand if everyone who currently has access to certain data, should have that access.
You can run analysis of sensitive metadata and compare it against insight into who has access to it, therefore empowering every admin to spot non-compliance and security risks.
The capability of auditing who has access to sensitive metadata and why is covered in this separate solution guide.