Saltar al contenido

Artículos

¿Quién puede ver los datos de salud de sus clientes en Salesforce? Permisos, PHI y PII explicados

Por Alex Gomez, Fundador, Troppus Group · 15 de septiembre de 2026 · 6 min de lectura

En la mayoría de las orgs de Salesforce, unos pocos permisos deciden quién puede ver la información de salud de todos los clientes. Configuraciones como View All Data, Modify All Data y Export Reports se saltan las reglas de uso compartido que su equipo configuró con tanto cuidado. Si las personas equivocadas las tienen, un administrador de casos, un voluntario o una integración pueden ver, cambiar o descargar registros que nunca necesitan.

Encontramos esto en casi todas las revisiones de acceso que hacemos para organizaciones de salud y servicios humanos. Aquí le explicamos qué hacen estos permisos, por qué importan para los datos de pacientes y cómo revisar su propia org.

PHI, PII y por qué importa el "mínimo necesario"

PII (información de identificación personal) es todo lo que identifica a una persona: nombre, dirección, fecha de nacimiento, teléfono, número de Seguro Social. PHI (información de salud protegida) es información de salud vinculada a una persona, en poder de un proveedor de salud, un plan de salud o uno de sus socios comerciales. Los diagnósticos, las visitas al hospital, los números de identificación de Medi-Cal o Medicaid y los planes de atención son todos PHI.

Muchas organizaciones comunitarias manejan PHI, en especial los proveedores de Administración Mejorada de Cuidados (ECM) y de Apoyos Comunitarios de CalAIM, y cualquiera que reciba datos de hospitales o planes de salud. El estándar de mínimo necesario de HIPAA establece que cada persona solo debe poder ver la información de salud que su trabajo requiere. En Salesforce, los permisos son la forma de cumplir ese estándar, o de incumplirlo sin darse cuenta.

Cómo decide Salesforce lo que puede ver un usuario

Salesforce revisa tres cosas, en orden, cada vez que alguien abre un registro. Unos cuantos permisos poderosos se saltan los dos primeros controles por completo.

View All Data / Modify All Data: omiten los controles 1 y 2 en todos los objetos Usuario 1. Acceso al objeto ¿Pueden abrir Contactos o Planes de Atención? 2. Acceso al registro ¿Qué clientes? Valores predeterminados, roles y reglas de uso compartido 3. Acceso al campo ¿Qué campos? Diagnóstico, SSN, ID de Medicaid
Su configuración de uso compartido vive en los controles 1 y 2. Un usuario con View All Data o Modify All Data llega a todos los registros sin pasar por ellos. La seguridad a nivel de campo sigue aplicando, por eso es importante para sus campos más sensibles.

Los permisos que más importan para los datos de clientes

Permiso Lo que le permite hacer a alguien Quién debería tenerlo
View All Data Leer todos los registros de todos los objetos, sin importar el uso compartido Solo sus administradores de Salesforce, idealmente una o dos personas
Modify All Data Leer, editar, eliminar y transferir todos los registros Solo sus administradores de Salesforce
View All / Modify All en un objeto Todos los registros de un objeto, como Contactos o Planes de Atención Un supervisor que de verdad supervisa a todos los clientes, nunca por defecto
Export Reports Descargar a una hoja de cálculo cualquier informe que pueda ejecutar Personas que necesitan exportaciones para su trabajo, no todos los usuarios
API Enabled Conectar herramientas como Data Loader u otras aplicaciones que extraen datos en bloque Usuarios de integración y administradores, mediante un conjunto de permisos
Manage Users Crear usuarios y asignar permisos, incluso a sí mismos Solo sus administradores de Salesforce
Customize Application / Author Apex Cambiar la configuración de seguridad o escribir código que puede ignorar el uso compartido Administradores y desarrolladores, con revisión antes de que los cambios lleguen a producción

Una prueba útil: si mañana le robaran el inicio de sesión a esta persona, ¿cuántos registros de clientes podría descargar alguien? Para un administrador de casos, la respuesta debería ser su propia carga de casos.

Cinco lugares donde se filtran los datos de pacientes sin que nadie lo note

  • Perfiles que otorgan demasiado. Un solo perfil amplio compartido por todos es la causa más común. Salesforce recomienda mantener los perfiles al mínimo y agregar acceso con conjuntos de permisos y grupos de conjuntos de permisos, de modo que cada rol reciba solo lo que necesita.
  • Integraciones y aplicaciones conectadas. En agosto de 2025, atacantes usaron tokens de inicio de sesión robados de una aplicación de chat de terceros, Salesloft Drift, para exportar datos de las orgs de Salesforce de muchas empresas. Cada integración debe tener su propio usuario, con solo los objetos que necesita, alcances de conexión limitados y, cuando sea posible, restricciones de IP.
  • Sandboxes con datos reales. Un sandbox de copia completa contiene registros reales de clientes, y los contratistas suelen tener más acceso ahí. Enmascare o elimine la PHI antes de que alguien haga pruebas en él.
  • Personas que ya se fueron. Congele o desactive a un usuario el día que se va. Los inicios de sesión compartidos ocultan quién hizo qué, así que dé a cada persona su propia cuenta.
  • Portales y sitios públicos. Si tiene un sitio de Experience Cloud o un formulario público, revise lo que puede ver el usuario invitado. No debería ser nada más allá de lo que la página necesita.

Cómo revisar su org este mes

  1. Haga una lista de todos los que tienen los permisos críticos de arriba. En Setup, revise cada perfil y conjunto de permisos, o pídanos el informe que usamos nosotros.
  2. Revise sus valores predeterminados. Los objetos de clientes como Contactos, Casos y planes de atención deben estar en Privado, para que el acceso se agregue a propósito.
  3. Bloquee los campos sensibles. Use la seguridad a nivel de campo para ocultar diagnósticos, números de Seguro Social e identificaciones de Medicaid a los roles que no los necesitan.
  4. Revise las exportaciones y el acceso por API. Quite API Enabled de los perfiles y otórguelo solo mediante un conjunto de permisos.
  5. Revise las aplicaciones conectadas. Elimine las que nadie usa y reduzca a lo que pueden alcanzar las demás.
  6. Confirme la autenticación multifactor para todos, contratistas incluidos.
  7. Ejecute Salesforce Health Check (Setup → Health Check) y corrija los elementos de alto riesgo.
  8. Repita cada trimestre, y siempre que alguien cambie de rol.

Algo más que debe saber: Salesforce firmará un Acuerdo de Socio Comercial (BAA) para los servicios que cubre, pero el BAA no configura su org. Quién puede ver qué sigue siendo responsabilidad suya.

¿No está seguro de quién puede ver los datos de sus clientes?

Revisaremos con usted el acceso a su Salesforce y le mostraremos exactamente quién puede ver, cambiar o exportar registros de clientes, y qué corregir primero. Toma 30 minutos, no cuesta nada, y usted se lleva sus tres correcciones principales. Reserve una revisión de salud gratuita.

¿Quiere una respuesta clara para su organización?

30 minutos · Sin costo · Se lleva sus 3 mejoras principales.

Reserve una revisión gratuita