Tema
TMPL-007: Plantilla de revisión semestral de cuentas y privilegios
| Campo | Valor |
|---|---|
| ID | TMPL-007 |
| Versión | 1.0 |
| Fecha de emisión | 2026-06-16 |
| Propietario | CISO + CTO (joint review) |
| PCI DSS | Req 7.2.4 — "All user accounts and related access privileges are reviewed at least once every six months to ensure user accounts and access remain appropriate based on job function, and any inappropriate access is addressed" |
| Cadencia | Semestral (H1: junio · H2: diciembre) |
1. Propósito
Esta plantilla normaliza la revisión semestral obligatoria por PCI DSS v4.0 Req 7.2.4. Cada ciclo (junio y diciembre) el CISO y el CTO completan todas las secciones de este formulario, lo firman, y archivan el resultado en docs/pci-dss/access-reviews/YYYY-HX-review.md.
2. Cuándo se ejecuta
| Ciclo | Ventana | Deadline absoluto |
|---|---|---|
| H1 del año (semestre 1) | 1 – 30 junio | 30 junio 23:59 UTC |
| H2 del año (semestre 2) | 1 – 31 diciembre | 31 diciembre 23:59 UTC |
Un calendar reminder automático se dispara el 1 de junio y el 1 de diciembre de cada año (Google Calendar del CTO + email a CISO).
3. Quién participa
| Rol | Responsabilidad |
|---|---|
| CTO | Proponente: extrae los listados de cada plataforma y propone decisión por usuario |
| CISO | Revisor: valida la decisión, verifica que la justificación de negocio sigue vigente |
| HR | Provee bajas/cambios de rol del semestre |
| Auditor externo (opcional) | En años pares (2026, 2028), un auditor independiente valida la revisión |
4. Plataformas en alcance (PCI)
Todas las plataformas de la matriz Q233 deben ser revisadas:
| # | Plataforma | Fuente para extraer usuarios |
|---|---|---|
| 1 | DigitalOcean account | doctl account get + DO console team |
| 2 | GitHub Fintrixs-SAS org | gh api repos/.../collaborators |
| 3 | K8s API + RBAC (rbac-sod) | kubectl get serviceaccounts -n rbac-sod |
| 4 | PostgreSQL DBaaS prod | doctl databases user list <prod> |
| 5 | PostgreSQL DBaaS staging | doctl databases user list <staging> |
| 6 | Wazuh OpenSearch internal users | securityadmin.sh -backup |
| 7 | Wazuh manager API users | /security/users API |
| 8 | GoPhish admin console | DB direct query |
| 9 | Dashboard Fintrixs Pay (merchants) | SELECT FROM iam_core.iam_users |
| 10 | Rapid7 + VAPT droplets | ControlCase SOW (vendor confirmation) |
| 11 | Linux OS local accounts (collector) | cat /etc/passwd; getent shadow |
| 12 | Kong API gateway | N/A (no RBAC; access via IP allowlist only) |
5. Formulario
5.1 Header del informe
Cycle: H1 2026 / H2 2026 / H1 2027 / ...
Review period: YYYY-MM-DD a YYYY-MM-DD
Proposing CTO: Nombre completo + email
Reviewing CISO: Nombre completo + email
Auditor (si aplica): Nombre + firma digital
HR confirmation: Fecha de la lista de bajas5.2 Por cada plataforma, completar la tabla:
| Usuario | Rol/Permisos | Última actividad | Decisión | Justificación |
|---|---|---|---|---|
| (string) | (string) | (date) | KEEP / DOWNGRADE / DISABLE / REMOVE | (free text — min 20 chars) |
Códigos de decisión:
| Código | Significado | Acción técnica |
|---|---|---|
KEEP | Acceso sigue siendo apropiado | Ninguna |
DOWNGRADE | Acceso debe reducirse a un rol menor | kubectl/gh/sql UPDATE role |
DISABLE | Suspender pero mantener cuenta (retención) | is_enabled = false |
REMOVE | Eliminar la cuenta completamente | DELETE / gh remove collaborator / etc. |
EXEMPT | Mantener con justificación explícita (proveedor, QSA temp) | Documentar fecha de re-revisión |
5.3 Sumario de acciones tomadas
Total cuentas revisadas: ___
KEEP: ___
DOWNGRADE: ___
DISABLE: ___
REMOVE: ___
EXEMPT: ___
Tickets generados: ___
Ejecución de acciones: Completada el YYYY-MM-DD5.4 Acuse de recibo del CTO
Yo, [CTO nombre completo], CTO de Fintrixs SAS, confirmo que:
1. He revisado personalmente cada una de las ___ cuentas listadas en este informe.
2. He validado que el acceso de cada usuario sigue siendo apropiado y conforme
a su función actual.
3. He aplicado las decisiones de DOWNGRADE/DISABLE/REMOVE listadas en §5.3.
4. Cualquier excepción (`EXEMPT`) está justificada con motivo de negocio
documentado y fecha de re-revisión.
5. Las cuentas de terceros/proveedores (ControlCase, VAPT) han sido confirmadas
con la organización vendor.
Firma: ________________________________
Fecha: ________________________________
Hash de evidencia (sha256 del archivo final): ___________________________5.5 Acuse de revisión del CISO
Yo, [CISO nombre completo], CISO de Fintrixs SAS, confirmo que:
1. He revisado el informe del CTO y las decisiones tomadas.
2. He verificado en una muestra del 10% (random) que la justificación coincide
con el rol actual del usuario en HR/Slack/Linear.
3. Toda excepción está dentro de la política POL-003 §5.
Firma: ________________________________
Fecha: ________________________________6. Archivo + retención
- Path:
docs/pci-dss/access-reviews/YYYY-HX-review.md - Retención: 7 años (PCI 10.5.1)
- Acceso: read-only en el repo Git; immutable por convención (no git rebase sobre los archivos firmados)
- Backup: copia automática a DO Spaces
fintrix-compliance-archive/cada 24h
7. Reporte al board
Cada ciclo, el CISO genera un slide de 1 página para el board del próximo mes con:
- Total cuentas revisadas
- Counts por categoría (KEEP/DOWNGRADE/DISABLE/REMOVE/EXEMPT)
- Anomalies (e.g. usuario inactivo descubierto)
- Plan de remediación si aplica
8. Vínculo con otros controles
- Q45 — User Account Listings — el snapshot que se revisa
- Q48 — Inactive User Audit — auto-flag de cuentas >90 días sin actividad
- Q39 — Segregation of Duties — matriz de roles + permisos
- POL-003 — Logical Access — política madre
- SOP-005 — MFA Exception Request — proceso de excepciones
- PCI DSS v4.0 Req 7.2.4