Certificación ISO 27001: construya un SGSI que perdure

Un cliente le pide su certificado ISO 27001. El plazo comercial está claro; el trabajo de implantación quizá no tanto. La primera decisión de la dirección es si construir un sistema de gestión de la seguridad que la empresa pueda sostener, o montar un proyecto temporal en torno a la fecha de una auditoría.

Un plan de certificación útil empieza por definir el sistema que necesita operar y, a continuación, organiza las evidencias que lo demuestran. Eso implica decidir qué servicios debe cubrir el certificado, quién puede autorizar decisiones sobre riesgos, qué recursos necesitan los responsables de los controles y cómo sabrá la dirección si los controles funcionan.

El certificado es un entregable importante. El activo empresarial duradero es un sistema de gestión de seguridad de la información, o SGSI, que siga siendo útil cuando se van empleados, cambian los proveedores, se lanzan nuevos productos y los clientes hacen preguntas más exigentes.

Qué acredita realmente la certificación ISO 27001

ISO/IEC 27001 especifica los requisitos para establecer, implementar, mantener y mejorar de forma continua un SGSI. Su finalidad es gestionar los riesgos para la confidencialidad, la integridad y la disponibilidad de la información en el contexto de la organización.

La confidencialidad se refiere a la divulgación indebida, por ejemplo, que registros de clientes queden accesibles para usuarios no autorizados. La integridad se refiere a cambios inexactos o no autorizados, por ejemplo, que alguien altere unas instrucciones de pago. La disponibilidad se refiere al acceso cuando se necesita, por ejemplo, restablecer un servicio importante tras un fallo de infraestructura.

La certificación se refiere a ese sistema de gestión dentro de su alcance declarado. No garantiza que todos los productos estén libres de vulnerabilidades, que no puedan producirse incidentes ni que se hayan evaluado todas las unidades de negocio. Un certificado que cubre un servicio gestionado no debe presentarse como garantía de un producto no relacionado.

ISO e IEC publican la norma; no certifican a su organización. Un organismo de certificación independiente realiza la evaluación y toma la decisión de certificación. Para dar garantías a los clientes, una recomendación práctica es elegir un organismo acreditado para la actividad de certificación de SGSI correspondiente y confirmar que su certificación cumplirá los requisitos de los compradores.

También importa la diferencia entre conformidad y certificación. Una organización puede implantar un SGSI que cumpla la norma sin buscar una certificación externa. La certificación añade una evaluación independiente y un certificado formal. Comprar software, contratar a un implantador cualificado o completar un curso de formación no otorga la certificación a la organización.

Decida si la certificación resuelve el problema de negocio

La certificación es especialmente relevante cuando los requisitos de compra, los compromisos contractuales, la información sensible o las dependencias operativas justifican un aseguramiento independiente. No es una obligación legal universal para todas las empresas.

Antes de comprometerse, pida a los equipos comerciales y de cuentas que identifiquen el requisito real. ¿Exige el comprador un certificado antes de firmar el contrato, antes del acceso a producción o en la renovación? ¿Debe cubrir un servicio o una entidad jurídica concretos? ¿Seguirá exigiendo el comprador un cuestionario de seguridad, informes de pruebas o controles contractuales adicionales?

Estas respuestas condicionan las prioridades de inversión. Un certificado puede facilitar las compras, pero no elimina toda la diligencia debida. Evite prever ingresos partiendo del supuesto de que la certificación completa automáticamente la revisión de seguridad de cada cliente.

Separe la certificación del análisis regulatorio. Un SGSI puede aportar evidencias y gobernanza relevantes para otras obligaciones, pero la certificación no acredita el cumplimiento del RGPD ni de la NIS2. Estos regímenes tienen sus propias reglas de aplicabilidad y sus propias obligaciones. La NIS2 se aplica a través de la legislación nacional; las obligaciones del RGPD dependen de las actividades de tratamiento y de los roles de la organización.

Por tanto, el planteamiento para la dirección debe identificar tres cosas: el aseguramiento que necesitan los clientes, los riesgos de la información que la empresa debe gestionar y el coste operativo continuado. Apruebe el programa sobre esa base, y no sobre la promesa de un certificado en una fecha arbitraria.

