¿Qué es la segregación de funciones (SoD)? Definición

Un único empleado que puede crear un registro de proveedor y luego aprobar la factura de ese proveedor no necesita la ayuda de nadie más para procesar un pago indebido. No se requiere colusión y no hay que falsificar nada: un solo inicio de sesión con demasiado alcance es suficiente por sí mismo. La segregación de funciones (SoD) es el control que cierra esa brecha. Divide un proceso sensible en pasos que diferentes personas deben completar, de modo que ninguna persona pueda ejecutar una transacción de principio a fin sin supervisión.

El principio sustenta la mayoría de los marcos de control interno en finanzas, TI y operaciones de seguridad. Los auditores lo preguntan por su nombre. Los reguladores lo citan en cláusulas específicas. Y el costo de omitirlo sigue aumentando: el caso medio de fraude ocupacional costó 104.000 dólares en 2026, y el caso promedio se prolongó durante unos 12 meses antes de que alguien lo detectara, según el informe de la ACFE Occupational Fraud 2026: A Report to the Nations.

Puntos clave

La SoD divide la autorización, la custodia y el registro entre diferentes personas para que una sola cuenta no pueda completar un proceso sensible por sí sola.
Es distinta del privilegio mínimo y RBAC. El privilegio mínimo limita cuánto acceso tiene una persona, RBAC es el mecanismo, y la SoD es la regla de diseño que decide qué combinación de roles puede tener una sola cuenta.
El caso medio de fraude ocupacional costó 104.000 dólares en 2026 y se prolongó unos 12 meses antes de que alguien lo detectara (ACFE).
NIST AC-5, ISO 27001 Anexo A 5.3 y NIS2 Art. 21(2)(i) esperan controles de SoD documentados, aunque el peso legal varía según el sector.
Los equipos sin una plataforma dedicada de gobernanza y administración de identidades (IGA) o de gobernanza, riesgo y cumplimiento (GRC) pueden implementar la SoD mediante controles compensatorios: roles de administrador no eliminables, enrutamiento de aprobaciones, registro de auditoría y revisión periódica.

¿Qué es la segregación de funciones (SoD)?

La segregación de funciones (SoD) es un control interno que divide un proceso sensible en etapas — típicamente autorización, custodia o ejecución, y registro o conciliación — y asigna cada etapa a una persona diferente. Ningún individuo inicia y aprueba la misma transacción, ni maneja un activo y registra su propio movimiento. El objetivo es hacer que el fraude o el error requieran colusión en lugar de solo oportunidad.

La SoD no es lo mismo que un organigrama. Una línea de reporte muestra quién gestiona a quién, pero no dice nada sobre quién puede crear un proveedor, aprobar su pago y conciliar el libro mayor sin que una segunda persona revise la transacción. Dos personas pueden reportar al mismo gerente y aun así cumplir con la SoD, siempre que ninguna pueda completar el proceso completo por sí sola. El principio de los cuatro ojos, que requiere que al menos dos personas aprueben una acción sensible, es la expresión más simple de la idea.

Segregación de funciones vs. privilegio mínimo vs. RBAC

La SoD no es privilegio mínimo, y el privilegio mínimo no es RBAC. El privilegio mínimo limita cuánto acceso tiene una persona. La SoD limita si una persona puede completar un proceso sensible completo por sí sola, incluso dentro de su acceso permitido. RBAC (control de acceso basado en roles) es el mecanismo que generalmente aplica ambos, al vincular permisos a roles en lugar de individuos.

Las tres ideas fallan de manera diferente cuando se aplican por separado. El privilegio mínimo sin SoD todavía permite que una cuenta con alcance limitado cree y apruebe el mismo tipo de registro, porque limitado no significa aislado. RBAC sin SoD puede silenciosamente otorgar a una persona dos roles que nunca debían superponerse, como un empleado de cuentas por pagar cubriendo a un aprobador durante una semana de vacaciones. Las definiciones de roles parecen correctas, pero la combinación anula el control.

Nada de esto hace que RBAC sea innecesario. Es la herramienta que hace que la SoD sea aplicable a escala. Consulte cómo RBAC asigna acceso por rol para el modelo subyacente: en lugar de rastrear permisos individuales, un administrador define roles, y las reglas de SoD deciden qué roles puede tener una sola cuenta a la vez.

Principio	Qué controla	Falla sin él
Privilegio mínimo	Cuánto acceso tiene una cuenta	Las cuentas acumulan permisos de alto riesgo no utilizados con el tiempo
RBAC	Cómo el acceso se asigna a la función laboral	Los permisos se asignan de forma ad hoc, inconsistente, por persona
Segregación de funciones	Si una cuenta puede terminar un proceso sensible sola	Una sola cuenta comprometida o descuidada puede completar un fraude o causar daño sin que intervenga una segunda parte

