Ingeniería de prompts

Proporcionar contexto organizacional

Por qué es importante el contexto

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 tienen recursos, riesgos y alcances de auditoría enormemente diferentes, incluso cuando buscan 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, stack tecnológico, tamaño del equipo y nivel de madurez.

Elementos de contexto esenciales

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é es importante: 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. Entorno industrial y 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, sujeta a PCI DSS y GDPR"

  • "SaaS B2B que vende a clientes empresariales que requieren SOC 2"

Por qué es importante: La salud prioriza la confidencialidad de los datos de los pacientes; las fintech enfatizan la integridad de las transacciones; el SaaS B2B se enfoca en el aislamiento de los datos de los clientes. Los controles y la evidencia cambian en consecuencia.

3. Stack tecnológico

Enumera tu infraestructura principal, aplicaciones y herramientas de seguridad.

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

Por qué es importante: La guía específica para herramientas supera a las recomendaciones genéricas. En lugar de "implementar el registro de logs", obtendrás "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:

  • "Iniciando 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 de EE. UU."

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

5. Desafíos o limitaciones específicos

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

Ejemplos:

  • "El auditor anterior señaló políticas de contraseñas débiles y falta de MFA"

  • "Equipo remoto primero en 15 países, sin oficina física"

  • "Monolito legado que se está migrando a microservicios en Kubernetes"

  • "Restricción presupuestaria: $10k en total para herramientas de cumplimiento"

Por qué es importante: Las limitaciones dan forma a las soluciones viables. El enfoque remoto primero cambia los controles de seguridad física; los límites presupuestarios afectan la elección de herramientas; los hallazgos de auditoría priorizan la remediación.

Contexto en acción: Antes y Después

Ejemplo 1: Política de control de acceso

❌ Sin contexto: "Genera 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: "Genera una política de control de acceso para SOC 2 CC6 para una empresa SaaS de 50 personas que utiliza Okta SSO, GitHub, AWS y Salesforce. Incluye revisiones de acceso trimestrales 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: Descripción general de la metodología sin detalles de activos ni priorización.

✅ Con contexto: "Crea 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. Prioriza las amenazas relevantes para HIPAA".

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

Ejemplo 3: Hoja de ruta de implementación

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

Resultado: Fases de alto nivel sin alineación de tiempos ni recursos.

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

Resultado: Plan por fases con victorias rápidas (formalización del MFA existente), hitos adecuados a los recursos y tareas específicas de herramientas alineadas con el cronograma y la capacidad del equipo.

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

Organización del contexto con Espacios de Trabajo

Para trabajos 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

  • Stack tecnológico

  • Marcos y cronogramas de auditoría

  • Prioridades o limitaciones 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 la auditoría de GDPR. Prioridad: victorias rápidas para la certificación en 6 meses, énfasis en la 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.

Más información sobre los Espacios de Trabajo

Contexto para diferentes tipos de consultas

Generación de políticas

Proporcionar: roles, herramientas, frecuencias de revisión, flujos de trabajo de aprobación

Ejemplo: "Redacta una política de respuesta a incidentes para ISO 27001 A.5.24. Roles: Responsable de seguridad (Jane), CTO (aprobación), equipo de ingeniería (respuesta). Herramientas: PagerDuty para alertas, Jira para seguimiento, Slack para comunicaciones. Revisiones post-incidente en un plazo de 48 horas".

Análisis de brechas

Proporcionar: estado actual, marco objetivo, debilidades conocidas

Ejemplo: "Analiza nuestra postura de seguridad actual frente a SOC 2 CC6-CC8. Tenemos MFA a través de Okta, revisiones de acceso trimestrales, 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 evidencias

Proporcionar: alcance de la auditoría, capacidades de recolección de evidencias, herramientas con registro de logs

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".

Guía de implementación

Proporcionar: habilidades del equipo, cronograma, 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 el 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 habilita 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 (p. ej., migración a Kubernetes)

  • Cambios regulatorios (p. ej., nuevos requisitos de GDPR)

  • Hallazgos post-auditoría que requieran remediación

  • Cambio de fase de implementación a fase de mantenimiento

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

Probando 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 limitación o prioridad

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

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

Próximos pasos

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

Volver a la Descripción General de Ingeniería de Prompts

¿Te fue útil?