En una frase. Salesforce puede explotarse conforme al RGPD, pero es la plataforma donde más depende de usted: el modelo de datos lo diseña el cliente, y con él decide qué campos existen, quién los ve, cuánto duran y si la inteligencia artificial de la plataforma los toca.
Ningún producto «cumple el RGPD»; cumple —o no— el tratamiento que usted realiza con él. En Salesforce esa frase deja de ser una cautela retórica y se convierte en la descripción exacta del reparto de responsabilidades. Salesforce no le entrega un CRM terminado: le entrega objetos, campos, perfiles, automatizaciones y una API. El responsable del tratamiento construye el modelo de datos, y por tanto es el responsable quien crea el campo de texto libre donde un comercial acabará anotando el estado de salud de un contacto. Todos los datos sobre el proveedor recogidos aquí corresponden a fecha de julio de 2026 y deben reverificarse en la documentación legal vigente de Salesforce antes de usarlos en un expediente, anotando la fecha de comprobación.
Puntos clave
- Compruebe qué entidad figura en su pedido: para clientes del EEE es habitual contratar con una entidad irlandesa del grupo, pero eso condiciona el contrato aplicable y la cadena de transferencias, así que se verifica, no se supone.
- Salesforce publica un Data Processing Addendum y una lista de subencargados en su documentación legal; el addendum se incorpora normalmente a las condiciones del pedido.
- Salesforce afirma públicamente disponer de normas corporativas vinculantes aprobadas para encargados. Trátelo como declaración del proveedor a fecha de julio de 2026, verifíquela en su documentación legal vigente y anote la fecha en que lo comprobó.
- Las regiones de infraestructura europea (Hyperforce) existen, pero su disponibilidad depende del producto y de la organización concreta: pida confirmación por escrito.
- Salesforce es propietaria de Slack: si su organización lo utiliza, es un tratamiento distinto que exige su propia entrada en el registro.
Qué datos personales acaban dentro de Salesforce
La respuesta honesta es: los que usted haya decidido meter. En una implantación de ventas típica encontrará, en los objetos estándar, nombre y apellidos, correo y teléfono profesionales, cargo, empresa, idioma y país, más el historial completo de interacción: llamadas registradas, correos sincronizados desde el buzón del comercial, reuniones, tareas, notas y adjuntos. A eso se suman los campos personalizados que crea cada departamento, y ahí es donde aparecen las sorpresas de auditoría: campos de «observaciones» sin control, listas desplegables con información sobre la situación personal del interesado, adjuntos con documentación de identidad escaneada.
Cuando la implantación va más allá de ventas, el perímetro se amplía: casos de soporte con conversaciones completas, portales de clientes con datos de usuarios finales, comunidades, e incluso datos de empleados si se usa la plataforma para procesos internos. Conviene revisar campo a campo si alguno contiene categorías especiales de datos, porque en Salesforce el diseño del esquema es una decisión del responsable y no puede delegarse en el proveedor. La regla operativa: si nadie sabe explicar para qué existe un campo personalizado, ese campo infringe la minimización de datos y debe eliminarse.
Entidad contratante y contrato de encargado del tratamiento
Antes de analizar cláusulas, mire su pedido. Salesforce, Inc. es la matriz estadounidense, pero para clientes del Espacio Económico Europeo la entidad contratante suele ser una sociedad irlandesa del grupo. Compruebe qué entidad figura en su pedido y archive esa página: determina qué contrato le aplica, qué ley rige y cómo se articula la cadena de transferencias. Es la primera pregunta que hará cualquier inspección y la que con más frecuencia nadie sabe responder.
Salesforce publica un Data Processing Addendum en su documentación legal, incorporado a las condiciones del pedido. Su contenido responde a las exigencias del art. 28.3 RGPD: tratamiento conforme a instrucciones documentadas, deber de confidencialidad, medidas de seguridad, condiciones para recurrir a subencargados, asistencia en el ejercicio de derechos y en las evaluaciones de impacto, supresión o devolución al término del contrato y derechos de auditoría limitados a informes de terceros y cuestionarios. Descargue la versión vigente en PDF, archívela con la fecha de obtención y contraste su clausulado con el mínimo legal usando nuestro modelo de contrato de encargado del tratamiento y la guía del artículo 28 del RGPD.
Una advertencia sobre papeles: Salesforce actúa como encargado respecto de los datos que usted introduce, pero puede actuar como responsable respecto de datos de administración de la cuenta y de uso del servicio. Es una distinción habitual en SaaS y conviene tenerla clara antes de responder a un ejercicio de derechos; el criterio para separar ambas figuras está en responsable frente a encargado del tratamiento.
Alojamiento y transferencias internacionales (a fecha de julio de 2026)
Salesforce ofrece infraestructura en regiones europeas bajo su arquitectura Hyperforce. La disponibilidad no es uniforme: varía por producto y por organización, y una migración de una instancia existente es un proyecto, no un interruptor. Pida confirmación por escrito de en qué región reside cada una de sus organizaciones y de cada producto que utiliza, y archive la respuesta con la fecha.
Sobre la garantía de transferencia, hay dos vías que conviene distinguir. El addendum incorpora las cláusulas contractuales tipo —confirme módulo y versión aplicables a su contrato—. Y Salesforce afirma públicamente contar con normas corporativas vinculantes aprobadas en su condición de encargado, un mecanismo previsto en el art. 46.2.b) RGPD que opera junto a las cláusulas, no en lugar de la documentación. Presente ese punto en su expediente por lo que es: una declaración del proveedor a fecha de julio de 2026, que usted ha verificado en su documentación legal vigente en una fecha concreta que consta por escrito. No copie la afirmación sin comprobarla; las aprobaciones tienen ámbito subjetivo y objetivo, y una norma corporativa vinculante que no cubra a la entidad con la que usted contrata no le sirve de nada.
Lo que debe quedar en su documentación es un cuadro sencillo: entidad contratante, regiones de alojamiento por producto, garantía invocada, fecha de verificación y una evaluación de impacto de la transferencia que valore el acceso desde fuera del EEE. La metodología completa está en nuestra guía de transferencias internacionales de datos.
Subencargados y superficie de integración
Salesforce publica su lista de subencargados y notifica los cambios. La particularidad de esta plataforma no está en esa lista, sino en lo que se conecta a su alrededor: los paquetes instalados desde el marketplace, los usuarios de integración creados para middleware, los conectores hacia el ERP y las herramientas de enriquecimiento de datos. Ninguno de ellos aparece en la lista del proveedor porque no son subencargados de Salesforce: son encargados suyos, y necesitan su propio contrato y su propia entrada de inventario. Un CRM con veinte paquetes instalados y ningún inventario de destinatarios es un hallazgo garantizado.
Designe internamente quién recibe y evalúa las notificaciones de cambio de subencargado, con qué plazo debe reaccionar y qué desencadena una nueva evaluación de transferencias. Si además usa otras plataformas de marketing o CRM, mantenga los expedientes comparables: los escenarios de HubSpot y de Microsoft 365 plantean preguntas distintas sobre alojamiento y telemetría.
Seguridad, certificaciones y monitorización de usuarios
Salesforce mantiene un portal de confianza con información sobre disponibilidad y seguridad y pone informes de auditoría a disposición de sus clientes. Trate esas certificaciones como declaraciones del proveedor: solicite el informe vigente, revise alcance y periodo cubierto, compruebe que incluye los productos que usted usa y archívelo junto a su evaluación de garantías del art. 28.1 RGPD. Lo que le corresponde a usted bajo el art. 32.1 RGPD es la configuración: autenticación multifactor obligatoria, restricciones de acceso por IP o dispositivo, caducidad de sesiones y revisión periódica de perfiles.
Aquí aparece un ángulo específicamente español. Las funciones de auditoría de la plataforma —registro de eventos, seguimiento de accesos y descargas, monitorización de uso— generan datos sobre el comportamiento de sus propios empleados. Activarlas es razonable desde la seguridad, pero convierte esos registros en un tratamiento de control laboral sujeto al art. 87 LOPDGDD, que exige información previa y clara a la plantilla y, en su caso, a la representación de los trabajadores, y a los criterios de proporcionalidad que ha venido aplicando la jurisprudencia. Informe antes de activar, no después de necesitar el registro.
Checklist de configuración de Salesforce
- Congele el esquema. Establezca un procedimiento de aprobación para crear campos personalizados: quién lo autoriza, con qué finalidad y con qué plazo de conservación asociado. Sin esto, el modelo de datos crece sin control.
- Audite los campos de texto libre existentes y elimine o restrinja los que recojan información no prevista.
- Revise el modelo de compartición. Valores predeterminados de la organización, reglas de compartición y jerarquía de funciones determinan quién ve qué; el ajuste inicial de muchos proyectos es deliberadamente abierto para acelerar la puesta en marcha.
- Aplique seguridad a nivel de campo. Restringir por objeto no basta: los datos sensibles se protegen campo a campo, por perfil y conjunto de permisos.
- Controle los entornos de pruebas. Cada actualización de un sandbox copia datos reales; exija enmascaramiento o generación de datos sintéticos antes de dar acceso a integradores externos.
- Decida expresamente sobre las funciones de inteligencia artificial. Manténgalas desactivadas hasta que haya documentado qué datos alimentan el modelo, qué condiciones contractuales específicas las regulan y si su salida influye en decisiones sobre personas.
- Reduzca los permisos de los usuarios de integración al mínimo funcional: son cuentas con acceso masivo y suelen crearse con permisos de administrador «temporalmente».
- Inventaríe los paquetes instalados desde el marketplace y desinstale los que no estén en uso; cada uno accede a datos.
- Limite la exportación masiva. Restrinja los permisos de exportación de informes y de acceso a la API a las personas que realmente los necesitan, y registre su uso.
- Defina la política de borrado. La plataforma no purga por su cuenta; establezca criterios de eliminación de registros, vacíe la papelera y decida qué ocurre con los datos archivados: el art. 5.1.e) RGPD exige un plazo, no una intención.
- Separe los productos añadidos. Marketing, portales de clientes o Slack tienen condiciones y tratamientos propios; no los cubra con la documentación del CRM.
- Cierre el ciclo de altas y bajas de usuarios internos con revisión trimestral de cuentas activas.
Qué inscribir en el registro de actividades de tratamiento
No inscriba «Salesforce». Inscriba los tratamientos que ejecuta en Salesforce, que en una implantación media son al menos tres: gestión de clientes y oportunidades comerciales, atención de incidencias de soporte y —si existe— gestión de usuarios de un portal o comunidad. Añada una cuarta entrada para la monitorización de accesos de empleados si ha activado el registro de eventos. Cada entrada necesita finalidad, base de legitimación, categorías de datos y de interesados, destinatarios —el proveedor, sus subencargados y los encargados suyos conectados por integración—, transferencias con la garantía aplicada, plazo de conservación y remisión a las medidas de seguridad. La estructura completa está en la guía del registro de actividades de tratamiento. Mantener esta correspondencia entre entradas, contratos y proveedores a mano deja de ser viable en cuanto hay varias plataformas conectadas; ahí es donde una herramienta de gestión aporta algo real, y las opciones están descritas en nuestro análisis de software para el registro de tratamientos —Legiscope es una de ellas y mantiene enlazados registro, contrato de encargo y lista de subencargados.
Cuándo hace falta una EIPD
Un CRM de ventas entre empresas no exige por sí solo una evaluación de impacto. Salesforce cambia esa ecuación por tres vías. Primera, la escala: implantaciones con cientos de miles de registros de personas físicas y decenas de integraciones superan con facilidad el umbral de tratamiento a gran escala del art. 35.3 RGPD. Segunda, la puntuación predictiva y las recomendaciones automáticas, que constituyen elaboración de perfiles con efectos sobre el trato que recibe cada persona. Tercera, la monitorización sistemática de empleados a través del registro de eventos. Contraste su caso con los criterios del art. 35.3 RGPD y con la lista de tratamientos que la AEPD considera de evaluación obligatoria; si la plataforma llega a decidir sin intervención humana, entra además el art. 22 RGPD.
FAQ
¿Salesforce cumple el RGPD?
Rechace la pregunta antes de contestarla: un producto no puede cumplir el RGPD porque el Reglamento obliga a organizaciones, no a programas informáticos. Salesforce aporta contrato de encargado, lista de subencargados, garantías de transferencia y controles de seguridad configurables. Con esas mismas piezas se puede montar una implantación impecable o una que exponga toda la base de clientes a cualquier usuario interno. La diferencia está en el esquema de datos, los permisos y la documentación que usted mantenga.
¿Con qué entidad de Salesforce firmo el contrato?
Compruebe qué entidad figura en su pedido. Para clientes del EEE es frecuente contratar con una entidad irlandesa del grupo, pero no lo dé por hecho: la entidad determina el contrato aplicable y la posición en la cadena de transferencias. Archive esa página del pedido junto al addendum de tratamiento de datos.
¿Las normas corporativas vinculantes de Salesforce me eximen de las cláusulas contractuales tipo?
No las trate como sustituto automático. Las normas corporativas vinculantes son un mecanismo de transferencia del art. 46.2.b) RGPD que convive con las cláusulas contractuales tipo incorporadas al addendum. Verifique en la documentación legal vigente del proveedor cuál se invoca para su contrato y su entidad, anote la fecha de comprobación y documente igualmente su evaluación de impacto de la transferencia.
¿Puedo activar Einstein y las funciones de IA sin más trámite?
No sin una decisión documentada. Antes de activarlas debe saber qué datos alimentan la función, qué condiciones contractuales específicas las regulan, si generan datos nuevos sobre el interesado y si su resultado condiciona decisiones. Si el resultado influye en cómo se trata a una persona, necesita base de legitimación propia, información al interesado y, con probabilidad, evaluación de impacto.
Conclusión
En Salesforce, el proveedor cubre bien su parte —contrato publicado, subencargados listados, garantías de transferencia, informes de auditoría disponibles— y precisamente por eso el riesgo se desplaza entero hacia el cliente. Los hallazgos que se encuentran en auditoría no son contractuales: son campos personalizados sin finalidad, permisos heredados de la puesta en marcha, sandboxes con datos reales y ninguna política de borrado. Verifique la entidad contratante y la región de alojamiento por escrito, documente la garantía de transferencia con fecha, revise el modelo de permisos y repita la comprobación anualmente.
Fuentes oficiales: Reglamento (UE) 2016/679 (RGPD), AEPD, Comité Europeo de Protección de Datos (CEPD) y Ley Orgánica 3/2018 (LOPDGDD).
Legiscope automates this for you
Stop doing compliance manually. Legiscope's AI handles ROPA creation, DPA audits, and gap analysis — in minutes, not weeks.
Start free trial