Conflictos comunes de segregación de funciones (con ejemplos)

Un conflicto de segregación de funciones existe cuando una cuenta o una persona tiene dos roles que, combinados, le permiten completar un proceso sensible sin que intervenga una segunda parte. Los ejemplos más claros se encuentran en finanzas y adquisiciones, pero el mismo patrón de fallo aparece en pipelines de DevOps, sistemas de RRHH y bóvedas de credenciales.

Los requisitos formalizados de SoD se remontan a los escándalos contables de Enron y WorldCom a principios de la década de 2000, que condujeron directamente a la Ley Sarbanes-Oxley y su mandato de controles internos de la Sección 404. Esa historia todavía moldea cómo los auditores abordan el control hoy: la SoD existe porque la confianza informal deja de escalar una vez que una empresa supera cierto tamaño.

Cuando una persona puede tanto crear un proveedor como aprobar su pago, el fraude no requiere colusión en absoluto.

Dominio	Funciones en conflicto	Qué permite si se combinan
Finanzas	Crear un proveedor + aprobar su factura	Pagos a proveedores ficticios sin un segundo revisor
Adquisiciones	Solicitar una compra + aprobar la orden de compra	Gastos no autorizados que evitan los controles presupuestarios
TI / DevOps	Desplegar código + aprobar el despliegue	Código no revisado llega a producción, incluyendo puertas traseras
RRHH	Establecer el salario de un empleado + procesar la nómina	Cambios salariales no autorizados que nadie más verifica
Gestión de credenciales	Crear una bóveda + otorgarse sus propios derechos de administrador	Una cuenta que almacena secretos y controla quién puede verlos, sin supervisión independiente
Administración de TI	Aprovisionar cuentas de usuario + aprobar solicitudes de acceso	Cuentas creadas y aprobadas por la misma persona, evitando la revisión

Si una fila de esa tabla describe cómo funciona su bóveda hoy, esa brecha se puede solucionar. Pruebe Passwork gratis y vea cómo las políticas de bóveda la cierran.

Cómo construir una matriz de segregación de funciones

Una matriz de segregación de funciones mapea los roles contra las acciones que esos roles pueden realizar, para que los conflictos sean visibles antes de que causen un problema. Construir una requiere cinco pasos.

Identifique los procesos críticos. Comience con todo lo que mueve dinero, cambia accesos o toca producción: pagos a proveedores, cambios de nómina, despliegue de código, administración de credenciales y bóvedas.
Liste todos los roles involucrados. Incluya roles por título de trabajo (empleado de cuentas por pagar, ingeniero DevOps) y roles de sistema (administrador de bóveda, aprobador) lado a lado.
Mapee los roles contra las acciones. Construya una cuadrícula con roles en un eje y acciones — como crear, aprobar, ejecutar y registrar — en el otro. Marque cada acción que cada rol puede realizar actualmente.
Señale las superposiciones. Cualquier rol que pueda tanto iniciar como aprobar el mismo proceso, o tanto ejecutar como registrarlo, es un conflicto.
Resuelva cada conflicto. Reasigne el rol, divida el proceso entre dos roles o, cuando la reasignación no sea práctica, documente un control compensatorio.

Un pequeño ejemplo práctico — tres roles contra tres acciones en un proceso de cuentas por pagar:

Rol	Crear proveedor	Aprobar pago	Conciliar libro mayor
Empleado de cuentas por pagar	Sí	No	No
Gerente financiero	No	Sí	No
Auditor	No	No	Sí

Ninguna fila puede marcar todas las columnas. Así es como debe funcionar la matriz.

Controles de SoD preventivos vs. detectivos (y controles compensatorios para equipos pequeños)

Los controles de SoD preventivos detienen una asignación conflictiva antes de que ocurra, generalmente bloqueando una combinación de roles en el propio sistema de acceso. Los controles detectivos capturan conflictos después del hecho, a través de registros de auditoría y revisión periódica de accesos. Los controles compensatorios sustituyen a cualquiera de los dos cuando un equipo es demasiado pequeño para separar completamente un proceso.

Los controles preventivos son los más fuertes, porque eliminan la oportunidad por completo. Un sistema de roles que se niega a permitir que una cuenta tenga tanto «aprobador» como «solicitante» para el mismo flujo de trabajo nunca permite que se forme el conflicto en primer lugar.

Los controles detectivos aceptan que alguna superposición es inevitable y la capturan en su lugar. Un registro de auditoría que documenta quién creó un registro, quién lo aprobó y quién accedió a él después permite a un revisor detectar un conflicto durante una certificación de acceso, incluso si el sistema permitió que ocurriera.

