Una propuesta de software puede incluir administradores, supervisores y usuarios sin explicar qué podrá hacer cada uno. Las decisiones aparecen hasta la demostración: ¿un supervisor puede reabrir una orden terminada?, ¿un colaborador temporal puede descargar los registros de clientes?, ¿quién puede cambiar los permisos de otra persona?
Antes de aprobar el desarrollo, convierte esas preguntas en un acuerdo operativo breve. El siguiente ejercicio sirve para una empresa que está contratando un portal o una herramienta interna. No constituye una certificación de seguridad ni sustituye una evaluación técnica.
Describe el trabajo antes de nombrar los roles
Reúne a alguien que realiza el trabajo y a quien responde por su resultado. Elijan un proceso, como atender una solicitud de mantenimiento, y describan sus pasos desde que llega hasta que termina. Escriban las acciones con verbos: crear, asignar, editar, aprobar, cerrar, reabrir y exportar.
En una empresa de mantenimiento hipotética, un técnico podría registrar avances de sus trabajos asignados y una persona de coordinación organizar las citas. La gerencia podría aprobar excepciones. Estas descripciones sirven más que tres etiquetas de cuenta cuyo significado cambia entre pantallas.
Asigna un responsable a cada acción. Si nadie puede explicar para qué necesita un permiso, déjalo como decisión pendiente en lugar de incluirlo por omisión.
Define los límites de cada acción
Para cada acción, pregunta sobre qué registros aplica y bajo qué condiciones. “Puede editar un trabajo” está incompleto. “Puede editar notas técnicas de un trabajo abierto que tiene asignado” sí es una decisión demostrable.
Plantea preguntas concretas:
- ¿El permiso aplica a una sucursal o a todas?
- ¿La persona puede consultar las otras solicitudes del mismo cliente?
- ¿Qué información sigue siendo editable después de una aprobación?
- ¿Una exportación contiene más datos que la pantalla?
- ¿Quién atiende una excepción cuando falta quien normalmente la autoriza?
Evita resolver todas las excepciones convirtiendo a alguien en administrador. Documenta la excepción real, su duración y quién se hace responsable de autorizarla.
Pregunta cómo se hacen cumplir las reglas
Iniciar sesión permite comprobar una identidad; no concede por sí solo acceso a todas las operaciones. OWASP recomienda limitar permisos a lo necesario, rechazar accesos no definidos y validar permisos en el servidor en cada solicitud. Ocultar un botón no basta. Su guía de autorización también explica por qué el acceso puede depender del registro concreto y no solamente del nombre del rol.
Pide al proveedor que explique ese límite en lenguaje claro. No necesitas elegir la biblioteca técnica, pero sí entender qué protege un archivo adjunto, una exportación y el registro de otro equipo.
Incluye rechazos en la demostración
Una reunión de aceptación debe mostrar algo más que un administrador haciendo todas las tareas. Prepara registros ficticios y cuentas de prueba identificadas dentro de un ambiente autorizado. No uses información real de clientes para que la presentación parezca más convincente.
En el ejemplo de mantenimiento, solicita tres demostraciones: un técnico actualiza un trabajo asignado, esa misma cuenta no puede acceder a uno ajeno y una orden cerrada sigue el procedimiento acordado para reabrirse. Incluye una descarga: los documentos podrían entregarse por un mecanismo distinto a la pantalla.
Anota el resultado esperado antes de la reunión. De lo contrario, el equipo podría aceptar lo que la implementación ya hace, aunque no coincida con la operación.
Prevé cambios en el equipo
Decide quién aprueba nuevas cuentas, quién atiende cambios de puesto y quién retira el acceso cuando termina una asignación. Incluye las cuentas de soporte del proveedor y las conexiones automáticas con otros sistemas.
Un registro útil identifica al responsable del negocio, al titular de la cuenta, los accesos concedidos y el motivo que obliga a revisarlos. Puede ser un cambio de sucursal, el cierre de un contrato o una modificación del proceso. No hace falta convertirlo en un comité complicado.
Pregunta qué ocurre con los trabajos abiertos cuando alguien deja el equipo. Retirar su acceso no debería dejar solicitudes urgentes sin responsable.
Acuerda qué evidencia se conserva y cómo corregir
Define qué cambios operativos necesitan historial: asignaciones, aprobaciones, permisos o reapertura de trabajos terminados. Pregunta quién podrá consultar ese historial y cómo solicitará una investigación. No guardes contraseñas ni datos innecesarios de clientes en las bitácoras.
Acuerda también cómo corregir un error. Restablecer un acceso, corregir una orden y recuperar un respaldo son operaciones distintas, con consecuencias diferentes.
Antes de aceptar el sistema, conserva un documento con acciones, límites, responsables de excepciones y resultados de las demostraciones. Nuestro servicio de software a la medida puede partir de ese acuerdo para definir el alcance. Si una propuesta sólo menciona “tres roles de usuario”, conversemos sobre ella y transformemos las etiquetas en decisiones verificables.