Skip to main content

GDPR mapping

GDPR applies to any Salesforce deployment that processes the personal data of EU residents, regardless of where the deployment is hosted. For most Salesforce buyers that means: any consumer-facing Experience Cloud site, any sales / marketing org that captures EU leads, any Health Cloud or Financial Services Cloud deployment with EU customers, any ISV-managed package distributed to EU partners.

The GDPR articles most relevant to a technical scanner are Article 5 (principles), Article 25 (data protection by design), Article 30 (Records of Processing Activities), Article 32 (Security of Processing), Article 33 (Breach notification preparation), and Article 35 (Data Protection Impact Assessment).

This page maps those articles onto the Vulkro detectors that produce evidence for them.

For the non-Salesforce half of a GDPR audit (web app, API, mobile, cookies, consent management), see the general-scanner GDPR page.

Run it​

vulkro-sf scan ./force-app --compliance gdpr
vulkro-sf scan ./force-app --compliance-pack gdpr -o gdpr-readiness.html

Articles covered​

ArticleTitleVulkro detector(s) that feed it
Art. 5(1)(c)Data minimisationpii-map (sensitive field inventory, what gets returned in API queries)
Art. 5(1)(f)Integrity and confidentialitysecurity-settings (requireHttps, password policy), profiles-permsets (over-privilege)
Art. 25Data protection by design and by defaultdetectors/apex (CRUD/FLS enforcement on read and write paths)
Art. 30Records of Processing Activities (RoPA)pii-map (sensitive SObject inventory), connected-apps (third-party data flow recipients)
Art. 32Security of ProcessingThe full five-pillar scan
Art. 33Breach notification preparationantipatterns AP-014 (test coverage gaps suggest unaudited code paths)
Art. 35Data Protection Impact AssessmentAppExchange Security Review report (starting input for the DPIA technical-risk section)

Per-article detail​

Art. 5(1)(c) Data minimisation​

The principle: personal data shall be adequate, relevant, and limited to what is necessary in relation to the purposes for which they are processed.

For Salesforce, the practical question is "which fields are returned in your Apex REST, @AuraEnabled, and LWC @wire results, and is the caller authorized to see each of them?" The PII map detector inventories sensitive fields per sObject. The Apex detector flags returns that include sensitive fields without an explicit CRUD/FLS check on the calling user. Together those produce the evidence trail for data minimisation: a sensitive field that surfaces in an API response when the caller does not need it is a minimisation breach.

Art. 5(1)(f) Integrity and confidentiality​

The principle: personal data shall be processed in a manner that ensures appropriate security, including protection against unauthorised or unlawful processing, accidental loss, destruction, or damage.

Vulkro's evidence:

  • requireHttps enforced on every login route and Site / Experience Cloud surface.
  • Password policy at or above the documented baseline.
  • Profile and permission set over-privilege findings (least privilege is the supporting control).
  • Crypto misuse in Apex (deprecated algorithms, weak modes).

Art. 25 Data protection by design and by default​

The article: the controller shall implement appropriate technical and organisational measures designed to implement data-protection principles in an effective manner and to integrate the necessary safeguards into the processing.

The Salesforce-shaped read is: every Apex method that reads or writes a sObject should enforce CRUD and field-level security on the calling user. WITH SECURITY_ENFORCED on the SOQL, Schema.sObjectType.X.isAccessible() on the precondition, or Security.stripInaccessible on the result. The Apex detector emits a finding for every read or write path that lacks enforcement.

Art. 30 Records of Processing Activities (RoPA)​

Article 30(1) requires the controller to maintain a record of processing activities including the categories of personal data, the categories of recipients, and (where applicable) transfers to third countries.

Vulkro produces two of the inputs the RoPA needs:

  • Categories of personal data: the PII map output. Every sensitive sObject and the fields it contains, classified by data category (contact, financial, health, government ID).
  • Categories of recipients: the Connected Apps detector lists every third-party OAuth integration installed in the org with the data scopes each one was granted. The output of the org-status connector pull is the recipients list for the RoPA.