Defina un alcance que los clientes puedan entender

El alcance describe los límites y la aplicabilidad del SGSI. Debe identificar los servicios, unidades organizativas, ubicaciones, personas, información, sistemas y dependencias relevantes. También debe tener en cuenta las interfaces con actividades situadas fuera de esos límites.

Un alcance reducido puede ser adecuado, sobre todo en una primera implantación. Aun así, debe reflejar lo que los clientes esperan que cubra el certificado. Excluir al equipo que administra el acceso a producción no elimina su influencia sobre un servicio al cliente incluido en el alcance.

En el caso de una aplicación alojada, examine toda la cadena del servicio: desarrollo, despliegue, operaciones de producción, acceso de soporte, administración de identidades, copias de seguridad y proveedores externos relevantes. Los procesos compartidos de RR. HH. o de TI pueden afectar a la seguridad aunque el alcance se centre en un producto y no en toda la empresa.

Un registro práctico del alcance debe responder a estas preguntas:

• ¿Qué entidad jurídica opera el servicio?
• ¿Qué servicios e información orientados al cliente están cubiertos?
• ¿Qué ubicaciones y modalidades de teletrabajo son relevantes?
• ¿Qué equipos y procesos compartidos afectan a esos servicios?
• ¿Qué proveedores aportan infraestructura o tratan información relevante?
• ¿Qué queda fuera de los límites y cómo se gestionan sus interfaces?

Ponga a prueba la redacción propuesta con un compañero que trate con compradores. Si no sabe explicar si el servicio del cliente está cubierto, hay que mejorar la redacción.

No optimice el alcance únicamente para reducir los honorarios de auditoría. Un límite más pequeño puede generar interfaces complicadas y dejar sin respuesta el requisito comercial. A la inversa, incluir de inmediato todas las empresas del grupo puede crear una coordinación innecesaria. El límite adecuado es defendible, comprensible y manejable desde el punto de vista operativo.

Documente la justificación y los desencadenantes para reconsiderarlo, como la adquisición de una empresa, el traslado de la infraestructura o el lanzamiento de un servicio sustancialmente distinto. El alcance debe seguir siendo una decisión de la dirección, no un párrafo olvidado.

Dé autoridad al programa, no solo un responsable

Designe un responsable de implantación y un patrocinador de la dirección que rinda cuentas. Tienen responsabilidades distintas. El responsable coordina el trabajo y mantiene la visibilidad; el patrocinador resuelve prioridades, autoriza recursos y garantiza que los objetivos de seguridad encajen con las decisiones de negocio.

La responsabilidad sobre los controles debe seguir a la autoridad operativa. RR. HH. puede ser responsable de los procedimientos relacionados con el empleo, TI de la gestión de dispositivos, ingeniería de las prácticas de desarrollo y compras puede coordinar la evaluación de proveedores. El responsable de cumplimiento no debe convertirse en responsable nominal de procesos que no puede cambiar.

Defina quién puede aceptar el riesgo residual y a qué nivel. El responsable de un servicio puede recomendar aceptar una exposición operativa limitada, mientras que un riesgo que afecte a compromisos importantes con clientes puede requerir la aprobación de la alta dirección. Documente la decisión, el razonamiento, las condiciones y la fecha de revisión.

La dirección también debe proteger la capacidad de implantación. Asignar trabajo sin hacerle hueco provoca retrasos previsibles. Pida a los responsables el esfuerzo necesario, las dependencias y las contrapartidas; después, apruebe un plan realista.

La revisión por la dirección es el momento en que la dirección evalúa el sistema y toma decisiones sobre mejoras, cambios y recursos. Un acta firmada sin decisiones significativas tiene poco valor práctico. La revisión debe poner de manifiesto las decisiones pendientes, no limitarse a respaldar un cuadro de mando en verde.

Entienda los requisitos antes de comprar una lista de comprobación