La mayoría de las guías de SoD asumen una plataforma dedicada de gobernanza y administración de identidades (IGA) o GRC ejecutando verificaciones continuas de conflictos. Los equipos de TI pequeños rara vez tienen ese presupuesto, y la mayoría de las guías omiten qué hacer en su lugar.

Cuatro controles compensatorios cubren la mayor parte de la brecha. Llámelo la línea base de SoD de cuatro controles:

Separar roles donde el tamaño del equipo lo permita
Enrutar todo lo que no se pueda separar a través de un segundo aprobador
Registrar cada acción privilegiada en un registro de auditoría exportable
Revisar accesos en un calendario fijo en lugar de nunca

Ninguno de los cuatro requiere una plataforma GRC. Los cuatro requieren que alguien sea responsable del calendario.

Segregación de funciones y marcos de cumplimiento

La segregación de funciones aparece por nombre o por requisito en la mayoría de los principales marcos de cumplimiento, aunque el peso legal varía según el sector y la jurisdicción. SOX la vincula a los controles de informes financieros, NIST e ISO la enmarcan como un control de seguridad general, y NIS2 la incluye en los requisitos de política de control de acceso para entidades esenciales e importantes en la UE.

Ninguno de estos marcos proporciona una matriz de SoD lista para usar. Requieren que la organización tenga una y pueda demostrar cómo se resuelven los conflictos.

Marco	Qué requiere	Citación
SOX	Controles internos documentados sobre informes financieros, incluyendo controles de acceso que impiden que una persona complete ciertas transacciones sola	SOX Sección 404, guía para pequeñas empresas de la SEC
NIST SP 800-53 Rev. 5	Las organizaciones definen y documentan las funciones individuales, luego configuran el acceso al sistema para que ninguna combinación de funciones permita que una cuenta complete un proceso sensible sola	NIST AC-5, control AC-5
ISO/IEC 27001:2022	Segregación de funciones como área de control nombrada, que cubre cómo se separan las funciones y responsabilidades en conflicto	ISO/IEC 27001:2022, Anexo A control 5.3
Directiva NIS2	Las entidades esenciales e importantes implementan medidas que cubren la seguridad de recursos humanos, políticas de control de acceso y gestión de activos	Directiva NIS2, Artículo 21, Art. 21(2)(i)

El mandato de la Sección 404 de SOX es el que la mayoría de los programas de SoD impulsados por cumplimiento citan por reflejo, aunque se aplica específicamente a los controles de informes financieros de empresas públicas, no a todos los marcos de esta tabla. Si la SoD es legalmente requerida para una organización determinada depende del sector, la jurisdicción y qué marcos aplican. Un equipo de cumplimiento o legal es la fuente correcta para esa determinación. Esta tabla es un mapa, no una opinión legal.

Cómo Passwork aplica la segregación de funciones en la bóveda

Passwork incorpora la segregación de funciones en la bóveda a través de cuatro mecanismos: roles de administrador no eliminables, roles RBAC personalizados, sincronización de grupos AD/LDAP y un registro de auditoría exportable. Juntos separan quién crea una bóveda de quién la controla permanentemente, y convierten la revisión de acceso de una búsqueda manual en una exportación programada.

Las políticas de bóveda asignan administradores a nivel de tipo de bóveda, no a quien resulte crear la bóveda. Una política de bóveda define qué administradores corporativos obtienen acceso automático y no eliminable a cada bóveda de ese tipo, para que la persona que crea una nueva bóveda departamental no pueda eliminar silenciosamente la supervisión después. Ese es un control preventivo: el conflicto entre «creador» y «administrador permanente» nunca tiene la oportunidad de formarse.

Gestión de roles en Passwork

Los roles RBAC personalizados separan la administración de cuentas y usuarios del acceso diario a la bóveda. Passwork incluye tres roles integrados — Propietario, Administrador y Miembro — y admite roles personalizados ilimitados con alcance en configuración de cuenta, gestión de bóvedas, gestión de usuarios, métodos de autenticación y acceso API. Consulte diseñar una política RBAC empresarial para saber cómo estructurar los roles antes del despliegue. Un rol creado para un técnico de soporte no necesita autoridad sobre políticas de bóveda, y no tiene que tenerla.

La sincronización de grupos AD/LDAP aplica el control preventivo a escala. En lugar de que un administrador verifique manualmente quién pertenece a qué grupo de Passwork, la membresía del grupo del directorio lo impulsa. Cuando RRHH mueve a alguien a un equipo diferente en Active Directory, su acceso a Passwork sigue automáticamente, y revocar acceso conflictivo cuando cambian los roles deja de depender de que alguien recuerde crear un ticket.

