¿Qué es un SGSI? Cómo conectar el trabajo de seguridad con las decisiones de negocio

El trabajo de seguridad puede parecer intenso sin estar coordinado. Ingeniería aplica parches a los sistemas, RR. HH. gestiona las bajas, compras revisa a los proveedores y la dirección aprueba excepciones. Un sistema de gestión de la seguridad de la información conecta esas actividades con objetivos comunes y con un proceso de decisión explícito.

Para un CEO, la pregunta importante no es si la empresa tiene suficientes documentos de seguridad. Es si la dirección puede explicar qué hay que proteger, qué riesgos importan, quién es responsable y por qué el nivel de protección actual es aceptable. Un SGSI hace que esas respuestas sean repetibles a medida que cambia el negocio.

Qué gestiona realmente un SGSI

Un sistema de gestión de la seguridad de la información es el sistema organizativo para gestionar los riesgos de seguridad de la información. Incluye responsabilidades, políticas, procesos, recursos, controles y evaluación. El software puede darle soporte, pero el software no es el sistema. Una biblioteca de documentos puede describirlo, pero los documentos por sí solos no demuestran que funcione.

Su finalidad es proteger tres propiedades de la información:

• Confidencialidad: la información solo está disponible para las personas y los sistemas autorizados.
• Integridad: la información sigue siendo exacta y completa, y está protegida frente a modificaciones indebidas.
• Disponibilidad: los usuarios autorizados pueden obtener la información y utilizar los servicios de soporte cuando lo necesitan.

Estas propiedades se traducen en preocupaciones de negocio. La exposición de registros de clientes puede minar la confianza y generar obligaciones legales. Unas instrucciones de pago incorrectas pueden causar pérdidas económicas. Una plataforma de soporte no disponible puede impedir que la empresa cumpla sus compromisos con los clientes.

ISO/IEC 27001 establece requisitos reconocidos para un SGSI con un alcance definido. Los capítulos 4 a 10 abordan el contexto de la organización, el liderazgo, la planificación, el soporte, la operación, la evaluación del desempeño y la mejora. Una organización puede desarrollar y operar un SGSI antes de plantearse la certificación.

El sistema de gestión aporta la conexión entre las salvaguardas individuales y las decisiones de negocio. Una copia de seguridad es un control. Decidir qué debe poder recuperarse, financiar la capacidad de recuperación, probarla y actuar ante las pruebas fallidas es trabajo del sistema de gestión.

Por qué la dirección necesita estas conexiones

Las decisiones de seguridad ya se toman en toda la empresa, se llamen o no SGSI. Alguien elige un proveedor SaaS, aprueba un acceso privilegiado, acepta un parche aplazado o se compromete con un requisito de recuperación de un cliente. Sin un proceso compartido, esas decisiones pueden partir de supuestos distintos y nadie responde de su efecto combinado.

Un SGSI da a la dirección una base para priorizar recursos limitados. También ayuda a los equipos a responder a las preguntas de los clientes a partir de registros mantenidos, en lugar de reconstruir sus prácticas en cada revisión comercial. Eso no garantiza el éxito en un proceso de compra; hace que las afirmaciones subyacentes sean más fáciles de respaldar.

Las conexiones deben responder a preguntas prácticas:

Estos vínculos son especialmente importantes durante el crecimiento. Las prácticas informales que funcionan cuando todos se conocen dejan de ser fiables cuando llegan nuevos equipos, ubicaciones, proveedores y compromisos con clientes.

Defina un alcance que refleje el negocio

Empiece por el contexto del negocio, no por una lista de controles. Identifique los servicios que presta la organización, la información que utilizan, las partes interesadas y sus requisitos, y las condiciones internas y externas que afectan a la seguridad.

El alcance define el perímetro del SGSI. Debe identificar las actividades cubiertas, las unidades organizativas, las ubicaciones cuando proceda, la tecnología y las interfaces con otras partes del negocio. Un primer alcance útil podría abarcar un producto de cara al cliente y sus operaciones de prestación, en lugar de todas las actividades corporativas.

Sin embargo, un alcance acotado no puede ignorar las dependencias. Si RR. HH. inicia el proceso de baja de los empleados con acceso al producto, esa interfaz importa. Si un proveedor de servicios en la nube aloja el servicio, la externalización no hace desaparecer la dependencia. Si el equipo de soporte exporta información de clientes, el proceso de exportación forma parte del análisis.

Redacte una declaración de alcance y póngala a prueba con tres preguntas:

• ¿Podría un cliente entender qué está cubierto y qué no?
• ¿Hemos incluido las dependencias necesarias para proteger el servicio cubierto?
• ¿Pueden unos responsables designados mantener el sistema dentro de este perímetro?

