ISMS Copilot Docs

Proporcionar Contexto Organizacional

Los consejos genéricos de cumplimiento rara vez sobreviven a la implementación en el mundo real. Una startup de 10 personas y una empresa de 500 empleados tienen recursos, riesgos y alcances de auditoría muy diferentes,…

Por qué el Contexto Importa

Los consejos genéricos de cumplimiento rara vez sobreviven a la implementación en el mundo real. Una startup de 10 personas y una empresa de 500 empleados tienen recursos, riesgos y alcances de auditoría muy diferentes, incluso cuando persiguen la misma certificación ISO 27001 o SOC 2.

ISMS Copilot adapta las recomendaciones cuando proporcionas contexto organizacional. Esto transforma los controles teóricos en pasos prácticos alineados con tu industria, pila tecnológica, tamaño del equipo y nivel de madurez.

Elementos Esenciales de Contexto

1. Tamaño y Estructura de la Empresa

El número de empleados y la estructura organizacional influyen en la complejidad de los controles y la asignación de recursos.

Ejemplo: "Somos una startup de 25 personas con un equipo de ingeniería de 5 personas, sin personal de seguridad dedicado y un presupuesto ajustado."

Por qué importa: Los equipos pequeños necesitan controles simplificados y automatizados en lugar de procesos a escala empresarial. ISMS Copilot recomienda herramientas SaaS en lugar de soluciones personalizadas y roles combinados en lugar de puestos especializados.

2. Industria y Entorno Regulatorio

Tu sector determina las regulaciones aplicables y las prioridades de riesgo.

Ejemplos:

  • "SaaS de salud que procesa PHI bajo HIPAA"
  • "Fintech que maneja datos de pago, sujeto a PCI DSS y GDPR"
  • "SaaS B2B que vende a clientes empresariales que requieren SOC 2"

Por qué importa: La salud prioriza la confidencialidad de los datos del paciente; el sector fintech enfatiza la integridad de las transacciones; el SaaS B2B se centra en el aislamiento de datos de los clientes. Los controles y la evidencia cambian en consecuencia.

3. Pila Tecnológica

Enumera tu infraestructura principal, aplicaciones y herramientas de seguridad.

Ejemplo: "Usamos AWS (EC2, RDS, S3), GitHub para código, Google Workspace para colaboración, Okta para SSO y Datadog para monitoreo."

Por qué importa: La orientación específica para herramientas supera a las recomendaciones genéricas. En lugar de "implementar registro", obtienes "configurar AWS CloudTrail con retención en S3 y alertas en Datadog para ISO 27001 A.8.15."

4. Madurez Actual y Objetivos

Describe dónde estás y hacia dónde te diriges.

Ejemplos:

  • "Comenzando la implementación de ISO 27001 desde cero, auditoría en 12 meses"
  • "Manteniendo SOC 2 Tipo II, tercera auditoría anual en 6 meses"
  • "Expandiendo de ISO 27001 para añadir SOC 2 para clientes en EE. UU."

Por qué importa: Las implementaciones por primera vez necesitan controles fundamentales y victorias rápidas. Los programas maduros requieren optimización y refinamiento de evidencia. Los escenarios de múltiples marcos se benefician del mapeo de controles para reducir duplicaciones.

5. Desafíos o Restricciones Específicos

Menciona limitaciones, hallazgos de auditorías anteriores o situaciones únicas.

Ejemplos:

  • "El auditor anterior señaló políticas de contraseñas débiles y falta de MFA"
  • "Equipo remoto en 15 países, sin oficina física"
  • "Monolito heredado en migración a microservicios en Kubernetes"
  • "Restricción presupuestaria: $10k en total para herramientas de cumplimiento"

Por qué importa: Las restricciones moldean soluciones factibles. El trabajo remoto cambia los controles de seguridad física; el presupuesto limita las opciones de herramientas; los hallazgos de auditorías priorizan la remediación.

Contexto en Acción: Antes y Después

Ejemplo 1: Política de Control de Acceso

❌ Sin contexto: "Generar una política de control de acceso para SOC 2"

Resultado: Plantilla de política genérica que requiere una personalización significativa para roles, herramientas y procesos.

✅ Con contexto: "Generar una política de control de acceso para SOC 2 CC6 para una empresa SaaS de 50 personas que usa Okta SSO, GitHub, AWS y Salesforce. Incluir revisiones trimestrales de acceso por parte de los gerentes y acceso basado en roles para los equipos de ingeniería, ventas y soporte."

Resultado: Borrador de política con herramientas nombradas, roles específicos, frecuencia de revisión definida y procedimientos listos para auditoría.

Ejemplo 2: Evaluación de Riesgos

❌ Sin contexto: "¿Cómo hago una evaluación de riesgos para ISO 27001?"

Resultado: Resumen general de metodología sin especificaciones de activos o priorización.

✅ Con contexto: "Crear una plantilla de evaluación de riesgos para ISO 27001 A.5.7 para un SaaS de salud con 100k registros de pacientes en AWS RDS, usando Stripe para pagos e Intercom para soporte. Priorizar amenazas relevantes para HIPAA."

Resultado: Plantilla que identifica activos críticos (base de datos de pacientes, procesador de pagos), amenazas relevantes (fuga de datos, ransomware) y controles específicos para el sector salud.