Registro de actividad en Passwork

El registro de actividad es la capa detectiva. Registra eventos a nivel de bóveda, carpeta, contraseña y cuenta, filtrable por fecha, usuario y tipo de acción, y exportable a Syslog, Visor de eventos de Windows o un SIEM. Para un auditor que pide ver evidencia de revisión de acceso, un registro exportable es la diferencia entre una respuesta real y una promesa. Los detalles completos sobre las capacidades de gestión de acceso de Passwork cubren cómo encajan estas piezas.

Lista de verificación de segregación de funciones

Use esta lista de verificación para pasar de una configuración de acceso ad hoc a un programa documentado de segregación de funciones, con o sin una plataforma GRC dedicada.

Mapee cada proceso crítico que mueve dinero, cambia accesos o toca producción.
Construya una matriz de segregación de funciones y señale cada rol que puede tanto iniciar como aprobar la misma acción.
Asigne administradores no eliminables por tipo de bóveda o política, para que la supervisión no dependa de quién creó el recurso.
Habilite la sincronización de grupos AD/LDAP para que los cambios de acceso sigan las actualizaciones del directorio en lugar de tickets manuales.
Active el registro de auditoría exportable para cada acción privilegiada.
Programe revisiones periódicas de acceso, más frecuentes para roles de alto riesgo que para los estándar.
Documente controles compensatorios donde la separación estricta no sea factible, y registre quién es responsable de cada uno.

Conclusión

La segregación de funciones funciona como una disciplina de diseño continua: cada vez que cambia un rol, se crea una bóveda o un nuevo pipeline entra en producción, la pregunta es la misma. ¿Puede una cuenta completar esto sola? Si la respuesta es sí, ese es un conflicto esperando que un incidente lo exponga.

La matriz y las citas de cumplimiento importan, pero el trabajo diario es operacional: administradores no eliminables, grupos sincronizados, un registro de auditoría que alguien realmente lee. Ahí es donde la SoD se mantiene, o silenciosamente deja de importar.

Comience abriendo su bóveda más sensible y verificando quién puede crear, aprobar y auditar acceso allí sin supervisión.

Si un administrador en esa bóveda puede crear, aprobar y auditar acceso sin supervisión, solucione eso antes de que una auditoría lo encuentre por usted. Inicie una prueba gratuita de Passwork y configure políticas de bóveda que separen esos roles desde el primer día.

Preguntas frecuentes sobre segregación de funciones

¿Es la segregación de funciones lo mismo que el privilegio mínimo?

No. El privilegio mínimo limita cuánto acceso tiene una persona. La segregación de funciones asegura que ninguna persona pueda completar un proceso sensible completo por sí sola, incluso dentro de su acceso permitido. Una cuenta con alcance limitado aún puede violar la SoD si es la única cuenta involucrada tanto en autorizar como en ejecutar una transacción.

¿Se aplica la segregación de funciones a cuentas de máquinas y servicios?

Sí. Los scripts de automatización y las cuentas de servicio pueden tener derechos conflictivos igual que las personas, por ejemplo un pipeline que tanto despliega código como aprueba su propio despliegue. Las revisiones de SoD deben incluir cuentas de servicio e identidades de automatización junto con las cuentas humanas, especialmente a medida que los pipelines de CI/CD y los agentes de IA asumen más acciones privilegiadas sin supervisión.

¿Es la segregación de funciones legalmente requerida?

Depende del marco y el sector. La Sección 404 de SOX la vincula a los controles de informes financieros para empresas públicas. NIST, ISO 27001 y NIS2 la tratan como un control de seguridad esperado en lugar de un mandato legal independiente. Verifique qué marcos aplican a su organización antes de tratar cualquier citación individual como un requisito general.

¿Cómo aplican los equipos pequeños la SoD sin una plataforma GRC dedicada?

A través de controles compensatorios: separar roles donde el tamaño del equipo lo permita, enrutar superposiciones inevitables a través de un segundo aprobador, registrar cada acción privilegiada en un registro de auditoría exportable y revisar accesos en un calendario fijo. Nada de eso requiere software de gobernanza de identidades, aunque alguien todavía tiene que ser responsable del calendario.

¿Con qué frecuencia debe revisarse una matriz de segregación de funciones?

Revise los roles de alto riesgo, como administradores de bóvedas o sistemas, mensualmente. Los roles de riesgo medio pueden seguir un ciclo trimestral. Revise inmediatamente después de cualquier cambio de rol también, ya que es cuando los nuevos conflictos se crean con más frecuencia.