Los requisitos de los capítulos 4 a 10 de ISO/IEC 27001 constituyen el núcleo del sistema de gestión. No pueden excluirse si se declara la conformidad. Sus resultados prácticos son distintos de la implementación de controles de seguridad individuales.

El anexo A de la edición de 2022 contiene 93 controles de referencia: 37 organizativos, ocho relativos a las personas, 14 físicos y 34 tecnológicos. La aplicabilidad se basa en el riesgo; no existe un número universal que todas las empresas deban implementar.

Determine los controles necesarios para el tratamiento de riesgos y compárelos después con el anexo A para comprobar que no se ha pasado por alto ningún control necesario. Los controles también pueden proceder de requisitos contractuales, de otras fuentes o de su propio diseño. El anexo A no sustituye a la evaluación de riesgos ni es un catálogo exhaustivo de todas las medidas de seguridad posibles.

La Declaración de Aplicabilidad (SoA, por sus siglas en inglés) recoge los controles necesarios, los motivos de su inclusión, su estado de implementación y la justificación de la exclusión de controles del anexo A. Mantenga trazabilidad suficiente para explicar cómo se relacionan esas decisiones con el tratamiento de riesgos y con otros requisitos.

ISO 27002 ofrece orientación sobre los controles de seguridad de la información; ISO 27001 aporta los requisitos certificables del sistema de gestión. Utilice la orientación para entender las opciones de implementación, pero adapte los procedimientos a su organización en lugar de importar un modelo operativo que no puede sostener.

Construya el tratamiento de riesgos antes de reunir evidencias

Empiece con un método de evaluación de riesgos repetible. Defina cómo se identifican los riesgos, cómo se evalúan la probabilidad y las consecuencias, cómo se comparan los resultados y qué criterios determinan la aceptabilidad. Una interpretación coherente importa más que una fórmula de puntuación complicada.

Describa los riesgos como escenarios. «Riesgo cloud» es demasiado vago para respaldar una decisión. «Se compromete una cuenta de administrador y se utiliza para exportar registros de clientes» identifica un suceso, la información afectada y una consecuencia para el negocio.

Implique a personas que conozcan el servicio. Pueden explicar las salvaguardas existentes, el acceso de soporte, las dependencias de proveedores, las limitaciones de recuperación y las soluciones provisionales que una biblioteca de riesgos genérica puede pasar por alto. Para una estructura de registro práctica, consulte nuestra guía sobre el registro de riesgos operativo.

Para cada riesgo significativo, registre el responsable, la evaluación, los controles actuales, la decisión de tratamiento, el resultado objetivo y la evaluación del riesgo residual. Entre los enfoques de tratamiento posibles están reducir la exposición, evitar una actividad, compartir aspectos del riesgo o aceptarlo según criterios definidos. Un seguro o la externalización no eliminan todas las consecuencias ni todas las responsabilidades.

Traduzca el tratamiento en trabajo con responsables. «Mejorar la seguridad de los accesos» no es un plan ejecutable. Especifique los sistemas afectados, el cambio necesario, el responsable, los criterios de finalización y cómo se evaluará la eficacia.

Mantenga separados estos registros:

Deben ser coherentes entre sí sin convertirse en copias unos de otros. Si un tratamiento depende de la supervisión de proveedores pero el control relacionado se ha excluido sin explicación, resuelva la incoherencia antes de preparar la auditoría.

Revise los riesgos a intervalos planificados y cuando se produzcan cambios significativos. Un nuevo proveedor de soporte, una ampliación de la recogida de datos, un incidente o un cambio importante de arquitectura pueden dejar obsoleta una decisión anterior.

Integre los controles en las operaciones habituales

Una política establece expectativas; un procedimiento explica cómo se realiza el trabajo; los registros operativos demuestran lo que realmente ocurrió. La preparación para la certificación necesita los tres cuando corresponda.

Por ejemplo, una política de accesos debe estar conectada con un proceso de altas y bajas implantado, con muestras de cambios de acceso y con una revisión de las excepciones. Un documento de política por sí solo deja sin demostrar la mayor parte de esa historia.

