The riskiest sentence in a Salesforce contract review in Korea is “the org will be used in Korea, so we only need to check the region.” Storage location has to be checked, but it is a starting point. A cross-border transfer decision under Korea’s Personal Information Protection Act (PIPA) asks which business process sends which personal data to which recipient, and who approves and changes that route. This note is a checklist to prepare with counsel and the privacy officer. It is not legal advice.
The region is a starting point
The English text of the Act and the Personal Information Protection Commission’s notice on the amended Act show that the transfer requirements do not reduce to consent alone, and that the amendment added a legal basis for orders to suspend a transfer.
Where the instance runs matters, but it does not prove that storage, processing, support, logs and external integrations all stay in the same country. Salesforce itself sends customers to per-service documents in its Trust and Compliance Documentation. A region line in a sales proposal is no evidence of an org’s processing route.
The unit of review is the business flow. A service agent working a Case, a portal creating a Contact, an external system reading records through the API: three flows, three reviews. So write the data flow list before the feature list. For each flow, record the source system, the receiving system, the identifying fields, the purpose, whether data is stored, when it is sent, and the operational owner. Without that list, the DPA, the security annex, the privacy notice and the setup screens each end up describing something different.
Seven items to close before the contract
- Business purpose. “Running the CRM” is not a purpose. Split it into units of work: classifying enquiries, renewal reminders, partner portal login. A broad purpose leaves no basis for cutting fields.
- Data items. Look at fields, not object names. Name, contact details, customer number, case notes, attachments and free-text comments carry different risks. Put sandbox copies and error logs on the list too.
- Recipients and roles. Salesforce, its affiliates, sub-processors, the systems integrator and services the client contracts directly may play different roles. The contract should say who decides purpose and means, who processes on instruction, and who notifies incidents and changes.
- The actual route. Beyond storage, check API requests, batch files, integration middleware, retry stores for failed messages and material attached to support tickets. Personal data sometimes stays longest outside the main database.
- Legal basis and notice. Which route under Article 28-8 applies depends on the contractual relationship, the recipient, the transfer method, the purpose and the facts. Counsel decides. The technical team hands over the items transferred, the country or region, the timing, the recipient and the purpose, in a form that can be verified.
- Retention and deletion. Conversation transcripts, audit logs, integration error queues, backups and sandbox copies may follow their own retention rules. The responsibility matrix should say what is deleted at contract end, how, and which record proves it.
- Change control. A new integration user, Connected App, Flow, field or external action can change a data flow. Add a personal-data and cross-border impact box to the change request, and a rule that sends affected changes to legal and security review.
The seventh item matters more than a yearly document refresh, because the real route changes first, through deployments and configuration.
When Agentforce and generative AI features are switched on
Turning on Agentforce or Prompt Builder adds lines to the flow list. A country investment announcement or a Hyperforce brochure does not prove where a given org’s inference, logs or Data 360 data are processed. Apply the same seven items at three points.
- Data 360 ingestion and Identity Resolution. Check the fields ingested, the source location, the tenant location, the matching keys, retention and access. Keep matching keys to the minimum identifiers, and have any sensitive identifier approved separately, with its necessity and safeguards.
- Prompt Builder inputs. Check which fields a template inserts, whether masking actually applies, which model provider and sub-processors are involved, and how long inputs, outputs and audit logs are kept. Switching on Trust Layer features does not complete the PIPA review.
- External calls from actions. When MuleSoft, Apex, Flow or External Services call an outside system, processors and regions outside the Salesforce contract can join the flow. Put the input and output fields, the authenticating identity, error logs and retry stores on the diagram.
Tokenisation and pseudonymisation reduce exposure. Depending on re-linking risk and key management, the data may still be personal data, so the cross-border review does not go away. Template controls have their own note: Prompt Builder governance.
Contract and configuration as one body of evidence
A list of clauses is not enough. For each flow, link the contractual processor and purpose, the setup or integration evidence, the date the actual calls were checked, the owner and the condition for the next review. One page listing the approved processes, allowed fields, forbidden fields, recipients, retention periods and change approver lets the CIO and the privacy officer see what each one approves in the internal sign-off.
In 2025 the Personal Information Protection Commission sanctioned Kakao Pay, Apple and others over cross-border transfer violations, noting that data subjects could not know about the outsourcing and the transfer (PIPC announcement). It says nothing about a Salesforce contract, but it shows the risk in “the processor is named in the contract, so operations need not check.”
A systems integrator building the solution does not take over the client’s responsibility. The integrator produces the flow diagram and configuration evidence, the client sets the purpose and approval criteria, and counsel and the privacy team rule on the legal basis and notice. If those outputs do not reference the same flow ID, the review stays disconnected, RACI or not.
When a change reopens the review
A review filed as a project close-out document goes stale at the next change. Not every change needs a full legal review, but the operational owner must be able to tell which changes alter fields, recipients, purpose, retention or region.
Adding an email address to an existing integration looks like a mapping tweak. If the approved flow was designed to send only the customer number, the personal data processed and the scope of notice have changed. A release that only changes on-screen labels, with the same route and purpose, may not need the same review. The test is whether the processing facts changed, whatever the size of the feature.