Plantilla de Analisis de Brechas de Cumplimiento

Descripcion General

Un Analisis de Brechas de Cumplimiento compara tus controles de seguridad actuales contra los requisitos de un marco objetivo, como SOC 2, ISO 27001, PCI-DSS o GDPR. Esta plantilla captura el requisito, el control que lo satisface, la evidencia disponible, cualquier pieza faltante y un plan para cerrar las brechas. Es un insumo estandar para la preparacion de auditorias y hojas de ruta de certificacion.

Cuando Usar

• For alternatives, see Access Control Review Template.

• Prepararse para una auditoria o certificacion inicial.

• Renovar una certificacion e identificar cambios desde la ultima auditoria.

• Fusionar empresas o integrar nuevas unidades de negocio.

• Despues de un cambio importante en arquitectura, procesos o proveedores.

• Construir una hoja de ruta de seguridad vinculada a obligaciones de cumplimiento.

Prerequisitos

• El marco objetivo y version, como SOC 2 Trust Services Criteria 2017.
• Un inventario de politicas, controles y procesos de seguridad.
• Acceso a repositorios de evidencia, sistemas de tickets y consolas cloud.
• Un equipo multifuncional de seguridad, ingenieria, legal y RRHH.

Solucion

Plantilla

1. Vision General del Compromiso

Campo	Descripcion	Valor
Marco	Estandar de cumplimiento objetivo	SOC 2 Tipo II
Version	Version o criterios especificos	Trust Services Criteria 2017
Alcance	Sistemas, equipos o ubicaciones cubiertas	Ambiente cloud de produccion
Fecha de evaluacion	Cuando se realizo el analisis	2026-06-27
Dueno	Persona responsable del analisis	Gerente de cumplimiento
Fecha objetivo de auditoria	Certificacion o auditoria planeada	2027-03-31

2. Mapeo de Controles

ID Requisito	Objetivo de Control	Control Actual	Evidencia	Estado	Brecha	Dueno	Fecha Limite
CC6.1	Acceso logico	Politica RBAC aplicada	Doc de politica RBAC, config IAM	Parcial	MFA no aplicada a todos los roles admin	Equipo IAM	2026-08-15
CC6.6	Monitoreo de sistemas	Logs centralizados en SIEM	Dashboard SIEM, politica de retencion	Cumple	Ninguna	Equipo de seguridad	N/A
CC7.1	Gestion de vulnerabilidades	Escaneos trimestrales	Reporte del escaner	Parcial	Sin SLA de remediacion	Equipo de gestion de vulnerabilidades	2026-09-01
A.12.3.1	Respaldo de informacion	Politica de backup existe	Politica de backup, prueba de restauracion	Cumple	Ninguna	Equipo DevOps	N/A
A.9.2.3	Derechos de acceso	Proceso de revision de acceso	Revisiones trimestrales de acceso	Parcial	Revisiones no documentadas	Gerentes de ingenieria	2026-07-30

3. Resumen de Brechas

Categoria	Total	Cumple	Parcial	No Cumple	Riesgo
Control de acceso	12	7	4	1	Alto
Monitoreo	8	6	2	0	Medio
Gestion de cambios	6	3	2	1	Alto
Gestion de proveedores	5	2	2	1	Medio
Respuesta a incidentes	7	5	1	1	Alto
Total	38	23	11	4	Alto

4. Plan de Remediacion

ID Brecha	Descripcion	Accion	Dueno	Fecha Limite	Prioridad	Evidencia Requerida
GAP-01	MFA faltante para roles admin	Aplicar MFA en todas las cuentas privilegiadas	Equipo IAM	2026-08-15	Alta	Reporte de inscripcion MFA
GAP-02	Sin SLA de remediacion de vulnerabilidades	Definir y aprobar SLA por severidad	Equipo de seguridad	2026-09-01	Alta	Documento de SLA
GAP-03	Revisiones de acceso no documentadas	Usar plantilla de revision de acceso trimestral	Gerentes de ingenieria	2026-07-30	Media	Atestaciones firmadas
GAP-04	Sin evaluacion formal de proveedores	Adoptar plantilla de evaluacion de proveedores	Compras	2026-10-01	Media	Evaluaciones completadas

5. Seguimiento de Evidencia

