De la lista de requisitos al framework
Al principio suele haber un documento: una política de grupo, un anexo de seguridad al contrato con un cliente o un cuestionario que un cliente envía cada año. Ese documento se convierte en un framework propio trasladando cada requisito a un control.
Ha demostrado su eficacia registrar un requisito por control. Si un párrafo contiene varias obligaciones, por ejemplo sobre cifrado, registro de eventos y conservación, divídalo. Solo así podrá mostrar más adelante un estado y una evidencia propios para cada obligación. Use la numeración de la fuente como identificador. Así usted y su cliente hablan del mismo requisito.
Formule cada control como una pregunta verificable. La obligación de garantizar una seguridad adecuada se convierte, por ejemplo, en la pregunta de si los datos de los clientes se cifran en la transmisión. Aclare con el cliente los requisitos poco claros antes de responderlos.
Si la lista de requisitos ya existe como hoja de cálculo, no tiene que volver a teclearla. Sightadel admite la importación desde archivos de Excel y Word. Después, revise uno a uno los puntos importados en cuanto a división y formulación.
Reutilizar el trabajo existente
La mayor ventaja de un framework propio surge de los vínculos. Muchos requisitos de clientes exigen cosas que ya implanta para ISO 27001, NIS2 o el RGPD: control de acceso, copias de seguridad, formación, gestión de incidentes, encargo del tratamiento. Las pruebas ya están en la biblioteca de evidencias.
Por eso, repase primero el framework propio pensando en lo que ya existe. Si un requisito está respaldado por una evidencia, vincúlela. La evidencia se mantiene en un único lugar y, si caduca, lo verá en todos los frameworks a la vez.
Compruebe con atención si la evidencia cumple realmente el requisito del cliente. Los clientes suelen formular de manera más estricta o más concreta que una norma. Si un contrato exige, por ejemplo, un plazo determinado para informar al cliente de los incidentes, no basta un proceso general de gestión de incidentes. En ese caso, complete el proceso y la evidencia.
Lo que queda abierto después son las carencias reales. Respóndalas con honestidad en la evaluación y cree planes de acción. Así obtiene una imagen clara de lo que debe hacer adicionalmente para ese cliente.
Los frameworks propios ante clientes y auditores
Un framework propio no es una norma con la que se certifique. Es una herramienta de trabajo con la que muestra a clientes, a la matriz del grupo o a su propia dirección hasta qué punto cumple determinados requisitos.
Si un cliente pregunta, le muestra el estado, la respuesta y la prueba de cada uno de sus requisitos. Para una auditoría de proveedores realizada por el cliente es una buena preparación, porque la estructura sigue su propia lista. Antes de compartir pruebas, compruebe si contienen información confidencial.
También en la auditoría de certificación puede tener un papel un framework propio. ISO 27001 exige, por ejemplo, tener en cuenta los requisitos de las partes interesadas, y entre ellos están los requisitos contractuales de los clientes. Con el rol «Auditor externo», el auditor ve y comenta los contenidos, también los frameworks propios.
Lo mismo se aplica a los catálogos de verificación internos, por ejemplo una autoevaluación anual de las sedes. Usted crea la evaluación con persona responsable y fecha de vencimiento, los participantes responden los controles y el progreso es visible en un solo lugar.
Errores habituales al crearlos
El error más frecuente es crear un framework propio para algo que ya existe. Antes de crearlo, consulte la lista de frameworks estándar. Sightadel incluye ISO 27001, ISO 9001, ISO 42001, NIS2, RGPD, BSI C5, DORA, NIST CSF 2.0, SOC 2, HACCP, el § 390 SGB V (Código Social alemán, libro V) y el Reglamento de IA de la UE (AI Act).
Un segundo error es una estructura demasiado general. Un control que agrupa cinco obligaciones solo puede responderse en bloque. Una parte se cumple y otra no, y la respuesta se vuelve imprecisa. Es mejor dividirlo.
En tercer lugar, a menudo falta el mantenimiento. Los requisitos de los clientes cambian con cada contrato nuevo, y los del grupo, con cada nueva versión. Determine quién mantiene actualizado el framework y deje constancia de en qué versión de la fuente se basa.
En cuarto lugar, no siempre tiene sentido un framework propio para cada cliente. Si los requisitos de varios clientes se parecen mucho, un framework común con los requisitos más estrictos de cada uno puede resultar más claro. Además, el número de frameworks propios depende de su edición.
