JourneyToCTA Diaries Part 10 - Data Governance
- Shreyas Dhond
- 2 days ago
- 6 min read
In the previous blog, we explored data security fundamentals as a key aspect of enterprise architecture within Salesforce.
We covered encryption at both rest and in transit, highlighting how sensitive data can be protected across storage and communication layers. We also discussed data obfuscation techniques such as pseudonymization, anonymization, and tokenization, and how they help safeguard sensitive information while still enabling business processes.
In addition, we looked at data archival and restoration strategies, emphasizing the importance of managing stale data outside the platform while maintaining the ability to restore it when needed. Finally, we clarified the distinction between data deletion and data purging, and why understanding this difference is critical for compliance and data lifecycle management.
Together, these concepts form the foundation for designing secure, compliant, and scalable data architectures in Salesforce. In this blog we are going to be focussing on data governance considerations and some of the key features and functionality in Salesforce that help us build a compliant solution depending on the standards and regulations.
Several data regulations impact enterprise solutions across industries and government jurisdictions. The purpose of these regulations is to ensure that customer data is protected, used ethically, and processed in compliance with privacy, security, and legal standards, thereby safeguarding individual rights and maintaining trust.
Privacy Data Regulations
Data privacy regulations such as the General Data Protection Regulation (GDPR), Health Insurance Portability and Accountability Act (HIPAA), and California Consumer Privacy Act (CCPA) play a critical role in shaping how enterprises design and implement Salesforce solutions. While each regulation applies to different industries and geographies, they all share a common goal: to ensure that customer data is handled securely, transparently, and with explicit user control. GDPR focuses on broad personal data protection and individual rights across the EU, HIPAA enforces strict safeguards for protected health information in the healthcare sector, and CCPA emphasizes transparency and consumer control over personal data for California residents.
Data Residency
One of the primary architectural considerations driven by these regulations is data residency. Organizations must ensure that customer data is stored and processed in compliance with geographic restrictions, particularly under GDPR, which limits cross-border data transfers unless specific safeguards are in place. In Salesforce, this influences decisions such as selecting the appropriate regional instance, leveraging Hyperforce for regional cloud deployment, and potentially designing multi-org strategies to segregate data by geography. Architects must carefully evaluate where data originates, where it is stored, and where it is processed to ensure compliance.