These are inputs, not the RoPA itself. The RoPA is a written register the controller maintains.

Art. 32 Security of Processing​

The article: taking into account the state of the art, the costs of implementation, and the nature, scope, context, and purposes of processing as well as the risk, the controller shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk.

This is the full five-pillar scan. Apex, Metadata, Profiles / PermSets, Connected Apps, and PII Map. The SARIF output is the "appropriate technical measures" evidence row. The compliance-pack HTML report is the auditor-facing summary.

Art. 33 Breach notification preparation​

Article 33 requires breach notification within 72 hours. The technical prerequisite is that you can tell when a breach happened, what was affected, and the scope. That requires audit-trail coverage that matches the code surface.

Vulkro's antipatterns detector AP-014 flags Apex classes with test coverage gaps. Untested code paths are unaudited code paths: a path that no test exercises is also a path no detector exercises. The finding is a signal that the breach-investigation reproducibility will be poor on that code surface.

This is not the only Art. 33 input. The Salesforce-side audit trail (EventLogFile, Field Audit Trail, Login History) is also required. See HIPAA § 164.312(b) for the audit-controls detector coverage; the same detectors feed Art. 33.

Art. 35 Data Protection Impact Assessment​

Article 35 requires a DPIA for processing that is likely to result in a high risk to the rights and freedoms of natural persons. The DPIA must cover the necessity and proportionality of the processing, the risks to data subjects, and the measures envisaged to address the risks.

The AppExchange Security Review readiness report is a starting input for the DPIA's technical-risk section. It groups findings by checklist section and produces a PASS / FAIL verdict per risk category. It does not replace the DPIA. It produces structured input the DPIA author can paste into the technical-measures section.

Cross-border transfer​

Chapter V of GDPR governs transfers of personal data to third countries and international organisations. Article 44 sets the general principle; Articles 45 through 49 cover adequacy decisions, Standard Contractual Clauses, Binding Corporate Rules, and derogations.

For a Salesforce deployment the cross-border-transfer surface is the Connected Apps list and the Named Credentials list. Every Connected App installed in the org represents a data flow to a third-party recipient. Every Named Credential represents an outbound callout to a URL.

The Connected Apps detector emits one row per Connected App with:

  • Recipient name and publisher.
  • OAuth scope grants.
  • Callback URL host.
  • Membership in the documented breach-class set (Drift / Gainsight posture).

That is the data flow recipients list the cross-border transfer record needs as input. The legal classification (which country, which transfer mechanism applies, whether the recipient is a processor or controller) is yours to assess.

What's NOT covered​

GDPR is built on principles, rights, and obligations. A scanner produces evidence for the technical-and-organisational-measures articles (5, 25, 32). It does not produce evidence for:

  • Article 6 Lawful basis: consent, contract, legal obligation, vital interests, public interest, legitimate interests. The lawful basis is a legal classification the controller documents.
  • Article 7 Conditions for consent: consent records, consent withdrawal flows, consent capture UX.
  • Articles 12 through 22 Data subject rights: access, rectification, erasure, restriction, portability, objection, automated decision-making. These need a working DSAR workflow and a written policy.
  • Articles 13 through 14 Notice obligations: privacy notices, layered notices, just-in-time notices.
  • Article 28 Processor contracts: the DPA / processor agreement with every sub-processor.
  • Articles 37 through 39 DPO obligations: the Data Protection Officer designation, contact, and reporting line.
  • Retention: GDPR requires personal data be kept no longer than necessary. Retention is a policy decision and an org-configuration decision (org-level data retention settings, sObject-level archival).

A scanner produces evidence for the technical surface. The controller still owns the lawful basis, the contracts, the rights workflow, the retention policy, and the DPO designation.