Construya el proceso en torno a las responsabilidades reales. Identifique quién solicita el acceso, quién lo aprueba, quién lo concede, qué ocurre cuando cambia el puesto de alguien y cómo se eliminan las cuentas. Incluya las cuentas de servicio y los usuarios externos cuando afecten al alcance.

Aplique el mismo razonamiento a otros procesos importantes:

• La evaluación de proveedores debe conectar la criticidad del servicio, el acceso a la información, las expectativas contractuales, los resultados de las revisiones y las cuestiones pendientes.
• La gestión de incidentes debe conectar las vías de notificación, las responsabilidades de respuesta, el escalado, la recuperación y las lecciones aprendidas.
• Las copias de seguridad y la recuperación deben conectar las necesidades del negocio, los sistemas protegidos, los procedimientos de restauración, los resultados de las pruebas y el trabajo de seguimiento.
• La gestión de cambios debe conectar la aprobación, las pruebas, los registros de despliegue, los cambios de emergencia y las excepciones.

Los controles físicos y relativos a las personas siguen importando en una organización basada en la nube. El teletrabajo, la protección de dispositivos, las conversaciones confidenciales, los cambios laborales y la concienciación no pueden descartarse porque los servidores estén externalizados.

Establezca la frecuencia de los controles según el riesgo y las necesidades operativas. No copie en una política el compromiso de una revisión trimestral si el responsable no puede llevarla a cabo y conservar los registros. Una política que describe un proceso que nadie sigue crea una brecha evitable entre la intención y la implementación.

Diseñe las evidencias para la inspección, no para el volumen

Una buena evidencia responde a una pregunta definida sobre un requisito o un control. Una carpeta enorme de capturas de pantalla no es intrínsecamente más sólida que un conjunto más reducido y bien explicado de registros fiables.

Para cada control importante, especifique el sistema de origen, el responsable, el método de recopilación, la cobertura, la frecuencia esperada y el revisor. Distinga las evidencias de diseño de las evidencias de funcionamiento. Una configuración de identidades puede mostrar que la autenticación multifactor está activada; los registros de aprobación y las revisiones de accesos demuestran otros aspectos de la gobernanza de accesos.

Las evidencias deben dejar claro su significado:

• ¿Qué servicio, sistema o población cubren?
• ¿Cuándo se generaron y qué periodo representan?
• ¿Son lo bastante completas para la cuestión que se evalúa?
• ¿Quién las revisó y qué excepciones se identificaron?
• ¿Qué seguimiento se derivó de esas excepciones?

Conserve también los resultados fallidos. Una prueba de restauración fallida con investigación, corrección y una nueva prueba satisfactoria documentadas puede demostrar que el seguimiento y la mejora funcionan. Eliminar los resultados incómodos perjudica la utilidad del registro.

Proteja las evidencias como información por derecho propio. Las exportaciones pueden contener datos de empleados, identificadores de clientes o configuraciones sensibles. Limite el acceso, minimice el contenido innecesario y defina la conservación en función de las obligaciones pertinentes y de las necesidades del negocio. Organice un acceso controlado para los auditores en lugar de distribuir alegremente archivos voluminosos.

Utilice la auditoría interna y la revisión por la dirección para comprobar la preparación

La auditoría interna evalúa si el SGSI es conforme con los requisitos aplicables y si se implementa y mantiene de forma eficaz. Debe abarcar el sistema de gestión, no limitarse a comprobar parámetros técnicos.

Planifique el alcance, los criterios, los métodos y los informes de la auditoría. Seleccione auditores competentes y preserve la objetividad y la imparcialidad. Una organización pequeña puede recurrir a apoyo externo o a fórmulas multifuncionales adecuadas en lugar de pedir a una sola persona que evalúe todo su propio trabajo.

Las pruebas de auditoría útiles siguen un registro a lo largo del proceso. Seleccione la baja de un empleado y compruebe la notificación, la eliminación de cuentas, la gestión de los equipos y las excepciones. Seleccione un proveedor y examine si su evaluación de riesgos se corresponde con su acceso real. Seleccione una acción de tratamiento y verifique si la finalización declarada tiene respaldo operativo.