Binding Corporate Rules (BCRs) and Standard Contractual Clauses (SCCs)
Under the General Data Protection Regulation (GDPR), organizations can meet cross-border data transfer requirements without changing data residency by leveraging approved transfer mechanisms when data must move outside the EU or UK. If the destination country has been granted adequacy status—such as under the EU–US Data Privacy Framework—data can be transferred without additional safeguards.
In cases where adequacy is not established, Salesforce supports compliance through mechanisms like Binding Corporate Rules (BCRs) and Standard Contractual Clauses (SCCs), both embedded within its Data Processing Addendum (DPA). These legal frameworks ensure that personal data transferred to non-adequate jurisdictions is still subject to GDPR-level protection.
In addition, Salesforce implements technical, organizational, and contractual safeguards as part of its Transfer Impact Assessment. Together, these measures enable organizations to maintain existing data residency strategies while still ensuring lawful and compliant global data processing.
Data Encryption
Encryption and data protection are central to meeting regulatory compliance requirements across frameworks such as the General Data Protection Regulation (GDPR) and the Health Insurance Portability and Accountability Act (HIPAA). These regulations require organizations to implement strong safeguards to protect sensitive personal and health data from unauthorized access, breaches, and misuse, making encryption a foundational control in any Salesforce architecture.
Tools like Salesforce Shield provide robust capabilities to address these requirements. Platform Encryption enables encryption of data at rest across standard and custom fields, files, and certain metadata. Field-level encryption allows organizations to selectively encrypt highly sensitive information such as Social Security Numbers, financial data, or protected health information (PHI). In addition, Event Monitoring and Field Audit Trail provide visibility and traceability into data access and changes, supporting compliance with audit and accountability requirements.
These capabilities are particularly important for GDPR, which mandates appropriate technical measures to protect personal data, and HIPAA, which requires encryption and audit controls to safeguard PHI. However, encryption is not a one-size-fits-all solution and must be implemented carefully. Encrypted fields may have limitations in search, filtering, reporting, and indexing, and excessive encryption can impact system performance and usability.
As a result, architects should adopt a risk-based approach by aligning encryption strategies with data classification policies. Sensitive data should be clearly identified and categorized (e.g., PII, PHI, financial data), and only data that truly requires encryption should be encrypted. Additional considerations include key management strategies such as Bring Your Own Key (BYOK), planning for backup and recovery, and ensuring that encryption policies are consistently applied across integrated systems.
Ultimately, a well-designed encryption strategy balances security, compliance, and system usability. By combining encryption with other controls such as access management, data minimization, and monitoring, organizations can achieve a comprehensive data protection posture while maintaining optimal Salesforce performance.
Consent Management
Consent management is another critical area influenced by regulations such as the General Data Protection Regulation (GDPR), California Consumer Privacy Act (CCPA), and the Health Insurance Portability and Accountability Act (HIPAA). Each regulation introduces specific requirements around how customer consent must be obtained and managed. GDPR requires explicit, informed opt-in consent before processing personal data, CCPA provides consumers the right to opt out of the sale or sharing of their data, and HIPAA mandates explicit authorization for the use and disclosure of protected health information (PHI).
Salesforce supports consent management through its data model, including objects such as Individual, Contact Point Consent, and Data Use Purpose. These enable organizations to capture detailed consent records, including when consent was given, how it was obtained, the purpose of processing, and the communication channel (e.g., email, phone, SMS). This structured approach ensures that consent is not only recorded but also traceable and auditable for compliance purposes.
A well-designed solution ensures that consent is granular and purpose-driven rather than broad or implicit. For example, a customer may consent to receive marketing emails but not SMS messages, or may allow data usage for service-related communication but not for third-party sharing. This level of granularity is essential to comply with regulatory expectations and to build customer trust.
In addition, consent must be consistently enforced across all systems where customer data is used. This requires integrating consent data across Salesforce clouds (such as Sales Cloud and Marketing Cloud) as well as external platforms. Architects should design for real-time or near real-time synchronization of consent preferences to ensure that downstream systems honor the latest customer choices.
Finally, organizations should implement processes for consent lifecycle management, including updates, withdrawals, and versioning of consent policies. Maintaining historical records of consent and changes over time is critical for auditability and demonstrating compliance during regulatory reviews.
Data Subject Rights
Finally, regulations such as the General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA) mandate support for data subject rights, including the right to access, delete, correct, and in some cases port personal data. These rights require organizations to provide transparency and control to individuals over how their data is used and maintained.
To support these requirements, Salesforce solutions must incorporate mechanisms for handling Data Subject Access Requests (DSARs). This involves the ability to locate all relevant customer data across multiple objects (such as Accounts, Contacts, Cases, and Activities) and across integrated systems. Organizations must be able to compile and export this data in a structured format when requested, as well as delete or anonymize it in accordance with regulatory obligations.
A key challenge is ensuring that data is consistently managed across the entire ecosystem, not just within a single Salesforce org. Architects should design centralized privacy request management processes, often using automation tools like Flow or Apex, to orchestrate tasks such as data discovery, approval workflows, and execution of deletion or anonymization actions. Maintaining detailed audit logs of all requests and actions taken is critical for demonstrating compliance during audits.
Salesforce also provides capabilities such as Privacy Center, which helps streamline and automate the processing of data subject requests. Privacy Center enables organizations to manage DSARs at scale by providing tools for data discovery, request tracking, and secure data retrieval or deletion across connected systems. This reduces manual effort and ensures a more consistent and compliant approach to handling privacy requests.
Conclusion
Overall, these privacy regulations require Salesforce architects to adopt a “privacy by design” approach. This means embedding compliance considerations into every layer of the solution, from data modeling and storage to security, integration, and user access. By focusing on data minimization, strong governance, and end-to-end enforcement of privacy controls, organizations can not only meet regulatory requirements but also build trust with their customers. In the next blog we will cover payment processing regulations and the patterns we can use to comply with these requirements.






Comments