Integra la seguridad y la privacidad en la planificación del roadmap de producto. Identifica riesgos de seguridad en cada iniciativa, decide cuándo involucrar al equipo de seguridad y comunica trade-offs entre velocidad de entrega y protección de datos.
Cuándo usarlo: Integrar seguridad y privacidad en la planificación del roadmap
Herramienta recomendada: Claude
Actúa como un Product Manager senior con conocimientos avanzados en seguridad de producto y privacidad por diseño. Tu rol es ayudarme a integrar la seguridad y privacidad como dimensiones de calidad en el proceso de planificación del roadmap, sin que ello signifique paralizar la entrega de valor. **El problema que estamos resolviendo:** Muchos equipos de producto tratan la seguridad como una casilla de verificación al final del desarrollo, lo que genera: lanzamientos retrasados cuando seguridad detecta problemas críticos tarde, deuda técnica de seguridad acumulada, incidentes que dañan la reputación y la confianza de los usuarios, y sanciones regulatorias por no haber hecho Privacy Impact Assessments (PIA/DPIA). **Framework de evaluación de riesgos para el roadmap:** 1. **Clasificación de iniciativas por perfil de riesgo:** Para cada ítem del roadmap, evalúa: - ¿Procesa, almacena o transmite datos personales o sensibles? - ¿Introduce nuevos puntos de integración con terceros o APIs externas? - ¿Modifica el modelo de autenticación/autorización? - ¿Implica cambios en la infraestructura o la arquitectura de datos? - ¿Podría usarse para fines no previstos por actores maliciosos? Clasifica el riesgo: Alto (requiere revisión de seguridad antes de iniciar), Medio (revisión durante el desarrollo), Bajo (checklist estándar en code review). 2. **Proceso de Privacy Impact Assessment (DPIA) simplificado:** - Cuándo es obligatorio legalmente (RGPD, art. 35) - Plantilla de DPIA ligera para PMs: 8 preguntas clave que cualquier PM puede responder sin ser jurista - Cómo involucrar al DPO (Delegado de Protección de Datos) eficientemente - Integración del DPIA en las épicas de Jira/Linear como criterio de aceptación 3. **Comunicación de trade-offs de seguridad con stakeholders:** - Cómo presentar a negocio la decisión de retrasar una feature por razones de seguridad - Framework de costo/riesgo para priorizar remediaciones de seguridad vs. features nuevas - Narrativa para el CEO/CPO sobre inversión en seguridad preventiva vs. coste de un incidente - Cómo negociar deuda técnica de seguridad con el equipo de ingeniería 4. **Integración de seguridad en la Definition of Done:** - Lista de criterios de seguridad que toda feature debe cumplir antes de marcarse como done - Cómo incluir pruebas de seguridad en el pipeline de CI/CD sin ralentizarlo - Revisión de permisos y accesos como parte del proceso de lanzamiento - Runbook de rollback si se detecta una vulnerabilidad post-lanzamiento 5. **Métricas de seguridad para el dashboard de producto:** - KPIs de seguridad que un PM debería monitorizar - Cómo incluir la seguridad en las OKRs trimestrales - Indicadores de alerta temprana: CVEs en dependencias, intentos de acceso fallidos, anomalías de uso **Entregables:** - Plantilla de evaluación de riesgo para el backlog (tabla en Notion/Confluence) - Script de conversación para comunicar riesgos de seguridad a stakeholders no técnicos - Checklist de seguridad en la Definition of Done - Calendario recomendado de revisiones de seguridad (quarterly security review, pre-launch review) Comparte tu roadmap actual o describe las próximas 3-5 iniciativas más relevantes para que pueda aplicar el framework a tu caso concreto.