Documente los hallazgos con precisión, incluidos el requisito, las evidencias observadas y la brecha. No reduzca la auditoría a un porcentaje de avance que oculte procesos de gestión que faltan.

A continuación, la revisión por la dirección considera las entradas exigidas, entre ellas el desempeño, los resultados de la auditoría, los cambios, el estado de la evaluación y el tratamiento de riesgos y las oportunidades de mejora. Prepare un dosier de decisión conciso con los registros de apoyo disponibles. Explique dónde debe elegir la dirección entre corrección, recursos adicionales, cambio de objetivos o aceptación aprobada del riesgo.

En el caso de las no conformidades, separe la corrección inmediata de la acción correctiva. Desactivar una cuenta olvidada corrige el problema inmediato. Reparar el proceso de notificación y revisar las bajas posteriores aborda la recurrencia. Documente la causa, la acción, el responsable y la evaluación de la eficacia.

Entienda la fase 1, la fase 2 y la decisión de certificación

La certificación inicial suele constar de dos fases de auditoría. Acuerde con el organismo de certificación los aspectos organizativos, los registros esperados y las expectativas de preparación con antelación suficiente para planificar adecuadamente.

La fase 1 examina la preparación, el alcance y la documentación del sistema de gestión. Ayuda al organismo a entender la organización y a evaluar la preparación para la fase 2. Cuente con que se examinará la relación entre alcance, evaluación de riesgos, tratamiento, la Declaración de Aplicabilidad y los procesos de gestión. Resuelva las cuestiones detectadas en lugar de tratar la fase 1 como un mero trámite administrativo.

La fase 2 evalúa la implementación y la eficacia. Los auditores utilizan entrevistas, observación y muestras de registros para comprobar si el SGSI funciona tal como se describe. Los empleados deben poder explicar sus responsabilidades reales, no recitar respuestas ensayadas.

Mantenga organizadas las solicitudes durante la auditoría. Designe un coordinador, registre las solicitudes, identifique al responsable adecuado y aporte las evidencias pertinentes con su contexto. Si falta algo, explique la situación con exactitud. No cree registros a posteriori que den a entender falsamente que un proceso tuvo lugar.

Una no conformidad significa que no se ha cumplido un requisito. Los hallazgos mayores afectan a la capacidad del sistema de gestión para lograr los resultados previstos; los menores no tienen ese efecto. La clasificación depende del contexto, por lo que no se puede asignar de antemano una etiqueta universal a un único registro que falte.

El organismo de certificación determina de forma independiente los hallazgos, las respuestas exigidas, las medidas de verificación y la decisión de certificación. Confirme por adelantado sus plazos y requisitos de seguimiento. La recomendación de un auditor no es en sí misma un certificado emitido, y los hallazgos sin resolver pueden retrasar la decisión.

Tras la certificación, un ciclo típico incluye auditorías de seguimiento en los años intermedios y una recertificación antes de que caduque el certificado de tres años. Confirme con su organismo el programa de auditoría y las condiciones concretas. Las auditorías de seguimiento no son un permiso para detener el SGSI entre visita y visita.

Planifique el calendario y el presupuesto en función de las dependencias

La duración depende de la madurez, el alcance, los riesgos sin resolver, la disponibilidad de evidencias, la capacidad interna y la programación de los auditores. No existe un periodo universal de evidencias de funcionamiento de ISO 27001 que deje automáticamente preparada a cualquier organización.

Pregunte al organismo de certificación qué necesita muestrear en sus circunstancias. Un proceso que se realiza mensualmente genera registros de forma distinta a un ejercicio anual. No espere a reservar la auditoría para descubrir que un control importante nunca se ha ejecutado.

Separe el trabajo que puede acelerar (recopilación, coordinación, redacción y preparación de revisiones) del trabajo que requiere implementación y un funcionamiento demostrado. Paralelice las tareas independientes, pero respete las dependencias: una Declaración de Aplicabilidad no puede cerrarse de forma creíble sin el razonamiento de selección de controles, y la eficacia no puede evaluarse únicamente a partir de una política propuesta.