Empezar por algo pequeño es una recomendación práctica, no un permiso para crear un perímetro engañoso. Un alcance claro con responsables designados es más sólido que un registro amplio que nadie actualiza. Amplíelo de forma deliberada cuando nuevos servicios o dependencias lo justifiquen.

Asigne decisiones, no solo tareas

La alta dirección debe proporcionar orientación y apoyo a un SGSI conforme a ISO 27001. Delegar la coordinación en un responsable de seguridad no transfiere la responsabilidad de la dirección sobre las prioridades, los recursos y el riesgo aceptable.

Separe las responsabilidades que a menudo se concentran en el puesto de una sola persona:

Una empresa pequeña puede asignar varias responsabilidades a una misma persona. Aun así, debe identificar qué papel ejerce esa persona en cada caso y dónde se necesita un cuestionamiento independiente, especialmente en la auditoría interna.

Defina umbrales de escalado. Un jefe de equipo podría aprobar una excepción operativa de corta duración dentro de unos límites acordados; un riesgo que amenace compromisos importantes con clientes puede requerir la aprobación de la dirección. Registre la justificación, las condiciones, la fecha de caducidad y el desencadenante de revisión. «Aceptado por la dirección» no basta si nadie puede identificar quién tomó la decisión ni qué exposición se aceptó.

Convierta la evaluación de riesgos en un proceso de priorización

La evaluación de riesgos debe describir escenarios plausibles, no limitarse a nombrar activos o enumerar debilidades. «Base de datos de clientes» es un activo. «Una cuenta de administrador comprometida permite la extracción masiva de registros de clientes» es un escenario de riesgo con una causa y una consecuencia.

Establezca un método de evaluación documentado y unos criterios de aceptación del riesgo. ISO 27001 no exige una fórmula de puntuación concreta. Como enfoque práctico, defina categorías de probabilidad e impacto en un lenguaje que entiendan quienes toman las decisiones, incluidas la interrupción operativa, las pérdidas económicas, las consecuencias contractuales y, cuando proceda, los daños a las personas.

Para cada escenario relevante, registre:

• El servicio, la información y las dependencias afectados.
• La amenaza o el evento y las vulnerabilidades pertinentes.
• Los controles existentes y sus limitaciones conocidas.
• La probabilidad, el impacto y la prioridad resultante.
• El responsable del riesgo y el tratamiento propuesto.

El tratamiento puede consistir en reducir la exposición mediante controles, evitar una actividad, compartir aspectos del riesgo mediante contratos o seguros, o aceptar el riesgo dentro de los criterios aprobados. Un seguro no recupera la información perdida, y un contrato con un proveedor no elimina las responsabilidades de la organización.

Distinga el riesgo actual del riesgo residual tras el tratamiento. No reduzca una valoración solo porque una tarea esté programada. Vuelva a evaluar tras la implantación y con evidencias adecuadas de funcionamiento. Obtenga la aprobación del plan de tratamiento y la aceptación del riesgo residual a través de la autoridad definida.

El registro operativo de riesgos debe seguir siendo un registro de decisiones: qué cambió, por qué se eligió un tratamiento y cuándo debe revisarse la evaluación.

Seleccione los controles y explique su aplicabilidad

Los controles son las medidas que se utilizan para modificar el riesgo. Incluyen salvaguardas técnicas como la autenticación multifactor, procesos organizativos como las revisiones de proveedores, medidas relacionadas con las personas como la formación y protecciones físicas para dispositivos e instalaciones.

El anexo A de ISO/IEC 27001:2022 contiene 93 controles de referencia: 37 organizacionales, 8 de personas, 14 físicos y 34 tecnológicos. La selección se basa en el riesgo; una organización no implanta automáticamente todos los controles. ISO/IEC 27002 ofrece orientación para la implantación, no un requisito de certificación del SGSI independiente.

Para ISO 27001, determine los controles necesarios para el tratamiento de los riesgos y compárelos con el anexo A para comprobar que no se ha omitido ningún control necesario. Los controles también pueden ser necesarios por requisitos legales o contractuales, y no tienen por qué limitarse al anexo A.

La Declaración de Aplicabilidad registra los controles necesarios, la justificación de su inclusión, su estado de implantación y la justificación de la exclusión de controles del anexo A. Es distinta del plan de tratamiento de riesgos: una explica el conjunto de controles aplicable; el otro, las acciones necesarias para tratar los riesgos. Consulte la guía de los controles del anexo A para conocer esa estructura de referencia.