ID Requisito	Ubicacion de Evidencia	Ultima Actualizacion	Revisor	Notas
CC6.1	/policies/rbac-policy	2026-06-01	Lider de seguridad	Aprobado y publicado
CC6.6	/siem/retention-config	2026-05-15	Analista SOC	Retencion de 12 meses confirmada
A.12.3.1	/runbooks/backup-restore-test	2026-06-20	Lider DevOps	Prueba trimestral de restauracion exitosa

Explicacion

El analisis de brechas convierte el cumplimiento en un proyecto útil. Al mapear cada requisito a un control, evidencia y estado, puedes priorizar el trabajo basado en riesgo y cronograma de auditoria. El plan de remediacion se convierte en la hoja de ruta que impulsa las tareas de ingenieria, seguridad y legal hacia la certificacion.

Variantes

• Evaluacion de preparacion SOC 2: Enfocada en Trust Services Criteria con controles y evidencia comunes.
• Analisis de brechas ISO 27001: Mapeado a controles del Anexo A y planes de tratamiento de riesgo.
• Analisis de brechas PCI-DSS: Centrado en el entorno de datos de tarjetahabientes, cifrado y acceso.
• Mapeo de cumplimiento GDPR: Rastrea derechos de los titulares de datos, registros de procesamiento y consentimiento.
• Mapeo multi-marco: Una matriz unificada mostrando cobertura entre SOC 2, ISO 27001 y PCI-DSS.

Lo que funciona

• Usa la version oficial del marco para evitar requisitos obsoletos.
• Involucra a los duenos de los controles, no solo al equipo de cumplimiento, en la evaluacion.
• Recolecta evidencia durante el analisis, no despues.
• Califica las brechas por riesgo y preparacion para auditoria, no solo por volumen.
• Rastrea la remediacion como un proyecto con duenos, fechas y entregables.
• Vuelve a ejecutar el analisis trimestralmente o despues de cambios mayores.
• Manten una fuente unica de verdad para ubicaciones de evidencia.

Errores Comunes

• Tratar el cumplimiento como un proyecto de una sola vez en lugar de un programa continuo.
• Mapear controles a requisitos sin revisar la evidencia real.
• Asignar remediacion a equipos sin capacidad o autoridad.
• Usar versiones obsoletas de marcos.
• Sobre-documentar controles triviales mientras se omiten brechas criticas.
• No vincular el analisis de brechas con historial de incidentes o evaluaciones de riesgo.

Soluciones Avanzadas

Recoleccion automatizada de evidencia con AWS Config

Automatiza la recoleccion de evidencia para SOC 2 e ISO 27001 usando AWS Config rules:

#!/bin/bash
set -euo pipefail

# Export AWS Config compliance data for audit evidence
aws configservice select-aggregate-resource-config \
  --configuration-aggregator-name "OrganizationConfigAggregator" \
  --expression '
    SELECT
      resourceId,
      resourceType,
      configurationItemStatus,
      configuration,
      tags
    WHERE
      resourceType = "AWS::Config::ConfigRule"
      AND configurationItemStatus = "OK"
  ' \
  --limit 100 > config-compliance-evidence.json

# Generate MFA enforcement evidence for CC6.1
aws iam get-account-summary > iam-account-summary.json
aws iam list-virtual-mfa-devices > mfa-devices.json

# Check root account MFA status
ROOT_MFA=$(aws iam get-account-summary --query 'SummaryMap.AccountMFAEnabled' --output text)
echo "Root MFA enabled: $ROOT_MFA" >> mfa-evidence.txt

# Generate S3 bucket encryption evidence for CC6.7
aws s3api list-buckets --query 'Buckets[].Name' --output text | \
  tr '\t' '\n' | \
  while read bucket; do
    ENC=$(aws s3api get-bucket-encryption --bucket "$bucket" --query 'ServerSideEncryptionConfiguration.Rules[0].ApplyServerSideEncryptionByDefault.SSEAlgorithm' --output text 2>/dev/null || echo "None")
    echo "$bucket: $ENC" >> s3-encryption-evidence.txt
  done

# Generate CloudTrail logging evidence for CC7.2
aws cloudtrail describe-trails --query 'trailList[].{Name:Name,IsLogging:IsLogging,S3Bucket:S3BucketName}' --output table > cloudtrail-evidence.txt

Matriz de mapeo de controles multi-marco

Crea un mapeo unificado entre SOC 2, ISO 27001 y PCI-DSS para evitar trabajo duplicado:

