Vietnam published Decree 13/2023/ND-CP on 17 April 2023, with binding effect from 1 July 2023. The decree is Vietnam's first comprehensive personal-data protection law, modelled in spirit on the EU GDPR but adapted to local context. For banks running Salesforce Financial Services Cloud (FSC) in Vietnam, the decree means explicit changes to consent capture, data-subject rights handling, cross-border transfer controls, and breach notification.
FSC supports the requirements. The configuration is the implementation team's responsibility.
What Decree 13/2023 actually requires
The decree defines personal data broadly (any information relating to an identifiable individual) and creates 11 explicit rights for data subjects, including the right to know, the right to consent, the right to delete, the right to restrict, the right to provide, the right to object, the right to complain, the right to claim damages, and the right to self-protection.
Beyond data-subject rights, the decree creates specific obligations on data controllers (the banks) and data processors (any third party that handles personal data on the bank's behalf):
- Lawful basis for every processing activity.
- Explicit consent for sensitive data and for direct marketing.
- A formal cross-border data transfer impact assessment for any transfer of personal data outside Vietnam.
- Breach notification to the regulator (Ministry of Public Security, Department A05) within 72 hours.
- Designation of a Data Protection Officer for organisations of certain sizes and types.
For a bank running FSC, several of these obligations translate into explicit platform configuration.
Consent capture
Consent is the heart of the decree. The bank must capture explicit, informed, granular, and revocable consent for each purpose for which it processes personal data.
The FSC implementation that supports consent properly does three things:
Consent records. A custom object (or the standard Salesforce Individual object) captures each consent event. Fields include the purpose, the timestamp, the channel of capture, the version of the privacy notice the customer saw, and the consent status (granted, withdrawn).
Purpose-specific flags. The Person Account carries a set of consent flags, one per purpose. Marketing Consent. Profiling Consent. Cross-border Transfer Consent. Third-party Sharing Consent. Each flag references a Consent record for traceability.
Workflow integration. Every downstream system that uses personal data checks the appropriate consent flag before processing. Marketing campaigns filter on Marketing Consent. Behavioural-profiling features filter on Profiling Consent. Cross-border data exports filter on Cross-border Transfer Consent.
The flags are operational. They drive the actual processing decisions, not just the audit log. A Person Account without the relevant consent must not appear in the marketing campaign list, the profiling model training set, or the cross-border export feed.
Sensitive personal data
Decree 13 defines sensitive personal data as a specific category requiring stricter protection. Banks regularly handle sensitive data: religious beliefs (from KYC declarations), health information (from insurance applications), trade union membership, criminal history, and others.
The FSC configuration for sensitive data:
Field-level security. Sensitive fields get field-level security that limits visibility to a small set of roles. The visibility configuration goes through Permission Sets, not Profiles, to make exceptions traceable.
Audit logging. Sensitive fields enable field-history tracking and field-audit logging. Every read of a sensitive field gets logged for the audit trail.
Encryption at rest. Sensitive fields use Salesforce Shield Platform Encryption, which encrypts the data at the database level. The encryption keys are bank-controlled.
Explicit consent. Sensitive data processing requires explicit, separate consent from the customer. The consent record references the specific data categories rather than a blanket "I agree to terms".
Cross-border transfer
Decree 13 requires a formal Cross-Border Data Transfer Impact Assessment (TIA) for any transfer of personal data outside Vietnam. The TIA must be submitted to the Ministry of Public Security and approved before transfer begins.
For a bank running FSC on Salesforce's global infrastructure, this matters. Salesforce data centres are not in Vietnam. The bank's FSC data lives outside the country. Every operation on the data is technically a cross-border transfer.
Two practical approaches:
Salesforce Hyperforce in Singapore. Salesforce's Hyperforce deployment in Singapore provides regional data residency. Banks can host their FSC org in Singapore, which is geographically closer and may simplify the TIA depending on regulator interpretation.
Data localisation for the most sensitive fields. A subset of the most sensitive data stays in a Vietnam-hosted external system, with FSC holding only references rather than the raw data. The cross-border exposure shrinks; the workflow gets more complex.
The TIA itself is a legal document, not a Salesforce configuration. The platform-side support is documentation: data flow diagrams, encryption inventories, access-control summaries. The legal team builds the TIA from this documentation.
Data-subject rights handling
The 11 rights in the decree need operational responses. The four that produce the most platform work:
Right to know. The customer can request a copy of all personal data the bank holds about them. The FSC implementation needs an export workflow that gathers the customer's data across all related objects (Person Account, Financial Accounts, Activities, Life Events, KYC documents) into a structured deliverable.
Right to delete. The customer can request deletion. For a bank, deletion is constrained by other regulatory retention requirements (AML records, transaction records). The workflow captures the deletion request, applies the legally-permitted deletion scope, and documents the records that cannot be deleted due to regulatory retention.
Right to restrict. The customer can request that the bank stop processing their data for specific purposes while keeping it on record. The consent-flag pattern handles this: setting the relevant consent flag to Withdrawn restricts processing without deleting the data.
Right to object. The customer can object to specific processing activities, particularly automated decision-making. The bank must respond by either ceasing the activity or documenting why it is exempt.
Each right needs a defined workflow, a defined SLA (the decree allows up to 72 hours for initial response), and a defined audit trail. An Action Plan template per right type is the operational pattern.
Breach notification
Decree 13 requires breach notification to the Ministry of Public Security within 72 hours of detection. The notification must include the nature of the breach, the scope of affected data subjects, the likely consequences, and the mitigation measures taken.
The FSC implementation supports breach notification through:
Audit logging on all access. When a breach is investigated, the audit log identifies which records were accessed by which users at which times. Without robust audit logging, the bank cannot scope the breach accurately.
Field-level encryption. Encrypted data is significantly less sensitive when exposed in a breach. Salesforce Shield encryption reduces the regulatory and reputational impact.
Access-control reviews. Regular reviews of who has access to what, with prompt revocation when employees leave or change roles. The fewer over-permissioned users, the smaller the breach surface.
The 72-hour clock starts at detection. Banks need a defined incident-response process that can produce the regulatory submission within the window. The process is not a Salesforce feature; the platform supports the underlying data needs.
Data Protection Officer
The decree requires certain organisations to designate a Data Protection Officer (DPO). Banks generally fall into this category. The DPO has formal responsibilities including monitoring compliance, advising on impact assessments, and serving as the regulator's contact point.
The DPO does not run the FSC implementation, but the FSC implementation supports the DPO's work:
Dashboards. Standard FSC dashboards showing consent rates, data-subject request volumes, audit-log anomalies, and breach-incident counts.
Reporting access. The DPO gets a Permission Set that grants read access to compliance-relevant objects and fields, with CDS rules constraining the access to the DPO's specific Purpose.
Investigation tooling. The DPO can run queries against the audit logs and the compliance records. The investigation surface lives inside FSC rather than in separate systems.
The compliance-first design pattern
For FSC implementations rolling out in Vietnam, the design pattern that works:
- Map every customer-data flow against Decree 13 obligations before building the data model.
- Build the consent capture as the first deliverable, before any marketing or profiling features.
- Configure field-level security and encryption for sensitive data as part of the initial data-model deployment.
- Build the data-subject-rights workflows alongside the core operational workflows, not as an afterthought.
- Configure audit logging on every personal-data field, accepting the storage cost.
Each of these decisions costs effort at implementation. Each saves substantially more effort when the first data-subject request lands or the first regulator query arrives.
Building an FSC implementation that needs to comply with PDPA Vietnam? Sapota's Salesforce team, certified on Financial Services Cloud Accredited Professional (AP-208), runs PDPA-aware data architecture, consent capture, and rights-handling workflows on Vietnam-jurisdiction FSC engagements. Get in touch ->
See our Salesforce service page for the team.