Utilice hitos de preparación en lugar de una única fecha de finalización optimista:

Presupueste el esfuerzo interno, la corrección, las herramientas, la formación, el apoyo de asesoría opcional y la evaluación externa. Incluya las auditorías de seguimiento, la recertificación y el mantenimiento continuo, no solo la factura de la primera auditoría.

Pida a los organismos de certificación que expliquen sus supuestos sobre personal, centros, actividades, complejidad y organización de la auditoría. Compare el ciclo completo y los costes de seguimiento. No trate una oferta inicial baja como el coste completo de operar un SGSI certificado.

Ejemplo práctico: un servicio, un plan sostenible

Consideremos, a modo ilustrativo, una empresa de 30 personas que opera un servicio alojado para compartir documentos. Supongamos que ya dispone de gestión de identidades, aprobaciones de despliegue y copias de seguridad, pero que las revisiones de proveedores y los registros de revisión de accesos son irregulares. Su posible cliente quiere garantías sobre el servicio alojado, incluido el acceso de soporte.

La dirección define como alcance el servicio y los procesos de desarrollo, operaciones y soporte que lo sustentan. Documenta las interfaces con RR. HH. y con la TI compartida en lugar de excluir sus efectos sobre la seguridad. El CEO patrocina el programa; un responsable de implantación lo coordina; los responsables operativos son los dueños de los controles.

El equipo identifica un escenario en el que unos permisos de soporte excesivos exponen documentos de clientes. El tratamiento incluye roles de soporte restringidos, elevación temporal aprobada, revisiones de accesos y una monitorización adecuada al servicio. La Declaración de Aplicabilidad recoge los controles necesarios y su estado de implementación.

A continuación, el responsable de accesos reúne una configuración de roles, una muestra de registros de aprobación, una revisión completada y evidencias de que los permisos excesivos detectados en esa revisión se eliminaron. Estos registros acreditan algo más que la existencia de una política de accesos.

Durante la auditoría interna se detecta que un contratista que ya se ha marchado tiene una cuenta activa. El equipo la desactiva, investiga la notificación de RR. HH. a TI que no se produjo, añade un paso explícito para la finalización de contratistas y revisa las bajas posteriores para evaluar la eficacia. La revisión por la dirección considera el hallazgo, los riesgos restantes y los recursos necesarios para las revisiones continuas.

Solo a efectos de planificación presupuestaria, supongamos que ocho colaboradores dedican cada uno dos horas semanales durante doce semanas. Eso suma 192 horas internas, sin contar la corrección especializada ni la participación en la auditoría. Se trata de un cálculo de capacidad ilustrativo, no de una estimación de mercado ni de una promesa de certificación.

La lección es de gestión: asigne el trabajo a personas con autoridad, reserve capacidad y haga que la preparación dependa de las evidencias. Las salvaguardas técnicas existentes reducen parte del trabajo de implantación, pero no sustituyen a las decisiones sobre riesgos, la auditoría interna ni la revisión por la dirección.

Automatice el trabajo repetible sin renunciar al criterio

La automatización puede apoyar la actualización de inventarios, la recopilación de evidencias, los recordatorios, las comprobaciones técnicas y los informes. Priorice el trabajo recurrente con datos de origen fiables y un revisor claro, en lugar de automatizar un proceso poco claro.

Una comprobación automatizada necesita una cobertura definida y una gestión de fallos. Si una conexión deja de recopilar registros, distinga entre «no se ha detectado ningún problema» y «no hay datos actuales». Confirme que la fuente cubre los sistemas, cuentas o ubicaciones relevantes antes de confiar en el resultado.

Mantenga explícito el criterio humano para la aceptación de riesgos, la aplicabilidad de los controles, las conclusiones sobre las evidencias y las decisiones de la dirección. Una comprobación de configuración puede mostrar que el cifrado está activado; no acredita que el acceso a las claves, la recuperación y las vías excepcionales de los datos se gestionen adecuadamente.