Para cada control seleccionado, defina un responsable, el resultado previsto, cómo funciona y qué evidencias demostrarán su eficacia. «Control de accesos implantado» es menos útil que un proceso explícito que abarque la aprobación, el aprovisionamiento, la revisión y la retirada.

Las políticas deben establecer reglas que las personas puedan seguir. Los procedimientos deben explicar cómo se ejecutan. Ninguno de ellos debe prometer revisiones o restricciones técnicas que la organización no pueda mantener realmente.

Integre las evidencias en las operaciones normales

Las evidencias deben surgir de hacer el trabajo, no de reconstruir un relato antes de una auditoría. Una revisión de accesos puede generar una lista de usuarios fechada, las decisiones de los revisores, los tickets de retirada y la confirmación de que se realizaron los cambios. Un ejercicio de recuperación puede generar las condiciones de la prueba, los resultados, las limitaciones observadas y las acciones de seguimiento.

Una captura de pantalla puede mostrar un ajuste en un momento dado. No demuestra necesariamente que ese ajuste abarque todos los sistemas pertinentes ni que haya sido eficaz durante todo un periodo. Los revisores deben examinar el alcance, la fecha, el origen, la exhaustividad y qué conclusión respaldan realmente las evidencias.

Un conjunto práctico de evidencias del SGSI incluye:

No cada fila necesita un documento independiente. Una organización pequeña puede combinar registros siempre que se mantengan la claridad y la trazabilidad. Proteja las propias evidencias: las exportaciones de usuarios, los registros de incidentes y las capturas de pantalla pueden contener información sensible y deben contar con mecanismos adecuados de acceso y conservación.

Ejemplo práctico: una plataforma de atención al cliente

Considere, a título ilustrativo, una empresa de software de 30 personas que utiliza una plataforma SaaS de atención al cliente. Supongamos que la plataforma contiene nombres de clientes, datos de contacto, historiales de tickets y, ocasionalmente, adjuntos de diagnóstico. El personal utiliza cuentas individuales, un proveedor externo aloja la aplicación y algunos tickets se exportan para resolver incidencias. Son supuestos del ejemplo, no un modelo de empresa prescrito.

El alcance del SGSI abarca las operaciones de atención al cliente y sus dependencias: la identidad del personal, el proveedor SaaS, el acceso desde los dispositivos finales, las exportaciones, la conservación y los mecanismos de recuperación. El responsable de soporte es el responsable del servicio; TI opera los controles de acceso; compras coordina la revisión del proveedor; la dirección aprueba los riesgos que superan las atribuciones delegadas.

La evaluación inicial identifica tres escenarios:

Supongamos que una conciliación de cuentas descubre que un antiguo empleado sigue teniendo acceso. La acción inmediata es retirarlo y evaluar si la cuenta se utilizó de forma indebida. La acción del sistema de gestión es determinar por qué falló la retirada. Quizá RR. HH. avisó a TI, pero la aplicación de soporte no figuraba en la lista de comprobación de bajas.

La acción correctiva actualiza entonces el inventario de aplicaciones, añade la plataforma de soporte al proceso de bajas, asigna la responsabilidad de confirmación y comprueba las bajas posteriores. Cerrar únicamente el ticket de retirada resolvería la situación inmediata sin corregir su causa.

Supongamos ahora que el proveedor SaaS modifica su lista de subencargados. El responsable del proveedor revisa el cambio frente a los requisitos contractuales, de seguridad y de privacidad pertinentes. Registra si afecta al tratamiento de los datos, a las dependencias o al riesgo aceptado, y si es necesaria una revisión especializada. El cambio tiene un responsable y una vía de revisión, en lugar de quedarse sin leer en un buzón compartido.

La dirección recibe las decisiones pendientes: si financiar una alternativa más sólida, reducir la información que se recoge en los adjuntos o aceptar una exposición restante definida. Así es como el SGSI conecta los hallazgos operativos con las decisiones de negocio.

Mantenga una cadencia capaz de detectar los cambios

Programe las revisiones en función del riesgo, la frecuencia de los cambios y las obligaciones. Una revisión semanal de brechas durante la implantación inicial y una revisión periódica por la dirección pueden ser opciones prácticas útiles, pero no son intervalos universales impuestos por ISO 27001. La norma exige auditorías internas y revisiones por la dirección a intervalos planificados.

Añada desencadenantes basados en eventos: incidentes, versiones importantes, adquisiciones, cambios de proveedores, nuevas obligaciones legales, compromisos significativos con clientes y hallazgos de auditoría. Un calendario por sí solo pasará por alto cambios importantes entre reuniones programadas.

