Tema
POL-001: Política de Seguridad de Información
| Campo | Valor |
|---|---|
| ID | POL-001 |
| Versión | 1.0 |
| Clasificación | Interno — Confidencial |
| Fecha de Emisión | 2026-03-13 |
| Fecha de Revisión | 2026-03-13 |
| Próxima Revisión | 2027-03-13 |
| Propietario | CISO / Director de Seguridad de Información |
| Aprobado por | Gerencia Ejecutiva — Fintrixs SAS |
| Aplica a | Todo el personal, contratistas, proveedores y socios comerciales |
1. Propósito
Establecer el marco de gobernanza de seguridad de información de Fintrixs SAS ("Fintrixs") para proteger la confidencialidad, integridad y disponibilidad de los activos de información, incluyendo datos de tarjetahabientes (CHD) según PCI DSS v4.0.
2. Alcance
Esta política aplica a:
- Todos los empleados, contratistas y terceros que accedan a sistemas de información de Fintrixs
- Todos los sistemas que almacenan, procesan o transmiten datos de cuentas de pago
- Infraestructura cloud (DigitalOcean), Kubernetes (DOKS), bases de datos, APIs y microservicios
- Entornos de desarrollo, staging y producción
- Dispositivos propiedad de la empresa y dispositivos personales usados para trabajo (BYOD)
3. Marco Regulatorio
Esta política se alinea con:
| Estándar/Regulación | Aplicabilidad |
|---|---|
| PCI DSS v4.0 | Requisitos 1-12 |
| ISO 27001:2022 | Controles Anexo A |
| NIST Cybersecurity Framework | Identify, Protect, Detect, Respond, Recover |
| Ley 1581 de 2012 (Colombia) | Protección de datos personales |
| Circular Externa 007/2018 SFC | Ciberseguridad sector financiero |
4. Principios de Seguridad
4.1 Defensa en Profundidad
Múltiples capas de controles de seguridad protegen los activos de información:
- Perímetro (WAF, Firewall, Kong Gateway)
- Red (Network Policies, VPC segmentation)
- Aplicación (Input validation, Auth/AuthZ)
- Datos (Cifrado at-rest y in-transit, tokenización)
4.2 Mínimo Privilegio
Cada usuario, servicio y sistema recibe únicamente los permisos necesarios para realizar su función.
4.3 Zero Trust
No se confía implícitamente en ninguna entidad, interna o externa. Toda solicitud es autenticada y autorizada.
4.4 Separación de Deberes
Las funciones críticas requieren la participación de más de una persona para completarse.
4.5 Need-to-Know
El acceso a información sensible se otorga únicamente cuando existe una necesidad comercial demostrable.
5. Estructura Organizacional de Seguridad
5.1 Roles y Responsabilidades
| Rol | Responsabilidad | Persona/Equipo |
|---|---|---|
| Gerencia Ejecutiva | Aprobación de políticas, asignación de recursos, responsabilidad final | CEO / CTO |
| CISO / Oficial de Seguridad | Gestión del programa de SI, cumplimiento PCI DSS, reporte a gerencia | Designado por Gerencia |
| DevOps / Infraestructura | Seguridad de infraestructura, firewalls, K8s, monitoreo | Equipo DevOps |
| Desarrollo | Codificación segura, revisión de código, pruebas de seguridad | Equipo de Desarrollo |
| QA / Testing | Pruebas de seguridad, validación de controles | Equipo QA |
| RRHH | Verificación de antecedentes, entrenamiento, onboarding/offboarding | Recursos Humanos |
| Todo el personal | Cumplimiento de políticas, reporte de incidentes, awareness | Todos |
5.2 Responsabilidad de Cumplimiento PCI DSS
El programa de cumplimiento PCI DSS es responsabilidad del CISO/Oficial de Seguridad, quien reporta trimestralmente a la Gerencia Ejecutiva sobre:
- Estado de cumplimiento de cada requisito
- Resultados de revisiones de logs diarias
- Configuración de controles de seguridad de red
- Aplicación de estándares a nuevos sistemas
- Respuesta a alertas de seguridad
- Proceso de gestión de cambios
6. Políticas Subordinadas
Esta política es soportada por las siguientes políticas específicas:
| ID | Política | Referencia PCI DSS |
|---|---|---|
| POL-002 | Controles de Seguridad de Red | Req 1 |
| POL-003 | Acceso Lógico y Autenticación | Req 7, 8 |
| POL-004 | Estándares de Cifrado | Req 3, 4 |
| POL-005 | SDLC y Gestión de Cambios | Req 6 |
| POL-006 | Gestión de Vulnerabilidades y Parches | Req 6, 11 |
| POL-007 | Respuesta a Incidentes | Req 12.10 |
| POL-008 | Gestión de Terceros | Req 12.8 |
| POL-009 | Seguridad Física | Req 9 |
| POL-010 | Logging y Monitoreo | Req 10 |
| POL-011 | Backup y Recuperación | Req 12 |
| POL-012 | Clasificación y Protección de Datos | Req 3 |
| POL-013 | Uso Aceptable de Tecnología | Req 12 |
| POL-014 | Hardening de Sistemas | Req 2 |
| POL-015 | Anti-Malware | Req 5 |
7. Gestión de Riesgos
7.1 Evaluación de Riesgos
- Se realiza una evaluación formal de riesgos al menos anualmente y ante cambios significativos
- Metodología: NIST Risk Management Framework (RMF)
- Resultados documentados en el Registro de Riesgos
- Revisión trimestral del Registro de Riesgos
7.2 Análisis de Riesgo Dirigido (Targeted Risk Analysis)
- Se realiza un TRA para cada requisito de PCI DSS que permita flexibilidad en frecuencia
- Se realiza un TRA para cada requisito cumplido con el enfoque personalizado
- Documentado en
docs/security/procedures/TRA-001-TARGETED_RISK_ANALYSIS.md
8. Conciencia y Entrenamiento de Seguridad
- Nuevas contrataciones: Entrenamiento de seguridad en onboarding (primera semana)
- Todo el personal: Entrenamiento anual de conciencia de seguridad
- Desarrolladores: Entrenamiento anual de codificación segura
- Equipo de IR: Entrenamiento anual de manejo de incidentes
- Reconocimiento: Todo el personal firma reconocimiento anual de esta política
- Temas cubiertos: Phishing, ingeniería social, manejo de datos sensibles, uso aceptable, reporte de incidentes
9. Gestión de Incidentes de Seguridad
- Todo incidente de seguridad debe ser reportado inmediatamente al Oficial de Seguridad
- Se mantiene un equipo de respuesta a incidentes disponible 24/7
- El Plan de Respuesta a Incidentes (POL-007) detalla los procedimientos completos
- Los incidentes que involucren datos de tarjetas requieren notificación a las marcas de tarjetas y al adquirente
10. Cumplimiento y Sanciones
10.1 Monitoreo de Cumplimiento
- Revisiones periódicas de cumplimiento de esta política y sus subordinadas
- Auditorías internas semestrales
- Evaluación anual PCI DSS por QSA autorizado
10.2 Violaciones
El incumplimiento de esta política puede resultar en:
- Acción disciplinaria hasta e incluyendo terminación
- Revocación de acceso a sistemas
- Acciones legales según la severidad
11. Notificación de Brecha
En caso de una brecha de seguridad que involucre datos de tarjetas de pago:
- Contener el incidente inmediatamente
- Notificar al Oficial de Seguridad y Gerencia Ejecutiva
- Seguir el procedimiento de Respuesta a Incidentes (POL-007)
- Notificar a las marcas de tarjetas y adquirente dentro de 24 horas
- Preservar evidencia forense
- Contactar investigador forense PCI certificado (PFI) si es necesario
12. Revisión y Actualización
- Esta política se revisa al menos anualmente o ante cambios significativos
- Los cambios significativos incluyen: fusiones, adquisiciones, cambios de infraestructura, nuevos servicios de pago, incidentes de seguridad
- Toda revisión es aprobada por Gerencia Ejecutiva
- La versión actualizada se comunica a todo el personal dentro de 5 días hábiles
13. Distribución
Esta política se distribuye a:
- Todo el personal empleado (email corporativo + intranet)
- Contratistas y consultores (previo a inicio de trabajo)
- Proveedores de servicios relevantes (como anexo a contratos)
Historial de Revisiones
| Versión | Fecha | Autor | Cambios |
|---|---|---|---|
| 1.0 | 2026-03-13 | Oficial de Seguridad | Documento inicial |
Aprobación
| Rol | Nombre | Firma | Fecha |
|---|---|---|---|
| Gerencia Ejecutiva | _________________ | _________________ | //____ |
| CISO / Oficial de Seguridad | _________________ | _________________ | //____ |