Artículos

Artículos, a partir de nuestros propios datos

Publicamos lo que podemos demostrar. Cada texto de abajo se apoya en un conjunto de datos que mantenemos y citamos, y donde usted puede repetir la consulta por su cuenta, decimos cómo.

El artículo 13 del CRA para un fabricante de software: los veinticinco apartados en orden, cuáles son suyos, cuáles de la Comisión, y una lista de comprobación por función
El artículo 13 del Reglamento de Ciberresiliencia es el artículo del fabricante: veinticinco apartados, desde los requisitos esenciales del apartado 1 hasta las competencias de la Comisión del apartado 25. Veintiuno de ellos son deberes que un fabricante de software asume, desde la evaluación de riesgos del producto y la diligencia sobre los componentes hasta el período de asistencia, el punto de contacto único, la documentación técnica conservada diez años, las medidas correctoras y lo que hay que hacer antes de cesar la actividad; dos son opciones, dos pertenecen a la Comisión y a las autoridades. El artículo 14 añade los plazos de notificación, los artículos 19 y 20 los deberes del importador y del distribuidor, el artículo 24 los del administrador, y el anexo I los requisitos que el producto debe cumplir. Una página gratuita enumera cada fila que vincula a su función, con las palabras del Diario Oficial en seis idiomas, con un estado por fila.
13 de septiembre de 2026
El plazo de incidentes NIS2 para una empresa de software: la alerta temprana a las 24 horas, la notificación a las 72 horas, el informe final al mes, qué hace significativo un incidente para un proveedor cloud, y una página que redacta los tres informes
El artículo 23, apartado 4, de NIS2 hace correr tres plazos desde el momento en que una entidad esencial o importante tiene conocimiento de un incidente significativo: una alerta temprana en 24 horas, una notificación del incidente en 72, y un informe final en el mes siguiente a esa notificación, con un informe intermedio a petición y un informe de situación cuando el incidente sigue abierto. Para un proveedor de servicios de computación en nube, el Reglamento de Ejecución (UE) 2024/2690 dice cuándo un incidente es significativo: una pérdida económica directa superior a 500 000 EUR o al 5 % del volumen de negocios, la cifra más baja, un servicio totalmente indisponible durante más de 30 minutos, una disponibilidad limitada para más del 5 % o 1 millón de sus usuarios en la Unión durante más de una hora, o una vulneración de datos sospechosa de ser maliciosa. Qué contiene cada informe, a qué CSIRT va, y una página gratuita que calcula los plazos y redacta los tres en seis idiomas.
13 de septiembre de 2026
El registro de acción correctiva ISO 27001: lo que pide el apartado 10.2 tras una no conformidad, las siete secciones que un auditor acepta, los errores que reabren un hallazgo, y una página que lo redacta
El apartado 10.2 es lo que le ocurre a una no conformidad una vez encontrada: corregirla y tratar lo que causó, encontrar la causa, preguntar si el mismo problema existe en otro lugar, actuar para que no se repita, comprobar que la acción funcionó, cambiar el sistema de gestión donde estaba la causa, y conservar la no conformidad, las acciones y sus resultados como información documentada. Un registro que un auditor acepta tiene siete secciones en ese orden, separa la corrección de la acción correctiva y sigue abierto hasta que la comprobación muestra que la acción funcionó. Una página gratuita redacta el registro a partir del hallazgo, la corrección, la causa, la acción con su responsable y su fecha, y la comprobación de la eficacia.
13 de septiembre de 2026
La evaluación de impacto de un sistema de IA ISO 42001: lo que pide el apartado 6.1.4, los tres niveles de consecuencias, dónde se encuentra con el Reglamento de IA, los errores que señala un auditor, y una página que la redacta
El apartado 6.1.4 de ISO/IEC 42001 hace que la empresa evalúe lo que cada sistema de IA podría hacer a los individuos y grupos a los que afecta y a la sociedad, conserve el resultado como información documentada y actúe en consecuencia a lo largo del ciclo de vida del sistema; el apartado 8.4 ejecuta el proceso y cuatro controles del anexo A piden el proceso, la conservación, el daño a individuos y grupos, y el daño más allá de los usuarios. Es el registro que la norma tiene e ISO 27001 no. Una evaluación que un auditor acepta nombra la finalidad y el uso indebido previsible, las personas, las consecuencias en los tres niveles con una probabilidad y una gravedad cada una, los beneficios, las medidas, un resultado y una fecha de revisión; según el Reglamento de IA es la entrada de la evaluación de impacto sobre los derechos fundamentales del artículo 27 y el lugar donde la empresa registra su propia lectura del sistema. Una página gratuita la redacta para un sistema.
13 de septiembre de 2026
La evaluación de riesgos ISO 27001 para una empresa de software: lo que pide el apartado 6.1.2, un método de cinco puntos, los riesgos de partida y una página que redacta el registro y el plan de tratamiento
El apartado 6.1.2 no prescribe un método; prescribe lo que el método debe producir: criterios para aceptar y para evaluar riesgos, una identificación de los riesgos de seguridad de la información, un análisis de sus consecuencias y probabilidad, una evaluación frente a los criterios, y resultados repetibles y comparables. El apartado 6.1.3 pide después las opciones de tratamiento, los controles, la comparación con el anexo A, la declaración de aplicabilidad y el plan. Para una empresa de software los riesgos se conocen en gran parte antes del primer taller: compromiso de credenciales, un portátil perdido, una caída del proveedor de nube, una copia de seguridad que no se restaura, un empleado que se va con el acceso abierto, una vulnerabilidad entregada en su propio código. Una escala de cinco puntos para probabilidad e impacto, el producto como nivel, un umbral de aceptación, la opción de tratamiento y los controles para cada riesgo por encima, y una página gratuita que redacta el registro y el plan en seis idiomas.
13 de septiembre de 2026
La Ley de Datos para una empresa SaaS: las obligaciones de cambio de proveedor desde el 12 de septiembre de 2025, las nueve cláusulas contractuales, el fin de los cargos por cambio, y lo que debe un titular de datos
El Reglamento (UE) 2023/2854 se aplica desde el 12 de septiembre de 2025, y una empresa que vende software alojado es, con arreglo a él, un proveedor de un servicio de tratamiento de datos, sea cual sea su tamaño. El capítulo VI le hace eliminar todo obstáculo a que un cliente cambie de proveedor o se traslade a su propia infraestructura: un contrato escrito con las nueve cláusulas del artículo 25, apartado 2, un preaviso de como máximo dos meses, un período de transición de como máximo 30 días naturales, un período de recuperación de al menos 30 días naturales, la supresión después, un registro en línea de los datos exportables, interfaces abiertas sin coste, una mención en el sitio web de la jurisdicción a la que está sujeta la infraestructura, y cargos por cambio basados en costes hoy y prohibidos a partir del 12 de enero de 2027. Una empresa cuyo producto es un producto conectado o un servicio relacionado es también titular de datos según el capítulo II, con acceso desde el diseño para los productos introducidos en el mercado después del 12 de septiembre de 2026. Las 96 filas del Reglamento que vinculan a cada función son un conjunto de datos en seis idiomas.
13 de septiembre de 2026
La política de IA ISO 42001 para una empresa de software: lo que pide el apartado 5.2, las diez secciones, los deberes del Reglamento de IA que nombra, los errores que señala un auditor, y una página que la redacta
El apartado 5.2 de ISO/IEC 42001 pide a la dirección una política de IA adecuada a aquello para lo que la empresa usa la IA, que dé el marco de los objetivos de IA, se comprometa con los requisitos aplicables y con la mejora del sistema, esté documentada, comunicada y disponible, y diga cómo se sitúa junto a las demás políticas. Tres controles del anexo A, A.2.2, A.2.3 y A.2.4, piden la política, su alineación con las demás políticas y su revisión. Una política de IA breve para una empresa de software ocupa diez secciones: propósito, alcance, posición, los usos excluidos, responsabilidad, objetivos, los requisitos aplicables, las demás políticas, comunicación y revisión. La sección de requisitos es donde entra el Reglamento de IA: el deber de alfabetización del artículo 4, los deberes de transparencia del artículo 50 cuando la empresa genera contenido, y una determinación de alto riesgo registrada por sistema, que la propia política nunca afirma. Una página gratuita redacta la política a partir de once respuestas en seis idiomas.
13 de septiembre de 2026
La política de seguridad de la información ISO 27001: lo que pide el apartado 5.2, las nueve secciones de una política breve, los errores que señala un auditor, y una página que la redacta
El apartado 5.2 pide a la dirección una política adecuada al propósito de la empresa, que lleve los objetivos de seguridad o el marco para fijarlos, se comprometa con los requisitos aplicables y con la mejora del sistema, y esté documentada, comunicada y disponible para las partes que la necesitan. Son siete cosas, y ninguna es un número de páginas. Una buena política para una empresa de software ocupa dos páginas en nueve secciones: propósito, alcance, por qué la seguridad importa aquí, compromisos, objetivos, funciones, las políticas temáticas que dependen de ella, cumplimiento, y comunicación y revisión. Los errores que señala un auditor son la plantilla con el nombre de otra empresa, las treinta páginas que nadie leyó, la aprobación que falta, objetivos que nadie puede medir y una política que ningún recién llegado ha visto. Una página gratuita redacta la política a partir de diez respuestas en seis idiomas.
13 de septiembre de 2026
La revisión por la dirección ISO 27001: las siete entradas del apartado 9.3 como orden del día, las cuatro tendencias, las dos salidas, lo que debe mostrar el acta, y una página que la redacta
El apartado 9.3 hace que la dirección revise el sistema de gestión a intervalos planificados frente a siete entradas: las acciones de la revisión anterior, los cambios en las cuestiones externas e internas, los cambios en lo que las partes interesadas necesitan y esperan, la retroalimentación sobre el desempeño con sus cuatro tendencias (no conformidades y acciones correctivas, seguimiento y medición, resultados de auditoría, los objetivos), la retroalimentación de las partes interesadas, la evaluación de riesgos y el plan de tratamiento, y las oportunidades de mejora. Las salidas son dos: decisiones sobre la mejora continua y cualquier cambio que el sistema necesite, conservadas como información documentada. El acta que un auditor acepta muestra cada entrada considerada y cada decisión tomada, con un responsable y una fecha en cada acción. Una página gratuita redacta el acta en el orden del apartado a partir de los datos de la reunión, las cifras y lo que se dijo.
13 de septiembre de 2026
Cómo comprobar que un certificado ISO 9001 es auténtico: qué debe mostrar un certificado, tres comprobaciones en diez minutos, y los 27 registros de acreditación
ISO no certifica empresas ni lleva un registro de ellas, así que un certificado solo vale lo que vale la entidad que lo emitió y la acreditación que respalda a esa entidad. Lo que ISO/IEC 17021-1 hace que muestre un certificado, las tres comprobaciones (el certificador está acreditado para ISO 9001, el certificado está vigente, el alcance cubre lo que usted compra), los 27 registros nacionales de acreditación con enlaces, por qué un certificador de otro Estado de la UE vale tanto como uno del suyo, y por qué el certificado barato no acreditado cuesta más al final.
12 de septiembre de 2026
Cuál es su autoridad de control del RGPD: el establecimiento principal, la autoridad principal del artículo 56, los casos locales y las 30 autoridades del Comité
Una empresa de software con clientes en varios Estados miembros trata con una sola autoridad de control para su tratamiento transfronterizo: la autoridad de su establecimiento principal, la autoridad de control principal del artículo 56, apartado 1, su único interlocutor conforme al artículo 56, apartado 6. Dónde está, qué significa el establecimiento principal para un responsable y para un encargado (artículo 4, punto 16), cuándo otra autoridad conserva un caso local (artículo 56, apartado 2), qué obtiene en su lugar una empresa sin establecimiento en la Unión (artículo 27, considerando 122), y adónde va la notificación de violación en 72 horas (artículo 33, apartado 1). Con las 27 autoridades y las tres del EEE tal como el Comité Europeo de Protección de Datos lista a sus miembros, leídas el 12 de septiembre de 2026.
12 de septiembre de 2026
Cuando su caída se convierte en el incidente grave de su cliente bancario: los seis criterios de DORA, el umbral de dos horas de inactividad del RTS 2024/1772, los plazos de cuatro horas, 24 horas, 72 horas y un mes del RTS 2025/301, y los datos que su cliente necesitará de usted
Una entidad financiera debe notificar un incidente grave relacionado con las TIC a su supervisor en las cuatro horas siguientes a su clasificación y a más tardar 24 horas después de tener conocimiento de él, presentar un informe intermedio en 72 horas y cerrar en un mes. Que una caída en su proveedor de software sea grave lo deciden seis criterios y los umbrales del Reglamento Delegado (UE) 2024/1772: más de dos horas de inactividad de un servicio que sustenta una función esencial o importante, más de 24 horas de duración, más del 10 por ciento de los clientes, dos o más Estados miembros, pérdidas de datos, 100 000 euros. Lo que debe contener cada informe según el Reglamento Delegado (UE) 2025/301, cuáles de esos datos solo tiene el proveedor, y en qué convierte eso la cláusula de asistencia en caso de incidente del artículo 30, apartado 2, letra f). Leído en el Diario Oficial.
12 de septiembre de 2026
Cuánto cuesta la certificación ISO 9001: los días de auditoría que IAF MD 5 fija por plantilla, la tarifa diaria, el total a tres años, y por qué es un tercio de ISO 27001
Las entidades de certificación no publican precios, pero los días de auditoría no son su opinión: IAF MD 5 los fija según el número de personas en el alcance, 1,5 días hasta cinco personas, 3 para 16 a 25, 7 para 86 a 125, y el organismo de acreditación sujeta al certificador a la tabla. Multiplique por una tarifa diaria de 1.200 a 1.800 euros, añada dos auditorías de seguimiento de alrededor de un tercio cada una, y tendrá su cifra antes de que nadie le pase una oferta. Calculado para seis tamaños de empresa, con los días de ISO 27001 al lado, qué sube o baja la cifra, y qué más paga.
12 de septiembre de 2026
La política DORA de su banco sobre proveedores, RTS 2024/1773: las seis preguntas de la diligencia debida, las cinco fuentes de garantía, las ocho condiciones para aceptar su certificado ISO 27001 en lugar de una auditoría, y los cinco informes que deberá
Toda entidad financiera de la Unión tiene una política escrita sobre sus contratos de servicios de TIC que sustentan funciones esenciales o importantes, y el Reglamento Delegado (UE) 2024/1773 dice qué debe contener esa política, en vigor desde el 15 de julio de 2024. Leído desde el lado del proveedor: las seis cosas que el cliente evalúa sobre usted antes de firmar (artículo 6), las cinco fuentes de garantía que puede usar y las ocho condiciones bajo las cuales puede confiar en sus certificaciones o informes de auditoría en vez de auditarle él mismo (artículo 8), los indicadores clave, las penalizaciones y los cinco tipos de informe que exigirá el contrato (artículo 9), y el plan de salida que debe probar (artículo 10). Con lo que un certificado ISO 27001 responde, y lo que no.
12 de septiembre de 2026
DORA para un proveedor de software: las cláusulas contractuales del artículo 30 que le enviará su cliente bancario, el registro de información en el que figurará, y lo que ISO 27001 ya responde
Desde el 17 de enero de 2025, todo banco, aseguradora, empresa de servicios de inversión y entidad de pago de la Unión gestiona a sus proveedores de software con arreglo al Reglamento (UE) 2022/2554, DORA. El proveedor no está regulado; el contrato sí. El artículo 30 enumera nueve cláusulas que todo contrato de servicios de TIC debe contener y seis más cuando el servicio sustenta una función esencial o importante: ubicaciones, devolución de datos, asistencia en incidentes a un coste fijado de antemano, cooperación con las autoridades del cliente, preaviso de resolución, derechos de auditoría, estrategias de salida. Cada cláusula leída en el Reglamento, el registro de información que el cliente presenta cada año, los tres actos delegados que hay detrás, y para cuáles de esas cláusulas un sistema ISO 27001 ya produce la evidencia.
12 de septiembre de 2026
La subcontratación bajo DORA, RTS 2025/532: las doce condiciones que lleva su contrato cuando subcontrata un servicio esencial, las diez condiciones que su cliente comprueba antes, y el plazo de preaviso antes de cambiar de subcontratista
Desde el 22 de julio de 2025 una entidad financiera solo puede permitir que su proveedor de software subcontrate un servicio que sustenta una función esencial o importante en las condiciones del Reglamento Delegado (UE) 2025/532. Diez condiciones que el cliente evalúa antes de firmar, desde su capacidad para identificar a cada subcontratista hasta si el subcontratista concede los mismos derechos de auditoría; doce condiciones que el contrato lleva después, desde su responsabilidad por el servicio del subcontratista hasta el derecho de resolución del cliente; un plazo durante el cual no puede cambiar de subcontratista hasta que el cliente haya aprobado o no se haya opuesto; y tres casos en los que el cliente puede resolver el contrato. Leído en el Diario Oficial, con lo que el registro de información consigna sobre la cadena y lo que un registro de proveedores ISO 27001 ya responde.
12 de septiembre de 2026
Los diecinueve tipos de servicios de TIC de DORA, S01 a S19: cuál es un producto SaaS, qué consigna el registro de información sobre él, y por qué un contrato puede ser varias filas
Cada servicio de TIC que compra un banco, una aseguradora o una entidad de pago se consigna en su registro de información bajo uno de diecinueve códigos, S01 a S19, del anexo III del Reglamento de Ejecución (UE) 2024/2956. Un producto alojado es S19, el software instalado S13, un servicio gestionado S14, un feed de datos S05, y el cliente presenta una fila por servicio y función, de modo que un solo contrato puede convertirse en varias. Los diecinueve tipos con las descripciones del propio Reglamento, la columna que lleva el código, lo que el cliente debe consignar al lado, y por qué el código que da a un cliente debe coincidir con el que da al siguiente.
12 de septiembre de 2026
El artículo 20 de NIS2 para el consejo: lo que el órgano de dirección debe aprobar, supervisar y aprender, los doce lugares donde el Reglamento de Ejecución lo nombra, y qué significa la responsabilidad
El artículo 20 de NIS2 obliga al órgano de dirección de una entidad esencial o importante a aprobar las medidas para la gestión de riesgos de ciberseguridad, supervisar su puesta en práctica, responder por los incumplimientos del artículo 21 por parte de la entidad, y asistir a formaciones. El Reglamento de Ejecución 2024/2690 nombra después al órgano de dirección en doce lugares de su anexo: una aprobación fechada de la política, una revisión anual, una línea de información directa, la aceptación de los riesgos residuales, informes de cumplimiento, un programa de sensibilización. Cada uno de los doce como registro, la cláusula de ISO 27001 que ya lo produce, y lo que los artículos 32 y 34 dicen sobre la responsabilidad.
12 de septiembre de 2026
El artículo 50 del Reglamento de IA para una empresa que suministra o usa IA generativa: las cuatro obligaciones de transparencia vigentes desde el 2 de agosto de 2026, la transición del 2 de diciembre de 2026, el código de buenas prácticas y el icono de la UE
El artículo 50 es la obligación del Reglamento de IA que alcanza a una empresa sea o no de alto riesgo su sistema: decir a las personas que hablan con una IA, marcar el contenido generado para que las máquinas lo detecten, revelar las ultrasuplantaciones y los textos escritos por IA sobre asuntos de interés público, informar a las personas expuestas al reconocimiento de emociones. Se aplica desde el 2 de agosto de 2026, el ómnibus digital lo dejó sin cambios y dio a los proveedores de sistemas generativos ya en el mercado hasta el 2 de diciembre de 2026 para la obligación de marcado. Los cuatro apartados en orden, quién es proveedor y quién responsable del despliegue en cada uno, el código de buenas prácticas de la Comisión del 10 de junio de 2026 con su marcado de dos capas y su icono AI, la multa y el registro que lleva un sistema ISO 42001.
12 de septiembre de 2026
El contrato de encargo del RGPD para una empresa SaaS: las ocho cláusulas del artículo 28, apartado 3, que lleva toda adenda de cliente, el deber que la mayoría olvida, y lo que se sitúa al lado bajo DORA
Una empresa SaaS firma el mismo contrato con cada cliente para el que trata datos, y el artículo 28, apartado 3, fija su contenido: el objeto y la duración, los ocho compromisos desde las instrucciones documentadas hasta las auditorías, y el deber del encargado de señalar una instrucción que infrinja el Reglamento. Qué significa cada cláusula para un proveedor de software, la regla de los subencargados del artículo 28, apartados 2 y 4, las cláusulas contractuales tipo de la Comisión de 2021, la responsabilidad del artículo 82 y el techo de multa del artículo 83, y la cláusula DORA del artículo 30 que un cliente bancario envía junto a cada cláusula. Con la lista de comprobación gratuita que lee las dos adendas como una.
12 de septiembre de 2026
El plazo de 72 horas del RGPD para una empresa de software: cuándo lo inicia la constancia, qué contiene la notificación, el plazo propio del encargado, y los plazos de NIS2, el CRA y DORA de al lado
El artículo 33 da al responsable 72 horas desde que tiene constancia de una violación de datos personales para notificarla a la autoridad de control, y la mayoría de las empresas se equivocan en el inicio, en el contenido o en el rol. Cuándo empieza la constancia según las directrices del CEPD y el considerando 87, los cuatro contenidos del artículo 33, apartado 3, las fases del artículo 33, apartado 4, la regla de los motivos de la dilación, el deber del encargado de notificar al responsable sin dilación indebida, la comunicación a los interesados conforme al artículo 34 y sus tres excepciones, y los plazos de NIS2, el CRA y DORA que una empresa de software puede tener corriendo desde el mismo momento. Con la página gratuita que calcula el plazo y redacta la notificación.
12 de septiembre de 2026
El registro NIS2: las dos listas en las que puede estar, qué presenta, para cuándo y a quién (artículo 3(4) y artículo 27)
NIS2 tiene dos registros, no uno. Toda entidad esencial o importante presenta cuatro datos a su autoridad competente para que el Estado miembro pueda elaborar su lista a más tardar el 17 de abril de 2025 (artículo 3(3) y (4)), con los cambios notificados en dos semanas. Once tipos de entidades digitales, entre ellas los proveedores de servicios en la nube y los proveedores de servicios gestionados, presentan además seis datos a más tardar el 17 de enero de 2025 para el registro de la ENISA (artículo 27), con los cambios en tres meses. Qué Estado los recibe (artículo 26), para qué sirven las dos listas, qué no decide el registro, y el registro que hay que conservar.
12 de septiembre de 2026
El registro RGPD de actividades de tratamiento para una empresa de software: los siete campos del artículo 30, apartado 1, los cuatro del artículo 30, apartado 2, por qué la exención de 250 personas nunca se aplica, y una página que lo redacta
El artículo 30 es la única obligación del RGPD a la que remiten todas las demás, y aquella de la que la mayoría de las empresas de software cree que la exención de 250 personas las libra. No es así: el artículo 30, apartado 5, retira la exención para todo tratamiento que no sea ocasional, y un producto en uso trata datos cada día. Los siete campos del registro de un responsable y los cuatro del de un encargado, leídos del Diario Oficial, para qué sirve cada uno, el control ISO 27701 que lo evidencia, y la página gratuita que redacta el registro una actividad cada vez.
12 de septiembre de 2026
El Reglamento de IA para una empresa de software: qué papel tiene, qué se aplica a todos, qué se aplica solo a un proveedor de alto riesgo, las disposiciones pyme y las fechas modificadas
Una empresa de software se encuentra con el Reglamento de IA en uno de seis papeles, y la mayor parte del Reglamento solo se aplica a dos de ellos. Qué cuenta como sistema de IA, por qué suministrar el modelo de un proveedor con su propio nombre le convierte en proveedor, las tres obligaciones que toda empresa tiene desde 2025 y 2026 (alfabetización en IA, las prohibiciones, la transparencia), las dos vías al alto riesgo y lo que cada papel debe entonces desde el 2 de diciembre de 2027, la línea del modelo de uso general, las disposiciones para pymes y pequeñas empresas de mediana capitalización que el ómnibus digital amplió, y una tabla de quién debe qué desde cuándo. Leído en los dos Reglamentos en CELLAR el 12 de septiembre de 2026.
12 de septiembre de 2026
El Reglamento de IA tras el ómnibus digital: las fechas que cambiaron el 27 de julio de 2026, y qué controles de ISO 42001 producen la evidencia para los trece aspectos del artículo 17 y los artículos 9 a 15
El Reglamento (UE) 2026/1744, firmado el 8 de julio de 2026, publicado el 24 de julio, en vigor el 27 de julio, trasladó las fechas del Reglamento de IA para los sistemas de alto riesgo al 2 de diciembre de 2027 para los del anexo III y al 2 de agosto de 2028 para los del anexo I, reescribió la alfabetización en IA como un deber de tomar medidas, y convirtió el plan de vigilancia poscomercialización en parte de la documentación técnica. La mayoría de lo que posiciona sigue dando las fechas antiguas. Las fechas modificadas, qué más cambió para un proveedor, y nuestra correspondencia de los trece aspectos del sistema de gestión de la calidad del artículo 17, los artículos 9 a 15, 72 y 73, y los deberes de los operadores de los artículos 4 y 26 con los controles del anexo A de ISO/IEC 42001, con lo que el Reglamento pide y la norma no produce.
12 de septiembre de 2026
El representante del RGPD del artículo 27 para una empresa de software fuera de la UE: quién debe designarlo, las tres condiciones de la exención y adónde va el nombre
Una empresa de software sin establecimiento en la Unión cuyo producto usan personas que están en ella queda sujeta al Reglamento por el artículo 3, apartado 2, y debe designar por escrito un representante en la Unión (artículo 27, apartado 1), establecido en un Estado miembro donde estén sus usuarios (27, apartado 3), con mandato para que se dirijan a él las autoridades de control y los interesados (27, apartado 4), y sin efecto de escudo frente a acciones contra la propia empresa (27, apartado 5). La exención del artículo 27, apartado 2, letra a), tiene tres condiciones que deben cumplirse todas, y un producto en uso falla en la primera. Adónde va el nombre del representante: la política de privacidad (artículo 13, apartado 1, letra a)), el registro de actividades de tratamiento (artículo 30, apartado 1, letra a)) y el registro que el propio representante lleva. El tramo de multa es el artículo 83, apartado 4. Una página gratuita lo decide a partir de dos preguntas.
12 de septiembre de 2026
El RGPD para una empresa de software: responsable de sus propios datos, encargado para sus clientes, y las cinco obligaciones que dependen del tamaño y de los datos
El Reglamento (UE) 2016/679 alcanza a toda empresa de software, así que la cuestión es qué obligaciones se activan. Los dos roles por tratamiento (artículo 4), el registro de actividades de tratamiento del que la exención de 250 personas nunca libra a un producto en uso (artículo 30), el delegado (artículo 37), la evaluación de impacto (artículo 35), el representante para una empresa fuera de la Unión (artículo 27), las bases de las transferencias (capítulo V), los plazos de 72 horas y de un mes, y lo que ISO 27701 produce para cada una. Leído del Diario Oficial, con la determinación gratuita que lo deja por escrito.
12 de septiembre de 2026
Esencial o importante bajo NIS2: la regla de tamaño, las reglas sin condición de tamaño y las siete formas de ser esencial
Que NIS2 alcance a una empresa es el artículo 2; que sea esencial o importante es el artículo 3; y la diferencia es supervisión ex ante, un tope de multa más alto y una lectura más estricta de todo lo demás. Los dos artículos citados, las clases de tamaño de la Recomendación 2003/361/CE tal como se cuentan de verdad, las reglas que ignoran el tamaño, y los casos que una empresa de software falla: un proveedor de nube con 40 empleados, un gran fabricante de maquinaria, un registrador, una empresa fuera de la Unión.
12 de septiembre de 2026
¿Exige ISO 9001:2015 un manual de calidad? Qué pide el apartado 7.5 en su lugar, los 21 lugares donde la norma nombra la información documentada, y para qué sirve hoy un manual
ISO 9001:2008 exigía un manual de calidad; ISO 9001:2015 no, y lo dice en su anexo A. Lo que exige es información documentada: cinco cosas que mantener (el alcance, la información de los procesos, la política de la calidad, los objetivos, la planificación operacional) y dieciséis tipos de registros que conservar, cada uno nombrado por apartado. Qué pide el apartado 7.5 de cada documento, por qué un manual sigue siendo el lugar adecuado para el mapa del sistema, y qué poner en él. Con el número de anuncios de licitación de la UE que pidieron ISO 9001 en el último año, 17.076, cinco veces ISO 27001.
12 de septiembre de 2026
ISO/IEC 27701:2025 para una empresa de software: la norma de privacidad independiente, sus 78 controles, lo que un sistema ISO 27001 ya cubre, y los artículos del RGPD que cada control evidencia
La segunda edición de ISO/IEC 27701, publicada en octubre de 2025, ya no es una extensión de ISO 27001: es una norma de sistema de gestión por derecho propio, con los capítulos 4 a 10 y un solo anexo A de 78 controles, 31 para responsables del tratamiento de PII, 18 para encargados del tratamiento de PII y 29 controles de seguridad de la información para ambos. Leída fila a fila para una empresa de software: cuáles de los 103 requisitos cubre ya a medias un sistema ISO 27001 en funcionamiento y qué pide 27701 más allá, los 33 requisitos de privacidad que ningún control de seguridad produce, y los 32 artículos del RGPD que los controles evidencian, del registro de tratamientos al plazo de violación de 72 horas. La lectura de StandardOS, con el texto de la norma donde está.
12 de septiembre de 2026
Qué países de la UE nombran ISO 9001 en las licitaciones públicas: 4.897 anuncios alemanes, 4.743 rumanos, y uno de cada diez anuncios rumanos la nombra
En 365 días, ISO 9001 aparece en 16.356 anuncios de TED de compradores de la UE-27, el 1,87% de todo lo que publicaron y cinco veces los 3.361 que nombran ISO 27001. Alemania y Rumanía suman el 59% de las menciones; Rumanía la nombra en el 10,48% de sus anuncios, Bulgaria en el 7,34%, Hungría en el 7,02%; Francia, España e Italia apenas la nombran. Y 1.475 anuncios nombran ambas normas, el 44% de cada mención de ISO 27001. La tabla por país, el solapamiento y la consulta para volver a ejecutarlos.
12 de septiembre de 2026
ISO 9001 para una empresa de software: qué significa el apartado 8 cuando el producto es código, subapartado por subapartado
Los apartados 4 a 7, 9 y 10 de ISO 9001:2015 son el esqueleto del sistema de gestión que una empresa ISO 27001 ya gestiona. El apartado 8, Operación, es el escrito para fábricas y centros de servicio, y el que una empresa de software tiene que traducir. Qué es cada subapartado cuando el producto es software: la revisión de requisitos antes de comprometerse (8.2), el ciclo de desarrollo como diseño y desarrollo (8.3), los proveedores en la nube y las dependencias como proveedores externos (8.4), el despliegue, la trazabilidad, los datos de los clientes y el soporte como producción y provisión del servicio (8.5), la puerta de liberación (8.6), y los errores e incidentes como salidas no conformes (8.7). Con los lugares donde el Cyber Resilience Act pide los mismos registros.
12 de septiembre de 2026
La alfabetización en IA del artículo 4 del Reglamento de IA, tal como se reescribió el 27 de julio de 2026: qué significa «tomar medidas», a quién cubre, qué no exige, y el registro que hay que llevar
El artículo 4 se aplica a todo proveedor y responsable del despliegue de un sistema de IA desde el 2 de febrero de 2025. El ómnibus digital lo reescribió: medidas para apoyar la promoción de la alfabetización en IA, teniendo en cuenta los conocimientos de las personas y el contexto, y, en los términos que el Reglamento usa ahora, ninguna obligación de garantizar un nivel específico de alfabetización de ninguna persona en particular. La Comisión publicará ejemplos prácticos y el Consejo de IA objetivos comunes. Qué pide el artículo, por qué no tiene multa propia en el artículo 99, cómo las cláusulas de competencia y concienciación de ISO 42001 producen el registro, y un programa de una página.
12 de septiembre de 2026
La declaración de alcance ISO 27001: por qué un certificado que dice sede central no cubre su SaaS, qué pide la cláusula 4.3, qué comprueba un comprador bajo DORA, y tres declaraciones de alcance que pasan
La declaración de alcance es el límite del certificado, y los compradores ahora la leen frente a un reglamento: un cliente financiero solo puede confiar en su certificado ISO 27001 en vez de auditarle si su alcance cubre los sistemas de los que depende. Lo que exige la cláusula 4.3 de ISO/IEC 27001:2022, lo que ISO/IEC 17021-1 hace mostrar al certificado, el ciclo de seguimiento que decide si está vigente, el plazo ya vencido de la edición de 2013, una declaración de alcance que falla y tres que pasan para una empresa de software, y cómo las interfaces con su proveedor de nube quedan dentro del alcance mientras el proveedor queda fuera.
12 de septiembre de 2026
La declaración de aplicabilidad ISO 27001 para una empresa de software: los 93 controles, las cuatro columnas del apartado 6.1.3 d), las exclusiones que un auditor acepta, y una página que la redacta
La declaración de aplicabilidad es el único documento ISO 27001 que un auditor lee antes que cualquier otro, y el apartado 6.1.3 d) la convierte en cuatro preguntas por control: si es necesario, por qué se incluye, si está implantado, y por qué se deja fuera un control del anexo A. Para una empresa de software sin oficinas propias y con una pila alojada, los 93 controles de la edición 2022 se reparten entre los que aplican por completo, el puñado honestamente excluido, y los parcialmente implantados que deciden los hallazgos de la auditoría. Qué significa cada columna, las exclusiones que un auditor acepta y las que nunca acepta, cómo la declaración sigue al plan de tratamiento de riesgos, y una página gratuita que la redacta en seis idiomas con los estados en la dirección.
12 de septiembre de 2026
La declaración UE de conformidad bajo el CRA: el anexo V punto por punto, la forma simplificada y un ejemplo resuelto
El artículo 28 obliga al fabricante a elaborar una declaración UE de conformidad antes de la introducción en el mercado, con la estructura tipo del anexo V, y el artículo 28(4) hace de su firma el acto por el que el fabricante asume la responsabilidad del producto. Los ocho puntos del anexo V, la forma simplificada de una frase del anexo VI, las reglas que la rodean (lenguas, la declaración única, las familias de productos, 10 años de conservación), un ejemplo resuelto, y lo que cuesta una declaración ausente o incorrecta según el artículo 58 y el artículo 64.
12 de septiembre de 2026
La evaluación de impacto del RGPD para una empresa de software: los tres casos del artículo 35, apartado 3, los nueve criterios detrás, los cuatro elementos del artículo 35, apartado 7, y una página que la redacta
El artículo 35 exige una evaluación de impacto relativa a la protección de datos antes de cualquier tratamiento que entrañe probablemente un alto riesgo, y nombra tres casos en los que se exige en todo caso. Qué funciones de un producto caen en ellos, los nueve criterios que aplican las autoridades de control y la regla de que dos de ellos suelen significar una evaluación, las listas que las autoridades publican conforme al artículo 35, apartados 4 y 5, los cuatro elementos que la evaluación debe contener, el asesoramiento del delegado de protección de datos y la opinión de los interesados, la consulta previa del artículo 36 con sus ocho semanas, y la revisión cuando cambia el riesgo. Con la página gratuita que decide si es exigible y la redacta.
12 de septiembre de 2026
La información de privacidad del RGPD para una empresa de software: los doce contenidos del artículo 13, los trece del artículo 14, el momento en que se facilita cada uno, y una página que la redacta
Una información de privacidad no es un género; es una lista. El artículo 13 nombra doce contenidos que un responsable facilita en el momento en que los datos personales se obtienen del interesado, seis en todo caso y seis adicionales para un tratamiento leal y transparente, y el artículo 14 nombra trece para datos obtenidos de otra fuente, facilitados en un plazo razonable y a más tardar en un mes, con cuatro excepciones. Para una empresa de software, siete de ellos ya son columnas de su registro de actividades de tratamiento. Cada contenido tal como lo redacta el Diario Oficial, el momento en que se facilita, los dos casos en que no se debe, y una página gratuita que redacta la información a partir de las respuestas en seis idiomas.
12 de septiembre de 2026
La política de la calidad ISO 9001: las cuatro cosas que exige el apartado 5.2, las tres cosas que deben ocurrir con ella, y un ejemplo de una página
El apartado 5.2 de ISO 9001:2015 es corto y preciso. La alta dirección establece una política de la calidad que es apropiada al propósito y contexto de la organización y apoya su estrategia, proporciona un marco para los objetivos de la calidad, y se compromete a cumplir los requisitos aplicables y a la mejora continua (5.2.1). La política se mantiene después como información documentada, se comunica, se entiende y se aplica dentro de la organización, y está disponible para las partes interesadas (5.2.2). Qué significa cada uno de los siete requisitos para una página de texto, los hallazgos que anotan los auditores, cómo la misma política sirve a ISO 27001, y un ejemplo de una página en nuestras propias palabras.
12 de septiembre de 2026
La revisión por la dirección ISO 9001: las 13 entradas y 3 salidas del apartado 9.3 como orden del día, de dónde sale cada entrada, y qué debe mostrar el acta
El apartado 9.3 de ISO 9001:2015 es la única reunión para la que la norma escribe el orden del día. La alta dirección revisa el sistema de gestión de la calidad a intervalos planificados en cuanto a conveniencia, adecuación, eficacia y alineación con la estrategia (9.3.1); considera trece entradas, desde el estado de las acciones de la vez anterior hasta el desempeño de los proveedores externos (9.3.2); y decide sobre la mejora, los cambios en el sistema y los recursos (9.3.3), conservando los resultados como información documentada. El orden del día, el registro detrás de cada entrada, qué debe mostrar el acta, y cómo la misma reunión sirve a ISO 27001 y, para las entidades NIS2, a la revisión anual de la política que exige el Reglamento de Ejecución.
12 de septiembre de 2026
La solicitud de un interesado del RGPD para una empresa de software: el mes del artículo 12, apartado 3, los ocho contenidos de una respuesta de acceso, los dos meses adicionales y una página que calcula el plazo
Una solicitud conforme a los artículos 15 a 22 se responde sin dilación indebida y en todo caso en el plazo de un mes desde la recepción (artículo 12, apartado 3); el plazo termina en la misma fecha del mes siguiente o en su último día; hay dos meses adicionales cuando las solicitudes son complejas o numerosas, informando al interesado dentro del primer mes; una negativa lleva sus motivos y las vías de recurso dentro del mismo mes (12, apartado 4); la respuesta es gratuita salvo solicitud manifiestamente infundada o excesiva, y la empresa soporta la carga de probarlo (12, apartado 5). Una solicitud de acceso se responde con una copia de los datos y los ocho contenidos del artículo 15, apartado 1, letras a) a h), de los fines a las decisiones automatizadas. Leída contra el catálogo, con una página gratuita que calcula el plazo y redacta la respuesta en seis idiomas.
12 de septiembre de 2026
Las diez medidas del artículo 21(2) de NIS2 como lista de comprobación: cada letra citada, las secciones del Reglamento detrás, y los controles ISO 27001 que ya las producen
El artículo 21(2) enumera diez medidas que toda entidad esencial e importante debe adoptar, desde las políticas de análisis de riesgos hasta la autenticación multifactorial. Para los proveedores de nube, de servicios gestionados y los demás proveedores digitales, el Reglamento de Ejecución 2024/2690 detalla cada una en 13 secciones escritas a partir de ISO/IEC 27001 y 27002. Una sola tabla: las diez letras tal como las formula la Directiva, las secciones que detallan cada una, y las cláusulas ISO 27001 y controles del anexo A que producen las pruebas, con los dos puntos que un SGSI no alcanza.
12 de septiembre de 2026
Las pruebas de penetración guiadas por amenazas bajo DORA, desde el lado del proveedor: cuándo el equipo rojo de su cliente bancario puede entrar en sus sistemas de producción, la prueba de 12 semanas del RTS 2025/1190, la prueba agrupada que puede realizar en su lugar, y lo que el contrato ya dice
El artículo 26 de DORA hace que las mayores entidades financieras realicen una prueba de penetración guiada por amenazas sobre sistemas de producción al menos cada 3 años, que cubre las funciones esenciales o importantes que han externalizado, y el artículo 30, apartado 3, letra d), pone la participación del proveedor en el contrato. El Reglamento Delegado (UE) 2025/1190, en vigor desde el 8 de julio de 2025, fija la mecánica: un equipo de control que puede incluir a su personal, un equipo azul que no debe saber, una fase activa de equipo rojo de al menos 12 semanas, una repetición y un ejercicio morado en las 10 semanas siguientes a su fin, un plan de corrección en 8 semanas. El artículo 26, apartado 4, permite a un proveedor cuyos otros clientes saldrían perjudicados contratar directamente a un probador externo y realizar una sola prueba agrupada para varias entidades financieras. Lo que el proveedor firma, lo que puede rechazar, y lo que un sistema ISO 27001 ya contiene. Leído en el Diario Oficial.
12 de septiembre de 2026
Lo que debe un responsable del despliegue de un sistema de IA de alto riesgo según el artículo 26 del Reglamento de IA: los doce apartados en orden, la evaluación de impacto del artículo 27, cuándo pasa a ser proveedor, y los registros que lleva un sistema ISO 42001
La mayoría de las empresas se encontrarán con el Reglamento de IA como responsables del despliegue: compran o licencian un sistema que otro ha construido y lo utilizan bajo su propia autoridad. Para un sistema de alto riesgo, las obligaciones están en el artículo 26, doce apartados, sin cambios por el ómnibus digital, aplicables desde el 2 de diciembre de 2027 para los sistemas del anexo III. Cada apartado leído en orden, la evaluación de impacto relativa a los derechos fundamentales del artículo 27 y quién la asume, las tres formas en que un responsable del despliegue pasa a ser proveedor según el artículo 25, el derecho a explicación del artículo 86, el techo del artículo 99, y el control ISO 42001 que produce cada registro.
12 de septiembre de 2026
Los nueve lugares en los que el marco de riesgos de TIC de su cliente bancario entra en su producto, RTS 2024/1774: fechas de fin de soporte, informes de vulnerabilidades y seguimiento de bibliotecas, ajustes que no puede eludir, código fuente probado antes de producción, cuentas nominales para su personal, y sus incidentes como sus alarmas
El Reglamento Delegado (UE) 2024/1774, en vigor desde el 15 de julio de 2024, especifica el marco de gestión del riesgo relacionado con las TIC que toda entidad financiera aplica bajo DORA, y nueve de sus artículos nombran al proveedor tercero de servicios de TIC. Leído desde el lado del proveedor: el registro de activos que consigna las fechas de fin de su soporte (artículo 4), el procedimiento de vulnerabilidades que verifica que usted gestiona y notifica vulnerabilidades y sigue las bibliotecas de terceros de su producto (artículo 10), el procedimiento de seguridad de datos y sistemas que reparte funciones entre usted y el cliente y pide medidas sobre su infraestructura (artículo 11), conexiones cifradas sobre redes de terceros (artículo 13), código fuente de proveedores analizado y probado antes de producción (artículo 16), una cuenta única para cada miembro de su personal con acceso (artículo 20), sus notificaciones de incidentes como una de sus fuentes de detección (artículo 23), pruebas de continuidad que incluyen su servicio y su insolvencia (artículos 25 y 26). Con lo que un sistema ISO 27001 ya responde.
12 de septiembre de 2026
NIS2 para mercados en línea, motores de búsqueda y redes sociales: los proveedores digitales del anexo II, y por qué nunca son esenciales por tamaño
Tres definiciones tomadas de otros tres actos deciden si una plataforma es un proveedor digital bajo NIS2: un mercado donde los consumidores celebran contratos a distancia, un motor de búsqueda que busca en principio en todos los sitios web, una plataforma donde los usuarios finales se conectan y comparten. En el ámbito a partir del tamaño mediano, importantes con arreglo al artículo 3(2) por grandes que sean, bajo la ley del establecimiento principal, en el registro de la ENISA, bajo el Reglamento de Ejecución 2024/2690 con sus propios umbrales de incidente en los artículos 11 a 13: sin regla de los 30 minutos, una proporción de usuarios en su lugar.
12 de septiembre de 2026
NIS2 para proveedores de servicios gestionados y MSSP: una entidad del anexo I por definición, y el proveedor en el que aterriza la diligencia de cada cliente
El artículo 6(39) convierte a quien instala, gestiona, explota o mantiene TIC para clientes, in situ o a distancia, en proveedor de servicios gestionados, y el artículo 6(40) convierte a los que ayudan en la gestión de riesgos de ciberseguridad en MSSP. Ambos son tipos del anexo I: importantes en tamaño mediano, esenciales por encima de los límites, bajo la ley del establecimiento principal, en el registro de la ENISA, directamente bajo el Reglamento de Ejecución 2024/2690, con los cuatro umbrales de incidente de su artículo 10. Y el considerando 86 dice a cada cliente esencial e importante que actúe con mayor diligencia al elegirle.
12 de septiembre de 2026
NIS2 para una empresa SaaS: es usted un proveedor de servicios de computación en nube, y esto es lo que sigue
El considerando 33 de la Directiva nombra el software como servicio entre los modelos de servicio en nube, de modo que una empresa SaaS de tamaño mediano o mayor es una entidad de NIS2 como proveedor de servicios de computación en nube: importante por debajo de los límites de las medianas empresas, esencial por encima. Lo que sigue, en el orden en que llega: el Estado de su establecimiento principal, el registro en el que debía estar a más tardar el 17 de enero de 2025, las medidas del Reglamento de Ejecución 2024/2690, los cuatro umbrales de incidente de su artículo 7 y los relojes del artículo 23, y la línea entre todo esto y el CRA.
12 de septiembre de 2026
Normas armonizadas para el CRA: qué pide la solicitud de normalización M/606, para cuándo, y qué tiene hoy un fabricante
El artículo 27 da una presunción de conformidad a los productos que siguen normas armonizadas citadas en el Diario Oficial. El 3 de febrero de 2025 la Comisión pidió 41 de ellas a CEN, CENELEC y ETSI, con plazos del 30 de agosto de 2026 al 30 de octubre de 2027; los tres aceptaron el 3 de abril de 2025. A 12 de septiembre de 2026, el índice de normas armonizadas de la Comisión sigue sin entrada para el Reglamento, lo que para un producto de clase I significa que no hay vía de autoevaluación con arreglo al artículo 32(2). Qué se pidió, las fechas, y contra qué construir mientras tanto.
12 de septiembre de 2026
Transferencias internacionales del RGPD para una empresa de software: las 17 decisiones de adecuación, los cuatro módulos de las CCT, lo que necesita un subencargado estadounidense, británico o indio, y una página que elige el mecanismo
Cada proveedor de alojamiento, servicio de soporte, herramienta de analítica y servicio de nóminas fuera del EEE es una transferencia bajo el capítulo V. La lista de decisiones de adecuación de la Comisión, leída el 12 de septiembre de 2026, tiene 17 entradas: 16 países y territorios, de Andorra a Uruguay, y la Organización Europea de Patentes, con el Reino Unido renovado en diciembre de 2025, Brasil añadido en enero de 2026, y los Estados Unidos cubiertos solo para las empresas certificadas bajo el Data Privacy Framework. Todo lo demás necesita las cláusulas contractuales tipo de la Decisión (UE) 2021/914, cuyos cuatro módulos siguen los roles del exportador y del importador, con la evaluación del derecho local de la cláusula 14 antes de la primera transferencia; las excepciones del artículo 49 son para la ocasión única, nunca para un producto en uso. Leído contra el catálogo, con una página gratuita que elige el mecanismo y lo redacta.
12 de septiembre de 2026
La transposición de NIS2, Estado por Estado: lo que muestra el registro de la propia Comisión
No el rastreador de un despacho: las medidas nacionales que los Estados miembros han comunicado a la Comisión como transposición de la Directiva (UE) 2022/2555, leídas en la Oficina de Publicaciones el 12 de septiembre de 2026. 25 de los 27 Estados han comunicado al menos una, 303 medidas en total; España e Irlanda ninguna; Francia 15 textos, todos anteriores a la Directiva. El acto que cada Estado llama su ley NIS2, cuándo entró en vigor, y qué hace una empresa de software con la respuesta.
12 de septiembre de 2026
¿A qué CSIRT notificar según el artículo 14 del CRA? Los 27 coordinadores, tal como ENISA los publica
Todas las guías sobre la obligación de notificación del Cyber Resilience Act dicen «notifique a su CSIRT nacional» y ahí se quedan. Desde el 10 de septiembre de 2026, ENISA publica el CSIRT designado como coordinador de cada uno de los 27 Estados miembros. Aquí está esa lista, la regla que determina el Estado, y los dos Estados donde el coordinador no es el CSIRT nacional.
11 de septiembre de 2026
CRA anexo I: los 22 requisitos esenciales, como lista de verificación
El anexo I del Reglamento de Ciberresiliencia es lo que su producto debe cumplir desde el 11 de diciembre de 2027 y lo que la documentación técnica debe demostrar. La parte I son 14 requisitos del producto, 13 de ellos «cuando proceda» sobre la base de su evaluación de riesgos; la parte II son 8 requisitos de gestión de vulnerabilidades que se aplican siempre. Aquí están en una sola tabla, con lo que pide cada uno y si puede excluirlo.
11 de septiembre de 2026
¿CRA o NIS2? Cuál se aplica a una empresa de software, y si pueden ser las dos
El Reglamento de Ciberresiliencia regula productos introducidos en el mercado; NIS2 regula entidades que prestan servicios. Una empresa de software puede estar bajo una, la otra, ambas o ninguna, y la respuesta depende de dos preguntas: si introduce un producto en el mercado y si es una entidad mediana o mayor en un sector listado. Las fechas, los relojes de notificación, las multas y la tabla de decisión, a partir de los dos textos.
11 de septiembre de 2026
¿Cuándo empieza el reloj de 24 horas del CRA? «Tener conocimiento», según las orientaciones de la Comisión
Las 24 y las 72 horas corren desde el momento en que el fabricante «tiene conocimiento», y el Reglamento nunca dice qué significa eso. Las orientaciones de la Comisión del 27 de julio de 2026 sí lo dicen, en los apartados 211 a 218: un grado razonable de certeza, tras una evaluación inicial, tomado palabra por palabra del reglamento de ejecución de NIS2 y de las directrices sobre brechas de datos del RGPD. Qué convierte eso en un correo de un cliente, una alerta del escáner, una CVE listada en un componente, un zero-day de bug bounty y una vulnerabilidad que ya conocía antes del 11 de septiembre.
11 de septiembre de 2026
¿Cuándo se «introduce en el mercado» el software según el CRA, y cuál de sus builds es un producto? La regla de las orientaciones para el software independiente
Todo en el CRA pende de una fecha y de un sustantivo: la fecha en que un producto se introduce en el mercado, y si lo que usted entrega es siquiera un producto. Para el software independiente, las orientaciones de la Comisión del 27 de julio de 2026 responden a ambas cosas en los apartados 13 a 21: una versión se introduce en el mercado una sola vez, al ofrecerse por primera vez, y cada descarga posterior cuenta desde ese día; las compilaciones por sistema operativo y los paquetes de funcionalidades son productos distintos; una aplicación web usada en un navegador no es un producto, una extensión de navegador o un cliente instalado sí. Qué significa eso para el 11 de diciembre de 2027, para las betas y para las versiones antiguas que deja en línea.
11 de septiembre de 2026
¿Cuánto dura el período de soporte del CRA? Al menos cinco años, y otros tres relojes que dependen de él
El artículo 13, apartado 8, del Reglamento de Ciberresiliencia exige un período de soporte de al menos cinco años, o el tiempo de uso esperado si es menor, durante el cual se gestionan las vulnerabilidades. Su fecha de fin debe mostrarse en la compra, al menos el mes y el año. Las actualizaciones de seguridad deben seguir disponibles diez años o el período de soporte. Y la documentación técnica, la declaración y la información al usuario se conservan lo mismo. Los cuatro relojes, según el texto.
11 de septiembre de 2026
El Reglamento de Ciberresiliencia para un pequeño fabricante de software, en doce pasos
Todo lo que una empresa de diez personas que entrega software instalado o un dispositivo tiene que hacer según el CRA, en el orden en que hacerlo: la determinación del ámbito, el nivel, el CSIRT y la autoridad de aplicación, el procedimiento de notificación que se aplica desde el 11 de septiembre de 2026, y después la documentación técnica, los 22 requisitos, la SBOM, el período de soporte, el marcado CE y la declaración, con plazo el 11 de diciembre de 2027. Cada paso con su artículo y el texto que lo explica.
11 de septiembre de 2026
El reloj del informe final del CRA no empieza cuando usted tiene conocimiento
La mayoría de los textos sobre el artículo 14 del Reglamento de Ciberresiliencia dan tres plazos desde un único punto de partida: 24 horas, 72 horas, 14 días. Los dos primeros corren desde el conocimiento. El tercero no, y para una vulnerabilidad su punto de anclaje es una fecha que puede no existir todavía. Aquí está lo que dice el Reglamento, apartado por apartado.
11 de septiembre de 2026
¿Es su producto importante o crítico según el Reglamento de Ciberresiliencia? Los anexos III y IV completos
Una vez que un producto está en el ámbito del CRA, es por defecto, importante (clase I o II) o crítico, y el nivel decide si puede autoevaluarse o necesita un organismo notificado. Aquí están las 19, 4 y 3 categorías tal cual en el Diario Oficial, lo que cambia cada nivel según el artículo 32, y lo único que el nivel no cambia.
11 de septiembre de 2026
¿Es su proyecto de código abierto «comercial» según el CRA? Las siete pruebas de la Comisión, con sus ejemplos
El CRA alcanza al software libre y de código abierto solo cuando se suministra en el marco de una actividad comercial, y el Reglamento deja «comercial» en manos de dos considerandos. Las orientaciones de la Comisión del 27 de julio de 2026, sección 3, las convierten en siete pruebas: un precio, una edición de pago u open core, monetizar otros servicios o datos personales, servicios de soporte, donaciones, patrocinio y la condición sin ánimo de lucro, con 22 ejemplos. Dónde acaban un mantenedor, una empresa open core y una fundación, y en qué le convierte una pull request.
11 de septiembre de 2026
¿Está su producto en el ámbito del Reglamento de Ciberresiliencia? Dónde queda el SaaS
La pregunta más frecuente sobre el CRA no es cómo notificar, sino si el Reglamento se le aplica siquiera. El software como servicio puro queda fuera y dentro de NIS2; el software instalado y descargable queda dentro; el tratamiento a distancia sin el que un producto no funciona vuelve a quedar dentro. La determinación es suya y debe dejarla por escrito. Aquí está el texto que la decide.
11 de septiembre de 2026
¿Exige el CRA una SBOM? Sí, y esto es exactamente lo que dice
El anexo I, parte II, punto 1 del Reglamento de Ciberresiliencia exige una lista de materiales de software en un formato de uso común y legible por máquina que cubra al menos las dependencias de primer nivel. Va en la documentación técnica, no se publica, y una autoridad de vigilancia del mercado puede pedirla previa solicitud motivada. Las tres frases que lo deciden, y lo que dejan abierto.
11 de septiembre de 2026
La autoevaluación según el CRA: lo que el módulo A exige realmente, según el anexo VIII y las FAQ de la Comisión
La mayoría de los productos de software nunca verán un organismo notificado. Usan el módulo A, el procedimiento de control interno del anexo VIII, y «autoevaluación» es la palabra que todo el mundo emplea sin decir qué contiene. El anexo VIII, parte I, son cinco puntos; las FAQ de la Comisión añaden la lista de actividades, el hecho de que no se impone ninguna metodología de ensayo, dónde lleva un producto de software su marcado CE, las dos formas de la declaración de conformidad, y el calendario de las normas armonizadas que decide cuándo la autoevaluación deja de significar «directamente contra el anexo I».
11 de septiembre de 2026
La evaluación de riesgos de ciberseguridad del CRA: lo que el artículo 13 exige realmente, y el único resultado que debe producir
El artículo 13, apartados 2 a 4, del Reglamento de Ciberresiliencia convierte la evaluación de riesgos en el documento del que cuelga cualquier otra obligación del CRA. Debe analizar los riesgos a partir de la finalidad prevista, el uso previsible y las condiciones de uso durante el tiempo de uso esperado; decir si y cómo se aplica cada requisito del punto 2 de la parte I; decir cómo se aplican el punto 1 de la parte I y la parte II; estar documentada, mantenida al día durante el período de soporte e incluida en la documentación técnica, con una justificación clara de cada requisito excluido. Los cuatro apartados, y una estructura de una página que los satisface.
11 de septiembre de 2026
La política de divulgación coordinada de vulnerabilidades que exige el CRA: tres disposiciones, y una política de una página que las cumple
El anexo I, parte II, punto 5, del Reglamento de Ciberresiliencia exige a todo fabricante en el ámbito establecer y aplicar una política de divulgación coordinada de vulnerabilidades. El artículo 13, apartado 17, exige un punto de contacto único para las notificaciones, fácil de encontrar y no limitado a herramientas automatizadas; el anexo II, punto 2, exige el contacto y la ubicación de la política en la información al usuario; el anexo VII, punto 2, letra b), pone ambos en la documentación técnica. Qué pide cada disposición, qué debe decir una política y qué no debe prometer.
11 de septiembre de 2026
La propia maquinaria del CRA de la UE, el día en que empezó la obligación: 0 organismos notificados, 0 normas armonizadas, 7 de 27 autoridades de aplicación
El Reglamento de Ciberresiliencia pide a los fabricantes que estén preparados. Aquí está lo preparadas que estaban las instituciones de las que depende el 11 y el 12 de septiembre de 2026, leído en los propios registros de la Comisión: ningún organismo de evaluación de la conformidad notificado con arreglo al CRA, ninguna norma armonizada publicada en el Diario Oficial, siete Estados miembros con una autoridad de vigilancia del mercado registrada, trece con una autoridad notificante, y la lista de CSIRT coordinadores publicada la víspera, con dos Estados que nombran un organismo distinto de su CSIRT nacional. Qué significa para un fabricante con un producto de clase I, y qué registrar.
11 de septiembre de 2026
¿Necesita el software marcado CE según el CRA? Sí, y el artículo 30 dice dónde va
Desde el 11 de diciembre de 2027 se exige un marcado CE en todo producto con elementos digitales introducido en el mercado de la UE, software incluido. Para el software, el marcado va en la declaración UE de conformidad o en el sitio web que acompaña al producto, antes de introducirlo en el mercado. Qué afirma el marcado, quién puede colocarlo, cuándo se le añade el número de un organismo notificado y qué debe contener la declaración que lo sustenta.
11 de septiembre de 2026
NIS2 o CRA: qué reloj de incidentes corre para una empresa de software, y qué hace 'significativo' un incidente
Ambas normas le dan 24 horas, 72 horas y un mes, y ambas ponen en marcha el reloj cuando usted 'tiene constancia'. Casi todo lo demás difiere: qué lo activa, quién lo recibe, en qué plataforma y qué cuenta. El artículo 23 de NIS2 y el Reglamento de Ejecución 2024/2690 para la empresa que opera un servicio en la nube; el artículo 14 del CRA para la empresa que entrega un producto; ambos para la empresa que hace las dos cosas. Los umbrales, criterio por criterio, y un solo procedimiento que satisface a los dos.
11 de septiembre de 2026
Por defecto, importante o crítico: las 26 descripciones técnicas del Reglamento de Ejecución 2025/2392, y la prueba de la funcionalidad principal
Los anexos III y IV del CRA nombran 26 categorías de productos en una línea cada una. El Reglamento de Ejecución (UE) 2025/2392 de la Comisión, en vigor desde el 21 de diciembre de 2025, describe cada una técnicamente, y las orientaciones de la Comisión del 27 de julio de 2026 dicen cómo clasificar frente a ellas: por la funcionalidad principal del producto, no por lo que además hace ni por lo que integra. Las 26 descripciones literalmente, las seis reglas de las orientaciones con sus ejemplos (un SOAR no es un SIEM, un visor de registros no es un SIEM, un router con cortafuegos es un router), y qué cambia la clasificación.
11 de septiembre de 2026
Cómo presentar una notificación CRA en la plataforma única de ENISA, según su propio manual
La plataforma abrió el 11 de septiembre de 2026 en portal.cra-srp.enisa.europa.eu. Quién puede iniciar sesión, qué coordinador elegir, qué pide cada una de las tres presentaciones, qué calcula mal el contador de la propia plataforma y cuándo puede pedir que se retrase la difusión. Leído en las guías, las FAQ, el glosario y las condiciones de uso de ENISA, no en un resumen de ellos.
11 de septiembre de 2026
¿Qué actualización somete su software existente al CRA? Las modificaciones sustanciales, según las orientaciones de la Comisión
El software introducido en el mercado antes del 11 de diciembre de 2027 queda fuera de las obligaciones de diseño y conformidad del CRA hasta que se modifica sustancialmente. Las orientaciones de la Comisión del 27 de julio de 2026 dicen qué significa eso para una actualización de software en los apartados 103 a 113 y 122 a 124, con once ejemplos resueltos: un riesgo que no está en su evaluación de riesgos, no el tamaño del diff. Las actualizaciones de seguridad quedan en general fuera; una casilla de «recordarme» puede quedar dentro. Qué escribir en cada versión, y qué desencadena y qué no la primera modificación sustancial.
11 de septiembre de 2026
Qué contiene la documentación técnica del CRA: el anexo VII, punto por punto
Desde el 11 de diciembre de 2027, todo producto con elementos digitales introducido en el mercado de la UE necesita documentación técnica antes de introducirse, conservada diez años o durante el período de soporte, lo que sea más largo. El anexo VII dice qué contiene en ocho puntos. Aquí están, lo que cada uno pide realmente, los cuatro documentos que presupone la parte II del anexo I, y cuánto tiempo la conserva.
11 de septiembre de 2026
Qué le pide el CRA por sus dependencias: diligencia debida, notificación aguas arriba y vulnerabilidades explotables conocidas, según las orientaciones de la Comisión
Un producto de software es sobre todo código de otros. El CRA hace al fabricante responsable del producto en su conjunto y le impone tres deberes hacia los componentes que contiene: diligencia debida según el artículo 13(5), notificar vulnerabilidades aguas arriba y compartir correcciones según el artículo 13(6), e introducir el producto en el mercado sin vulnerabilidades explotables conocidas. Las orientaciones de la Comisión del 27 de julio de 2026, secciones 3.4, 7.3 y 9.2, dicen qué exige cada uno y qué no: ni notificaciones duplicadas, ni obligación de que acepten su corrección, y una definición de «conocida» que incluye la base de datos CVE y la prensa.
11 de septiembre de 2026
¿Qué partes de su backend están dentro del CRA? El tratamiento remoto de datos, según las orientaciones de la Comisión
Un producto con elementos digitales incluye sus soluciones de tratamiento remoto de datos, y el Reglamento las define en una frase. Las orientaciones de la Comisión del 27 de julio de 2026 convierten esa frase en dos pruebas acumulativas, una regla de delimitación, una lista de lo que nunca entra (CI/CD, RR. HH., CRM, telemetría, sitios web), los casos SaaS, PaaS e IaaS, y un ejemplo de banca móvil resuelto de principio a fin. Para una empresa de software con una app y una nube, esta es la línea.
11 de septiembre de 2026
Qué pide el CRA a importadores y distribuidores, y cuándo los convierte en fabricante
Si revende software o dispositivos en la UE en lugar de construirlos, los artículos 19 y 20 del Reglamento de Ciberresiliencia le dan una lista de comprobación que recorrer antes de poner el producto a la venta, el deber de transmitir las vulnerabilidades al fabricante, el deber de informar a las autoridades de los riesgos significativos y diez años de conservación de registros. El artículo 21 le convierte en fabricante en cuanto vende bajo su propia marca o modifica sustancialmente el producto. Las obligaciones, según el texto.
11 de septiembre de 2026
Qué tiene que notificar según el CRA: los dos desencadenantes, tal como los define el Reglamento
El artículo 14 tiene dos desencadenantes y ambos están definidos en el texto. Una vulnerabilidad explotada activamente es aquella respecto de la cual existen pruebas fiables de que un agente malicioso la ha explotado en un sistema sin permiso del propietario (artículo 3, punto 42). Un incidente grave es el que afecta, o puede afectar, a la capacidad del producto de proteger datos o funciones sensibles, o el que conduce, o puede conducir, a código malicioso en el producto o en los sistemas de un usuario (artículo 14, apartado 5). Qué entra, qué no, y el deber de informar a los usuarios que acompaña a ambos.
11 de septiembre de 2026
¿Quién aplica el Reglamento de Ciberresiliencia en su Estado miembro? 7 de 27 lo han dicho
El CRA se aplica a nivel nacional, por una autoridad de vigilancia del mercado que cada Estado miembro designa y registra ante la Comisión. El 11 de septiembre de 2026, el día en que empezó a aplicarse la obligación de notificación, siete Estados habían registrado una. Aquí está el registro, Estado por Estado, incluidos los veinte que no lo han hecho, y qué significa para un pequeño fabricante que se pregunta quién vendrá a llamar a su puerta.
11 de septiembre de 2026
¿Se aplica el CRA al software de código abierto? Tres casos, y el régimen ligero de los administradores
El Reglamento de Ciberresiliencia alcanza al software libre y de código abierto solo cuando se suministra en el marco de una actividad comercial. Un proyecto no monetizado queda fuera. Una empresa que entrega un producto construido sobre componentes de código abierto es fabricante de ese producto. Y las fundaciones y empresas que sostienen productos de código abierto destinados a uso comercial son «administradores de software de código abierto» según el artículo 24: una política de ciberseguridad, cooperación con las autoridades y una obligación de notificación reducida, sin marcado CE ni documentación técnica. Los considerandos y el artículo, citados.
11 de septiembre de 2026
Sanciones del Reglamento de Ciberresiliencia: a qué está expuesto realmente un pequeño fabricante
El CRA fija tres tramos de multa, hasta 15 millones de EUR o el 2,5% del volumen de negocios mundial. Aquí está qué obligaciones caen en qué tramo, quién hace cumplir el texto, y los dos lugares donde el reglamento nombra a los pequeños fabricantes.
8 de septiembre de 2026
Cómo responder un cuestionario de seguridad desde su SGSI ISO 27001: 30 temas de preguntas mapeados a los controles del Anexo A que los responden
Casi todos los cuestionarios de seguridad que recibe una empresa europea preguntan por los mismos 30 temas. Aquí está el mapa de cada tema a los controles del Anexo A de ISO 27001 de los que realmente trata, y los cuatro registros que toda respuesta debería llevar.
3 de septiembre de 2026
Qué países de la UE nombran ISO 27001 en las licitaciones públicas: 1.548 anuncios alemanes, 829 polacos, y Grecia tiene la mayor cuota
En 365 días, ISO 27001 aparece en 3.415 anuncios de TED. Alemania y Polonia suman el 70% de ellos, Grecia la nombra en el 2% de todo lo que compra, y Francia, España e Italia apenas la nombran. Aquí está la tabla, la consulta y lo que significan las cifras.
3 de septiembre de 2026
Certificación ISO 27001 más barata: cómo comparar presupuestos sin comprar un certificado sin valor
Los presupuestos de los organismos de certificación varían, pero los días de auditor que hay detrás los fija el Anexo B de ISO/IEC 27006. Aquí está cómo leer un presupuesto, y la única comprobación que importa más que el precio.
20 de agosto de 2026
Certificación ISO 42001: qué es, y si es pronto
ISO/IEC 42001 es la norma de sistemas de gestión de la IA. Aquí está lo que pide, cómo se relaciona con una ISO 27001 existente, y una lectura honesta de la demanda actual.
20 de agosto de 2026
Cómo obtener la certificación ISO 27001 para una empresa, en el orden en que ocurre de verdad
El camino desde nada hasta un certificado, qué ocurre en la fase 1 y la fase 2, y los registros que un auditor pide en cada punto.
20 de agosto de 2026
Coste de implantación de ISO 27001: la cifra a tres años, no la primera factura
La certificación funciona en un ciclo de tres años con auditorías de seguimiento cada año. Presupuestar solo la primera auditoría es la forma más común de que el total sorprenda.
20 de agosto de 2026
Coste de la certificación ISO 27001 para una empresa, según la plantilla
Los días de auditor salen de la tabla del Anexo B de ISO/IEC 27006, así que el coste de la certificación sigue más a la plantilla que al sector. Aquí está la aritmética, y las partidas que la gente olvida.
20 de agosto de 2026
Implantar ISO 27001 sin consultores: lo que asume, y lo que ellos hacían a cambio del dinero
Es perfectamente posible certificarse sin consultor. Merece la pena saber antes lo que está absorbiendo, y qué partes se benefician de verdad de alguien que se ha sentado al otro lado de la mesa.
20 de agosto de 2026
ISO 27001 frente a NIS2: lo que cubre el certificado y lo que no
NIS2 es ley e ISO 27001 es una norma certificable, así que no son alternativas. Aquí está dónde un SGSI existente satisface los requisitos de la directiva, y los dos lugares donde no.
20 de agosto de 2026
La forma más barata de obtener ISO 27001, y la parte que no puede abaratar
La mayor parte de un presupuesto ISO 27001 son días de auditor, y esos los fija una tabla publicada y no una negociación. Aquí está lo que mueve la cifra de verdad, y lo que no.
20 de agosto de 2026
Lista de verificación de cumplimiento ISO 27001, por cláusula
Una lista de verificación que sigue la propia estructura de la norma: las cláusulas 4 a 10 y lo que cada una le pide poder demostrar, más lo que añade el Anexo A.
20 de agosto de 2026
Mejor software de cumplimiento ISO 27001: qué preguntar antes de comparar funciones
El número de integraciones es fácil de comparar y rara vez decide una auditoría. Aquí están las preguntas que sí lo hacen, incluida la que la mayoría de los proveedores no responderá por escrito.
20 de agosto de 2026
Cuántos días de auditor lleva una certificación ISO 27001, según la plantilla
Los organismos de certificación no publican precios, pero los días de auditoría los fija el Anexo B de ISO/IEC 27006. Aquí está la aritmética que convierte su plantilla en una cifra antes de que nadie le pase un presupuesto.
11 de agosto de 2026
ISO 27001 vs SOC 2 en Europa: qué piden realmente los compradores
Si vende en Europa, consiga ISO 27001: las licitaciones públicas de la UE la mencionaron 3.408 veces en un año, frente a 104 de SOC 2. Si vende a clientes estadounidenses, es al revés. Las cifras, la consulta pública de TED para repetirlas, y cuándo necesita ambas.
11 de agosto de 2026