El seguimiento se pregunta si los controles y los objetivos funcionan según lo previsto. La auditoría interna evalúa si el SGSI es conforme con los requisitos y si se ha implantado y mantenido de forma eficaz. La revisión por la dirección considera la idoneidad, la adecuación y la eficacia del sistema y toma decisiones sobre cambios y recursos. Estas actividades se alimentan mutuamente, pero no son intercambiables.

La dirección debe recibir información lista para decidir: riesgos relevantes, tratamientos vencidos, fallos repetidos, hallazgos de auditoría, requisitos cambiantes y limitaciones de recursos. Contar las tareas completadas sin examinar los resultados puede ocultar un desempeño deficiente. La guía de métricas del SGSI analiza indicadores útiles.

La gestión de incidentes también forma parte de este ciclo. Defina las vías de notificación, los criterios de evaluación, las responsabilidades de respuesta, la autoridad de comunicación y los mecanismos de recuperación. Pruebe las vías de contacto y la toma de decisiones mediante ejercicios. Evalúe las obligaciones de notificación aplicables en lugar de suponer que un único plazo sirve para todos los incidentes.

Tras un incidente o una no conformidad, resuelva el problema inmediato, investigue las causas, aplique acciones correctivas y evalúe su eficacia. Los hallazgos repetidos son un motivo para replantear el diseño del proceso o los recursos, no para repetir el mismo recordatorio.

Separe el SGSI, la certificación y las obligaciones legales

El SGSI es el sistema que opera la organización. ISO 27001 es una norma con respecto a la cual puede evaluarse ese sistema. La certificación la emite un organismo de certificación independiente, no ISO ni Secani, y se aplica al alcance declarado.

La certificación puede ser un mecanismo de aseguramiento útil cuando los clientes u otras partes interesadas la exigen. No demuestra que todas las actividades de la empresa estén cubiertas, que todos los controles funcionen siempre ni que no puedan producirse incidentes. Compruebe el alcance y la vigencia en lugar de tratar un certificado como una garantía de seguridad para toda la empresa.

La aplicabilidad legal requiere un análisis independiente. El artículo 32 del RGPD exige medidas técnicas y organizativas de seguridad apropiadas en función de los riesgos pertinentes. NIS2 aborda la supervisión por parte de la dirección, las medidas de gestión de riesgos y la notificación de incidentes para las entidades cubiertas a través de la transposición nacional.

Un SGSI puede organizar las evidencias y las responsabilidades que respaldan esas obligaciones, pero la certificación no acredita el cumplimiento del RGPD ni de NIS2. Tampoco es correcto afirmar que un SGSI nunca puede ser legalmente obligatorio: deben comprobarse las normas nacionales o sectoriales aplicables.

Evite tres fallos de implantación previsibles

Adoptar plantillas sin modificarlas. Las plantillas pueden proporcionar un esquema, pero los responsables deben validar cada compromiso frente a la práctica real. Una política que exige revisiones que nadie realiza crea una brecha no gestionada.

Trazar un perímetro que nadie puede mantener. Un inventario ambicioso no sirve de nada si las responsabilidades y las dependencias no están claras. Empiece por un perímetro de servicio defendible y amplíelo después mediante un plan explícito.

Tratar la certificación como la meta. El sistema debe mantenerse a través de cambios de personal, cambios de proveedores, incidentes y nuevos productos. Presupueste la operación, la revisión y la mejora, no solo la documentación inicial.

Una advertencia relacionada es la automatización sin revisión. Los registros recopilados automáticamente y los resúmenes generados por IA pueden apoyar el trabajo, pero las personas siguen teniendo que determinar su pertinencia, evaluar las brechas y aprobar las conclusiones.

Concrete la primera decisión de la dirección

Elija un servicio representativo y pida a su responsable que aporte una declaración de alcance, un mapa de dependencias, los escenarios de riesgo iniciales, los controles actuales y las decisiones pendientes. Acuerde quién puede aceptar riesgos, qué recursos hay disponibles y cuándo se revisarán los avances. Así se crea un punto de partida manejable sin aparentar que toda la organización ya está cubierta.

El modelo de espacios de trabajo de Secani respalda este flujo de trabajo modelando los servicios y los objetos de soporte, vinculando las evidencias con los requisitos, los controles y las decisiones, y asignando responsables y tareas de revisión. Los equipos pueden convertir la falta de evidencias o las responsabilidades poco claras en tareas. Las sugerencias asistidas por IA siguen siendo borradores sujetos a revisión humana, con las fuentes y las aprobaciones trazables.

Por tanto, la próxima conversación de la dirección debe ser concreta: ¿qué servicio protegemos primero, qué exposición requiere una decisión ahora y qué evidencias demostrarán que la decisión ha funcionado?