Del mismo modo, la automatización de flujos de trabajo puede organizar las solicitudes y los hallazgos de la auditoría interna, pero no aporta competencia ni independencia de auditoría. Los resúmenes y las correspondencias generados por IA deben seguir siendo borradores hasta que un revisor compruebe las fuentes y apruebe las conclusiones.

Mida tanto la eficiencia como la eficacia: el tiempo dedicado a preparar evidencias, las acciones correctivas vencidas, la cobertura incompleta, los fallos repetidos y el tiempo necesario para resolver excepciones importantes. Nuestra guía sobre métricas del SGSI explica cómo hacer que las mediciones sean útiles para las decisiones de la dirección.

Mantenga activa la responsabilidad después de la certificación

Antes de que llegue el certificado, establezca el calendario de mantenimiento. Entre las recomendaciones prácticas figuran comprobaciones periódicas por parte de los responsables, revisiones de riesgos desencadenadas por cambios relevantes, evaluaciones planificadas de controles, auditorías internas, revisiones por la dirección y la preparación de las evaluaciones externas. Elija las frecuencias según el proceso y el riesgo, en lugar de hacer mensual cada actividad.

Reasigne las responsabilidades cuando los empleados cambien de puesto o se marchen. Revise el alcance y la aplicabilidad de los controles cuando cambie el negocio. Haga seguimiento de las excepciones recurrentes: la eliminación tardía y repetida de accesos apunta a un problema de proceso aunque cada caso individual acabe cerrándose.

Secani apoya este flujo de trabajo conectando requisitos, controles, evidencias, responsables, tareas y decisiones de revisión en un espacio de trabajo compartido. Empiece con un servicio representativo, modele sus sistemas y dependencias, vincule las evidencias existentes a lo que demuestran y convierta las brechas en tareas asignadas. Contraste las sugerencias asistidas por IA con sus fuentes y conserve las aprobaciones humanas y el historial de decisiones. Esto ayuda al equipo a conservar lo que aprende durante la certificación a medida que cambian los sistemas; la certificación sigue siendo decisión del organismo independiente.

Preguntas que cambian el plan de implantación

¿Exige ISO 27001 una prueba de penetración?

No existe una cláusula universal de ISO 27001 que obligue a todas las organizaciones a realizar una prueba de penetración. Las pruebas necesarias dependen del tratamiento de riesgos, los controles aplicables, las características del servicio y los requisitos contractuales. Cuando se necesiten pruebas, defina la cobertura, la corrección y la repetición de las pruebas en lugar de conservar únicamente un informe.

¿Deberíamos optar por SOC 2?

Pregunte qué exigen los clientes y qué alcance esperan. SOC 2 da lugar a un informe de atestación; ISO 27001 da lugar a la certificación de un sistema de gestión. Parte de las evidencias de funcionamiento puede reutilizarse, pero ninguna de las dos se convierte automáticamente en la otra. Evalúe los requisitos de cada una por separado antes de comprometerse con ambas.

¿Necesitamos un consultor externo?

No necesariamente. La ayuda externa puede resolver cuestiones de interpretación, capacidad o necesidades especializadas. Mantenga la responsabilidad interna y asegúrese de que los procedimientos sigan siendo utilizables cuando termine el encargo. La acreditación de una persona como implantador o auditor no certifica a su empleador.

Empiece con una decisión y un rastro de evidencias

Apruebe un breve acta de constitución de la implantación que recoja la necesidad comercial, el alcance previsto, el patrocinador, el responsable, los responsables de los controles, la capacidad y los hitos de preparación. Después, tome un servicio importante y siga un control desde el requisito hasta el tratamiento de riesgos, la implementación, las evidencias y la revisión.

Ese primer recorrido pondrá de manifiesto las responsabilidades poco claras y los registros que faltan antes de que se multipliquen. Utilice nuestra lista de comprobación de ISO 27001 para organizar el trabajo restante, manteniendo separados los requisitos del sistema de gestión y la aplicabilidad de los controles.

Un SGSI duradero hace que las decisiones de seguridad sean inspeccionables y repetibles. La certificación reconoce el sistema dentro de su alcance; la dirección lo mantiene en funcionamiento cuando el equipo auditor se marcha.