Para comenzar a crear tu plantilla de plan de seguridad del sistema para CMMC, primero debes determinar qué nivel de cumplimiento debe alcanzar tu organización, según el tipo de datos que manejes. El cumplimiento de nivel 1 aplica a las organizaciones que procesan información de contratos federales (FCI). Este nivel requiere una autoevaluación anual y una afirmación formal de que la organización implementó 17 prácticas de seguridad básicas. 

El nivel 2 es el estándar para la gran mayoría de la base industrial de defensa (DIB), ya que aplica a cualquier contratista que maneje información no clasificada controlada (CUI). Este nivel se alinea con los 110 requisitos de seguridad de NIST SP 800-171. Los SSP de nivel 2 son considerablemente más detallados, ya que son la base de una evaluación trienal realizada por una organización evaluadora externa de CMMC (C3PAO). (En ciertos casos no prioritarios, se permite una autoevaluación rigurosa).

El nivel 3 está reservado para los programas más sensibles. Además de los 110 requisitos del nivel 2, los contratistas deben implementar 24 requisitos seleccionados de NIST SP 800-172. Estas evaluaciones las realiza directamente el Centro de Evaluación de Ciberseguridad de la Base Industrial de Defensa (DIBCAC).

Límites del sistema y activos dentro del alcance

El paso más crítico al desarrollar un SSP para CMMC es definir el alcance de la evaluación. Los límites mal definidos pueden provocar que la auditoría falle y generar sobrecostos importantes. Para evitarlo, categoriza todos los activos según su relación con la CUI.

• Activos de CUI: sistemas, dispositivos y aplicaciones que almacenan, procesan o transmiten CUI (por ejemplo, servidores que alojan datos de proyectos, laptops de empleados que acceden a repositorios de CUI). 

• Activos de protección de seguridad: activos que brindan funciones de seguridad al entorno de CUI, aunque no contengan CUI en sí (por ejemplo, firewalls, sistemas de gestión de eventos e información de seguridad [SIEM]).

• Activos especializados y activos de riesgo gestionados por el contratista (CRMA): según el entorno, las organizaciones también pueden necesitar identificar activos especializados (por ejemplo, OT, IoT, equipo de prueba) y CRMA, los cuales se tratan de manera diferente durante la evaluación pero deben documentarse igualmente.

• Activos fuera del alcance: sistemas que están separados lógica o físicamente del entorno de CUI y que no interactúan con datos sensibles (por ejemplo, nómina de RR. HH., sitios web de marketing).

Documentación de la implementación de controles

El núcleo de un SSP es la descripción detallada de cómo se cumple cada uno de los 110 requisitos de NIST SP 800-171. Aquí es donde muchas organizaciones tropiezan, al dar declaraciones genéricas que no cumplen con el estándar "verificable" de los evaluadores. Una descripción completa responde a las "preguntas del reportero": quién, qué, cuándo y cómo (el dónde queda implícito).

• Quién: el rol o la parte específica responsable de la acción.

• Qué: la acción o el comportamiento de seguridad específico que se realiza.

• Cuándo: la frecuencia o el detonante de la acción.

• Cómo: las herramientas, configuraciones o tecnologías específicas que se usan.

Cada descripción de implementación de control debe vincularse a los 320 objetivos de evaluación descritos en el documento complementario NIST SP 800-171A. Los mejores ejemplos de SSP para CMMC conectan explícitamente cómo las herramientas, las políticas y los procesos respaldan los controles, lo que demuestra una estrategia de seguridad coherente.

Los evaluadores no toman tu SSP al pie de la letra: usan la metodología IET (entrevistar, examinar, probar) para verificar la implementación. Cualquier brecha entre la "seguridad en papel" y el comportamiento real puede generar señales de alerta. Otras fallas comunes incluyen lenguaje genérico, información desactualizada, controles heredados sin verificar y parámetros vagos. Discrepancias como estas indican a los evaluadores que el programa de seguridad de una organización es "inmaduro" y que la organización podría no estar tomando en serio sus responsabilidades.

Un plan de seguridad del sistema CMMC sirve como la hoja de ruta del evaluador a través del entorno de seguridad de tu organización. Una guía transparente, minuciosa y confiable genera confianza y agiliza tu camino hacia la certificación.

1. Usa un lenguaje simple y claro

El público del SSP incluye tanto al personal técnico como a auditores no técnicos. Las descripciones deben ser claras y evitar jerga innecesaria. Una buena prueba es el estándar de la "persona razonable": ¿podría alguien sin familiaridad con tu entorno leer el SSP y entender de forma básica cómo proteges la CUI?

2. Actualízalo con regularidad y después de cambios importantes

Revisa tu SSP al menos una vez al año o cada vez que haya un "cambio significativo" en el sistema o las herramientas. Esto podría incluir migrar a una nueva plataforma en la cloud, cambiar de proveedor de seguridad o adquirir una nueva unidad de negocio que maneje CUI.

3. Evita el lenguaje genérico o "idealizado"

No te limites a copiar descripciones de NIST 800-171: tu SSP debe demostrar cómo tu organización cumple específicamente con los requisitos. También debe reflejar tu entorno actual, no lo que planeas lograr dentro de seis meses. Documentar un estado "ideal" que todavía no existe puede acarrear sanciones legales graves.   

4. Vinculación directa con evidencia

Cada descripción de implementación de control debe incluir una referencia al artefacto específico que la comprueba. Por ejemplo: "Los bloqueos de cuenta se aplican mediante Active Directory (ver captura de pantalla: AD_Policy_Lockout.png) y se monitorean mediante Huntress SIEM (ver artefacto: Monthly_Log_Review_Oct2025.pdf)". Esto facilita el trabajo del evaluador y genera credibilidad de inmediato.

5. Colabora entre departamentos

La ciberseguridad no es solo un problema de TI; es un requisito cultural y operativo. Construir un SSP exitoso requiere la participación de TI, RR. HH. (para la seguridad del personal y la incorporación), Legal (para la revisión de contratos) y Operaciones (para la seguridad física y el manejo de CUI). 

Un SSP no es algo que se hace una sola vez. Es un documento vivo que evoluciona junto con el panorama de amenazas y la pila tecnológica de tu organización.

Huntress Managed SIEM centraliza los registros de endpoints e identidades, lo que facilita documentar los registros de auditoría, las prácticas de monitoreo y los flujos de detección de incidentes mencionados en un SSP. 

Las organizaciones que trabajan con Huntress reciben un Plan de Seguridad del Sistema (SSP) Suplementario como parte del paquete de documentación de CMMC de Huntress y el "Kit de Recolección de Evidencia". Está diseñado para ayudar a las organizaciones y a los MSP a prepararse para CMMC Nivel 2 al:

• Dar un lenguaje listo para evaluadores sobre Huntress para tu SSP

• Documentar cómo Huntress se relaciona con los controles de NIST SP 800‑171 / CMMC

• Reducir el tiempo de preparación y mantener la documentación actualizada

• Facilitar las evaluaciones de C3PAO

El SSP Suplementario de Huntress le dice a tu C3PAO: "así es exactamente como funciona Huntress en nuestro entorno, qué controles respalda y por qué sigue siendo un activo de ciberseguridad". Dedica tu tiempo al resto de tu programa CMMC en lugar de escribir y defender el lenguaje del proveedor.

Descubre cómo Huntress puede ayudar a tu organización a mantenerse segura y cumplir con CMMC.