Antes de evaluar riesgos, seleccionar controles o redactar políticas, una organización necesita responder una pregunta más básica:
¿Qué realidad debe representar nuestro SGSI?
ISO/IEC 27001:2022 sitúa esta pregunta al comienzo de los requisitos (Cláusula 4) porque un sistema de gestión de seguridad de la información no debería diseñarse en abstracto. Si vienes de realizar un diagnóstico inicial, te resultará útil repasar el análisis GAP ISO 27001 y plan de acción.
Una empresa SaaS con clientes en varios países, desarrollo distribuido y dependencia de proveedores cloud tiene un contexto totalmente diferente al de un hospital, una industria manufacturera o una pyme con infraestructura local.
Por eso, dos organizaciones pueden aplicar la misma norma y terminar con alcances, riesgos y controles sustancialmente distintos. Para conocer las bases del sistema, te sugerimos revisar qué es un SGSI y cómo definir su alcance.
En términos prácticos, el recorrido metodológico es:
propósito de la organización → cuestiones internas y externas → partes interesadas → requisitos relevantes → interfaces y dependencias → límites del SGSI → declaración de alcance
Qué es el contexto de la organización en ISO 27001
El contexto es el conjunto de condiciones internas y externas que pueden influir en la capacidad de la organización para lograr los resultados previstos de su SGSI.
No es una lista genérica de “fortalezas y amenazas”, ni un inventario prematuro de riesgos. Es una representación razonada del entorno en el que opera el negocio. Para recordar la terminología normativa, consulta los conceptos de organización, partes interesadas y contexto.
Para construirla conviene analizar:
- qué hace la organización y qué servicios entrega;
- qué información necesita proteger;
- qué objetivos estratégicos persigue;
- qué estructura y gobernanza posee;
- qué tecnologías e infraestructuras utiliza;
- qué obligaciones legales y contractuales debe atender;
- de qué proveedores críticos depende;
- quiénes son las partes interesadas relevantes.
La cláusula 4 como sistema, no como cuatro casillas
La cláusula 4 se divide formalmente en cuatro subcláusulas:
- 4.1 Comprensión de la organización y de su contexto: Determinación de cuestiones internas y externas.
- 4.2 Comprensión de las necesidades y expectativas de las partes interesadas: Identificación de actores y sus requisitos.
- 4.3 Determinación del alcance del SGSI: Definición de los límites y aplicabilidad.
- 4.4 Sistema de gestión de la seguridad de la información: Establecimiento, operación y mejora de los procesos necesarios.
El error habitual es tratarlos como documentos independientes. En la práctica se alimentan en cadena. Las cuestiones de contexto determinan quiénes son las partes interesadas relevantes; los requisitos de estas partes condicionan los límites del sistema; y el alcance resultante establece el terreno sobre el cual se aplicará la evaluación de riesgos (explorada en conceptos de riesgo, evaluación y tratamiento).
Pasos 1 a 4: Cuestiones internas y externas
Paso 1 — Empieza por el propósito de la organización
Aclara qué productos o servicios entrega la empresa, qué información procesa y qué unidades de negocio participan. Esto evita construir el SGSI únicamente alrededor del departamento de IT cuando el verdadero objeto a proteger es un servicio de negocio.
Paso 2 — Identifica cuestiones internas relevantes
Analiza las condiciones internas de la empresa agrupadas en categorías prácticas:
- Estrategia: planes de expansión, fusiones, lanzamiento de nuevos productos o migración cloud.
- Gobierno y estructura: organigrama, grado de centralización y responsabilidades de seguridad.
- Personas: competencias, cultura de seguridad, rotación y trabajo remoto.
- Procesos: nivel de formalización, procesos heredados e integraciones.
- Tecnología e información: arquitecturas, deuda técnica, clasificación de datos y sistemas SaaS.
Paso 3 — Identifica cuestiones externas relevantes
Evalúa las fuerzas del entorno fuera del control directo de la empresa:
- Legal y regulatoria: leyes de protección de datos, regulaciones sectoriales y normativas internacionales. Para una visión amplia, consulta la familia ISO/IEC 27000.
- Mercado y clientes: exigencias contractuales de seguridad, auditorías de terceros y compromisos de SLA.
- Cadena de suministro: dependencia de proveedores cloud, data centers y servicios gestionados.
- Entorno físico y ambiental: ubicación de sedes, exposición a desastres naturales o fallos energéticos.
Paso 4 — Filtra las cuestiones por su relevancia para el SGSI
Una lista de 80 factores no es mejor que una de 12. Conserva únicamente aquellas cuestiones que influyan directamente en la capacidad del SGSI de alcanzar sus resultados previstos.
¿Debo usar FODA, PESTEL o una matriz específica?
ISO 27001 no impone ninguna herramienta metodológica concreta.
Matriz FODA / SWOT
Útil para talleres ejecutivos iniciales. Precaución: evitar quedarse en frases genéricas como “amenaza: ciberataques”.
Análisis PESTEL
Ideal para organizaciones internacionales o sujetas a entornos regulatorios y tecnológicos complejos.
Workshops y revisión documental
Entrevistas con líderes de área y revisión de contratos, mapas de procesos y arquitecturas tecnológicas.
Partes interesadas y sus requisitos (Cláusula 4.2)
Una parte interesada es cualquier actor que puede afectar, verse afectado o percibir que se ve afectado por las decisiones de la organización. Para el SGSI, se deben identificar las partes interesadas relevantes:
- Clientes y usuarios finales: Exigen confidencialidad, privacidad y continuidad del servicio.
- Reguladores y autoridades: Exigen cumplimiento normativo y notificación de incidentes.
- Proveedores y socios tecnológicos: Requieren reglas claras de acceso y responsabilidades compartidas.
- Alta dirección y accionistas: Buscan resiliencia del negocio, reputación y gestión eficiente de recursos.
Es vital diferenciar entre necesidad/expectativa y requisito relevante. Una expectativa de un cliente puede ser que la empresa responda correos al instante; un requisito relevante para el SGSI es la notificación formal de brechas de seguridad dentro de las 72 horas acordadas contractualmente.
Amd 1:2024 — Impacto del Cambio Climático en el contexto
En febrero de 2024, ISO publicó la modificación ISO/IEC 27001:2022/Amd 1:2024 (Climate action changes). Esta enmienda añade dos consideraciones en las cláusulas 4.1 y 4.2:
- La organización debe determinar si el cambio climático es una cuestión relevante dentro de su análisis de contexto.
- La organización debe considerar si las partes interesadas relevantes tienen requisitos vinculados al cambio climático.
Lo que NO significa: No obliga a implantar controles ambientales ni convierte a ISO 27001 en una norma ecológica.
Lo que SÍ significa: Exige no ignorar el tema automáticamente. Una empresa con centros de datos en zonas propensas a sequías, olas de calor extremas o inestabilidad energética debe valorar cómo estos factores climáticos afectan la disponibilidad física, la continuidad del servicio o la resiliencia de la cadena de suministro.
Del contexto a la determinación del alcance (Cláusula 4.3)
El alcance no se redacta de forma arbitraria; debe ser la consecuencia lógica del contexto y de los requisitos. Para que sea auditable y sólido, debe definir claramente seis dimensiones:
| Dimensión | Elemento a definir | Ejemplo de aplicación |
|---|---|---|
| 1. Servicios/Productos | Qué entregables cubre el sistema | Plataforma SaaS de gestión de pagos Alpha |
| 2. Procesos | Qué actividades operativas incluye | Diseño, desarrollo, despliegue, soporte y administración |
| 3. Ubicaciones | Dónde se realizan las tareas | Sede central en Madrid, oficina técnica y trabajo remoto |
| 4. Tecnología | Qué infraestructura soporta el sistema | Infraestructura cloud AWS, repositorios Git e IAM corporativo |
| 5. Interfaces | Puntos de conexión con lo externo al alcance | Conexión con el sistema ERP corporativo y APIs de terceros |
| 6. Dependencias | Terceros de los que depende la operación | Proveedores IaaS/PaaS, data center y SOC gestionado |
Para profundizar en cómo se entrelazan estas piezas, consulta cómo se relacionan los conceptos de un SGSI.
Ejemplo práctico: Alcance en una empresa SaaS
Un alcance mal redactado suele decir: “El SGSI cubre el departamento de IT”. Esto es ambiguo porque no delimita ni procesos de negocio ni servicios prestados.
Un alcance redactado correctamente responde a la estructura:
“El SGSI cubre los procesos de diseño, desarrollo, ingeniería, operación, mantenimiento y soporte de la plataforma SaaS de analítica corporativa prestada por TechCorp, operada desde la sede principal en Barcelona y modalidades de trabajo remoto autorizado, apoyada en infraestructura cloud AWS y considerando las interfaces críticas con proveedores de pagos y funciones de RR. HH. necesarias para la prestación del servicio.”
Errores frecuentes al definir el contexto y alcance
- Empezar seleccionando controles del Anexo A sin haber definido el alcance ni el contexto.
- Confundir el alcance del SGSI con un departamento del organigrama.
- Excluir proveedores o funciones externalizadas asumiendo que al estar fuera de la empresa no afectan al alcance.
- Definir un alcance artificialmente reducido solo para facilitar la certificación, dejando fuera dependencias críticas.
- Tratar el análisis de contexto como un documento estático que nunca se revisa ante cambios organizativos.
- Ignorar la evaluación del impacto del cambio climático tras la enmienda Amd 1:2024.
Plantillas prácticas de trabajo
Registro de cuestiones de contexto
| ID | Tipo | Cuestión de contexto | Impacto en el SGSI | Propietario |
|---|---|---|---|---|
| C-01 | Interna | Migración masiva a microservicios cloud | Afecta arquitectura, riesgos y gestión de accesos | CTO |
| C-02 | Externa | Nuevas exigencias contractuales de clientes B2B | Condiciona SLA de disponibilidad y auditorías de terceros | Legal / CISO |
| C-03 | Externa | Olas de calor extremas en sede de centro de datos | Afecta planes de continuidad y resiliencia física | Operaciones |
Registro de partes interesadas
| Parte interesada | Relevancia | Requisito identificado | Mecanismo en el SGSI |
|---|---|---|---|
| Clientes Enterprise | Alta | Notificación de brechas < 24h | Procedimiento de Gestión de Incidentes |
| Agencia de Protección de Datos | Alta | Cumplimiento legal y privacidad desde el diseño | Política de Privacidad y Controles de Cifrado |
| Proveedor Cloud (IaaS) | Alta | Acuerdo de nivel de servicio (SLA) 99.9% | Evaluación y Gestión de Proveedores |
Preguntas frecuentes
¿ISO 27001 obliga a utilizar la herramienta FODA?
No. La norma exige determinar las cuestiones internas y externas relevantes, pero deja a libre elección si utilizar FODA, PESTEL, talleres o revisión documental.
¿El alcance del SGSI debe incluir obligatoriamente a toda la empresa?
No. Puede limitarse a una línea de negocio, un servicio específico o una sede, siempre que los límites estén claramente definidos y se gestionen las interfaces con las partes no incluidas.
¿Cómo afecta la enmienda de cambio climático (Amd 1:2024)?
Exige evaluar si los factores climáticos son una cuestión relevante para el contexto del SGSI o si las partes interesadas tienen requisitos al respecto. No impone controles obligatorios si no resulta material para el sistema.
¿Cada cuánto tiempo se debe revisar el contexto de la organización?
Debe revisarse periódicamente (por ejemplo, en la revisión por la dirección) y de forma inmediata ante cambios significativos como reorganizaciones, adquisiciones, nuevas regulaciones o incidentes de gran impacto.
Del contexto a la gobernanza práctica
Un SGSI sólido no empieza redactando políticas a ciegas, sino comprendiendo el propósito, el entorno y los límites de la organización.
Si el contexto y el alcance están bien construidos, la posterior evaluación de riesgos y la asignación de controles responderán a necesidades reales del negocio.
Si quieres profundizar en cómo conectar el contexto, las partes interesadas, la gestión de riesgos y la gobernanza de IT dentro de un marco profesional de GRC, puedes continuar tu aprendizaje con el curso Analista GRC. Gobernanza de IT, Riesgo y Cumplimiento.