Ejemplo 3: Hoja de Ruta de Implementación

❌ Sin contexto: "Dame un plan de implementación para SOC 2"

Resultado: Fases de alto nivel sin alineación de plazos o recursos.

✅ Con contexto: "Crear una hoja de ruta de implementación de SOC 2 Tipo I de 9 meses para una startup de 30 personas con un líder de seguridad a tiempo parcial, enfocada en los Criterios de Servicios de Confianza para Seguridad y Disponibilidad. Usamos Google Workspace, GitHub, AWS y tenemos MFA básico pero sin políticas formales."

Resultado: Plan por fases con victorias rápidas (formalizar el MFA existente), hitos apropiados para los recursos y tareas específicas para herramientas alineadas con el plazo y la capacidad del equipo.

Usa Instrucciones Personalizadas en Espacios de Trabajo para establecer el contexto una vez para todas las consultas en un proyecto. Esto evita repetir "Somos un SaaS de salud de 50 personas que usa AWS..." en cada mensaje.

Organizar el Contexto con Espacios de Trabajo

Para trabajo con clientes o escenarios de múltiples proyectos, crea espacios de trabajo separados con instrucciones personalizadas que contengan:

  • Nombre del cliente e industria
  • Tamaño y estructura de la empresa
  • Pila tecnológica
  • Marcos de trabajo y plazos de auditoría
  • Prioridades o restricciones específicas

Ejemplo de instrucción:

"Cliente: Acme Corp, fintech de 120 personas, con sede en la UE. Tecnología: Azure, GitHub, Salesforce, Okta. Implementando ISO 27001:2022 y preparándose para una auditoría de GDPR. Prioridad: victorias rápidas para la certificación en 6 meses, énfasis en residencia de datos y cifrado. Presupuesto: $25k para herramientas."

Todas las consultas en ese espacio de trabajo aplican automáticamente este contexto sin repetición.

Aprende sobre Espacios de Trabajo

Contexto para Diferentes Tipos de Consultas

Generación de Políticas

Proporciona: roles, herramientas, frecuencias de revisión, flujos de aprobación

Ejemplo: "Redactar una política de respuesta a incidentes para ISO 27001 A.5.24. Roles: Líder de Seguridad (Jane), CTO (aprobación), Equipo de Ingeniería (respuesta). Herramientas: PagerDuty para alertas, Jira para seguimiento, Slack para comunicaciones. Revisiones post-incidente dentro de las 48 horas."

Análisis de Brechas

Proporciona: estado actual, marco objetivo, debilidades conocidas

Ejemplo: "Analizar nuestra postura de seguridad actual frente a SOC 2 CC6-CC8. Tenemos MFA vía Okta, revisiones trimestrales de acceso, protección de ramas en GitHub y AWS CloudTrail. Falta: documentación formal de gestión de cambios, evaluaciones de riesgo de proveedores y pruebas de DRP."

Preparación de Evidencia

Proporciona: alcance de la auditoría, capacidades de recolección de evidencia, herramientas con registro

Ejemplo: "¿Qué evidencia necesito para ISO 27001 A.8.15 (registro y monitoreo)? Tenemos AWS CloudTrail, Datadog APM y registros del sistema de Okta. Alcance de la auditoría: entorno de producción de AWS y SSO corporativo."

Orientación para Implementación

Proporciona: habilidades del equipo, plazo, herramientas existentes

Ejemplo: "¿Cómo implemento el cifrado en reposo para ISO 27001 A.8.24? Nuestro ingeniero de DevOps tiene experiencia en AWS, usamos RDS PostgreSQL y S3 para almacenamiento de archivos, y necesitamos completar la implementación en 4 semanas."

Evita incluir datos sensibles reales (nombres de clientes, contraseñas reales, PII) en las consultas. Usa marcadores de posición como "[base de datos de clientes]" o "[procesador de pagos]" y activa la reducción de PII si discutes escenarios de manejo de datos.

Cuándo Actualizar el Contexto

Actualiza el contexto cuando tu organización cambie:

  • Crecimiento o reducción significativa de personal
  • Adopción de nueva tecnología (ej. migración a Kubernetes)
  • Cambios regulatorios (ej. nuevos requisitos de GDPR)
  • Hallazgos post-auditoría que requieren remediación
  • Transición de la fase de implementación a mantenimiento

Actualiza las instrucciones personalizadas del espacio de trabajo en lugar de editar consultas anteriores.

Probar tu Contexto

Antes de enviar una consulta, verifica que hayas incluido:

  1. Tamaño de la empresa y estructura del equipo
  2. Industria y regulaciones relevantes
  3. Tecnologías y herramientas clave
  4. Estado actual y objetivos
  5. Cualquier restricción o prioridad

Si una categoría aplica a tu consulta, inclúyela.

Las consultas bien contextualizadas producen resultados listos para auditoría en el primer intento. Las consultas genéricas requieren múltiples rondas de refinamiento, consumiendo cuota de mensajes y tiempo.

Próximos Pasos

Añade contexto organizacional a tu próxima consulta. Compara la calidad y especificidad de la respuesta con intentos genéricos anteriores.

Volver a Resumen de Ingeniería de Prompts

On this page