Pedir que un sistema sea «seguro» es razonable, pero la palabra sola no define qué se construirá ni quién responderá cuando haya un problema. Una conversación útil empieza con las personas, la información y las acciones que necesitan protección, y continúa durante la operación.

Estas preguntas sirven para definir responsabilidades con un proveedor. No constituyen una auditoría ni garantizan que un sistema quede libre de riesgos.

¿Quién puede entrar y qué puede hacer?

Identifica grupos de usuarios y acciones: consultar, crear, aprobar, modificar y exportar. Pregunta cómo se otorgan y retiran permisos, cómo se recupera una cuenta y quién revisa accesos que ya no se necesitan. Cuando alguien cambia de función, el proceso debe contemplar la actualización de sus permisos.

Considera un ejemplo hipotético: un portal permite a cada cliente consultar sus propias solicitudes. La revisión debe incluir qué ocurre si una persona intenta abrir por dirección directa un registro ajeno, no solo si el menú oculta ese enlace. La guía de OWASP recomienda validar la autorización en cada solicitud y evitar depender de una única capa visual.

¿Qué datos maneja y dónde se guardan?

Enumera la información necesaria, quién la consulta, cuánto tiempo se requiere conservarla y qué sistemas reciben copias. Pregunta por ambientes de prueba, copias de seguridad y exportación. No uses datos reales para demostrar una función si no se han acordado las condiciones apropiadas.

Si se tratan datos personales o información regulada, identifica con el equipo responsable las obligaciones aplicables al caso. Una lista general de seguridad no reemplaza esa revisión.

¿Cómo se mantiene actualizado?

Pregunta quién identifica y revisa vulnerabilidades, cómo se priorizan actualizaciones y quién puede aprobar una intervención. El desarrollo inicial y el mantenimiento son trabajos distintos: verifica si la propuesta incluye seguimiento posterior, plazos de atención o un mecanismo para acordarlos.

El marco SSDF de NIST organiza prácticas de desarrollo seguro que pueden integrarse en diferentes ciclos de trabajo. Úsalo para formular preguntas concretas; mencionar un marco no demuestra que un proveedor lo haya implementado ni equivale a una certificación.

¿Qué pasa si algo falla?

  • ¿Quién recibe el aviso y cómo se contacta fuera del horario acordado?
  • ¿Dónde están las copias y cuándo se probó la restauración?
  • ¿Qué registros permiten investigar cambios o accesos indebidos?
  • ¿Quién puede suspender una cuenta o una integración?
  • ¿Cómo se comunica el incidente y quién toma cada decisión?

Convierte respuestas en acuerdos comprobables

Solicita que el alcance, los responsables y las exclusiones queden claros. Si necesitas recuperación en determinado plazo o revisión periódica de accesos, descríbelo y acuerda cómo se verificará. También pregunta qué depende de servicios externos y qué debe hacer tu propio equipo.

La seguridad no es una casilla que se marque al publicar. Es un conjunto de decisiones que deben revisarse cuando cambian los usuarios, las integraciones o la información del sistema.

Fuentes consultadas

Definamos los requisitos de tu sistema

Cuéntanos qué información y usuarios intervienen para identificar las decisiones que tu proyecto necesita.

Hablar sobre mi sistema