import json
from pathlib import Path

FRAMEWORK_MAPPING = {
    "MFA enforcement": {
        "soc2": "CC6.1",
        "iso27001": "A.9.4.2",
        "pci": "8.3.1",
        "control": "Multi-factor authentication for all privileged accounts",
        "evidence": ["IAM MFA config", "Enrollment report", "Root MFA status"],
    },
    "Encryption at rest": {
        "soc2": "CC6.7",
        "iso27001": "A.10.1.1",
        "pci": "3.4",
        "control": "AES-256 encryption for all data stores",
        "evidence": ["KMS key policy", "S3 encryption config", "RDS encryption status"],
    },
    "Centralized logging": {
        "soc2": "CC7.2",
        "iso27001": "A.12.4.1",
        "pci": "10.1",
        "control": "All systems forward logs to centralized SIEM",
        "evidence": ["SIEM ingestion config", "Log source inventory", "Retention policy"],
    },
    "Vulnerability scanning": {
        "soc2": "CC7.1",
        "iso27001": "A.12.6.1",
        "pci": "11.2",
        "control": "Quarterly vulnerability scans with remediation SLA",
        "evidence": ["Scanner reports", "Remediation tickets", "SLA document"],
    },
    "Access reviews": {
        "soc2": "CC6.3",
        "iso27001": "A.9.2.5",
        "pci": "8.2.4",
        "control": "Quarterly access reviews with documented attestation",
        "evidence": ["Review records", "Manager sign-off", "Removal tickets"],
    },
}

def generate_mapping_report(mapping: dict) -> str:
    lines = []
    lines.append("| Control | SOC 2 | ISO 27001 | PCI-DSS | Evidence |")
    lines.append("|---------|-------|-----------|---------|----------|")
    for name, data in mapping.items():
        evidence = ", ".join(data["evidence"])
        lines.append(
            f"| {name} | {data['soc2']} | {data['iso27001']} | "
            f"{data['pci']} | {evidence} |"
        )
    return "\n".join(lines)

report = generate_mapping_report(FRAMEWORK_MAPPING)
Path("multi-framework-mapping.md").write_text(report)
print(report)

Monitoreo continuo de cumplimiento con OPA

Usa Open Policy Agent (OPA) para verificar continuamente controles de cumplimiento en Kubernetes:

# OPA Gatekeeper policy: Enforce MFA-required labels on all deployments
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        openAPIV3Schema:
          type: object
          properties:
            labels:
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels

        violation[{"msg": msg, "details": {"missing_labels": missing}}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("Missing required labels: %v", [missing])
        }
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: require-compliance-labels
spec:
  match:
    kinds:
      - apiGroups: ["apps"]
        kinds: ["Deployment"]
  parameters:
    labels: ["compliance-scan", "data-classification", "owner-team"]

Mejores Practicas Adicionales

1. Usa un enfoque de compliance-as-code. Define controles como codigo (politicas OPA, AWS Config rules, politicas Sentinel de Terraform) para que el cumplimiento se verifique continuamente, no solo se evalue anualmente:

# Sentinel policy for Terraform: Enforce encryption on all S3 buckets
import "tfplan"

main = rule when tfplan.resource_changes is not empty {
  all tfplan.resource_changes as _, rc {
    rc.type is "aws_s3_bucket" implies
    rc.change.after.server_side_encryption_configuration is not null
  }
}

2. Manten un repositorio de evidencia vivo. Almacena toda la evidencia en un repositorio versionado con actualizaciones automatizadas. Esto elimina la recoleccion de evidencia de ultimo momento antes de auditorias:

#!/bin/bash
set -euo pipefail

EVIDENCE_DIR="compliance-evidence/$(date +%Y-%m)"
mkdir -p "$EVIDENCE_DIR"

# Auto-collect monthly evidence snapshots
aws configservice get-discovery-summary > "$EVIDENCE_DIR/config-summary.json"
kubectl get compliance-scores -A -o json > "$EVIDENCE_DIR/k8s-compliance.json"
npm audit --json > "$EVIDENCE_DIR/npm-audit.json"
trivy image --format json myapp:latest > "$EVIDENCE_DIR/trivy-scan.json"

git add "$EVIDENCE_DIR"
git commit -m "compliance: monthly evidence snapshot $(date +%Y-%m)"