[{"data":1,"prerenderedAt":10},["ShallowReactive",2],{"article:es:iso-9001-para-una-empresa-de-software-que-significa-el-apartado-8-cuando-el-producto-es-codigo-subapartado-por-subapartado":3},{"locale":4,"slug":5,"title":6,"description":7,"published":8,"body":9},"es","iso-9001-para-una-empresa-de-software-que-significa-el-apartado-8-cuando-el-producto-es-codigo-subapartado-por-subapartado","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.","2026-09-12","\nUna empresa de software que tiene ISO 27001 y lee ISO 9001 por primera vez reconoce la mayor parte. Contexto, liderazgo, planificación, apoyo, evaluación del desempeño y mejora, los apartados 4 a 7, 9 y 10, son la Estructura Armonizada: el mismo esqueleto con «calidad» donde la otra norma dice «seguridad de la información». Luego llega al apartado 8, Operación, y encuentra producción, trazabilidad, preservación de las salidas y la propiedad de los clientes, escritos para organizaciones que fabrican y envían cosas. La tentación es declarar la mayor parte no aplicable. Es la lectura equivocada: el apartado 8 se aplica por completo al software, solo necesita traducción, y la traducción es lo que hace este artículo, subapartado por subapartado, en nuestra lectura del texto; la redacción de ISO no se reproduce. En [nuestro propio registro de apartados](\u002Fiso-9001), el apartado 8 es donde están las carencias honestas, y la traducción de abajo es lo que esos registros tendrían que contener.\n\n## 8.1 Planificación y control operacional\n\nEl apartado pide a la organización planificar y controlar los procesos que entregan sus productos y servicios: criterios para los procesos y para la aceptación, los recursos, y suficiente información documentada para tener confianza en que los procesos se ejecutaron según lo planificado. Para software, esto es la definición de cómo una funcionalidad viaja de la petición a producción, y los criterios de aceptación en cada paso. Es también el único lugar donde el apartado 8 menciona los procesos contratados externamente, que para una empresa de software es la plataforma en la nube en la que se ejecuta.\n\n## 8.2 Requisitos para los productos y servicios\n\n8.2.1 es la comunicación con el cliente: cómo un cliente sabe qué hace el producto, cómo pide, cómo reclama, y cómo se trata su propiedad (datos, en el caso de una empresa de software). 8.2.2 es la determinación de los requisitos: qué debe hacer el producto, incluidos los requisitos legales y reglamentarios que se le aplican. 8.2.3 es la revisión de esos requisitos antes de que la organización se comprometa a suministrar, con los resultados conservados, y es el subapartado en el que las empresas de software fallan con más frecuencia: un contrato firmado con un compromiso específico para el cliente que nadie de ingeniería revisó es una no conformidad respecto a 8.2.3, logren lo que logren los ingenieros después. 8.2.4 es los cambios en los requisitos, que en un producto por suscripción es cada nota de versión.\n\nPara una empresa de software, «requisitos legales y reglamentarios» tiene ahora un contenido concreto: desde el 11 de diciembre de 2027, los requisitos esenciales del [anexo I del Cyber Resilience Act](\u002Farticles\u002Fcra-annex-i-the-22-essential-requirements-as-a-checklist) son requisitos para el producto en el sentido de 8.2.2, y una revisión de requisitos que no los considere está incompleta.\n\n## 8.3 Diseño y desarrollo\n\nEste es el ciclo de vida del desarrollo de software, y el subapartado que se corresponde más directamente. 8.3.2, la planificación, es la definición del proceso: etapas, revisiones, verificación y validación, responsabilidades, en qué participa el cliente, y la información documentada que conservar. 8.3.3, las entradas, son los requisitos de los que parte un trabajo, incluidos los legales y reglamentarios y lo aprendido de productos anteriores. 8.3.4, los controles, es la distinción que traza la norma y que los equipos de ingeniería suelen difuminar: revisiones (¿cumple el diseño el plan?), verificación (¿cumple la salida los requisitos de entrada?, es decir, la revisión de código y la batería de pruebas) y validación (¿cumple el producto su uso previsto?, es decir, la aceptación por el usuario o en su nombre). 8.3.5, las salidas, es lo que sale del desarrollo: el artefacto, su documentación, los criterios de aceptación con los que se comprobó. 8.3.6, los cambios, es el control de cambios del diseño, con la revisión, la autorización y cualquier acción para prevenir efectos adversos, conservados.\n\nUna empresa que lleva su trabajo en un sistema de tickets, revisa código, ejecuta pruebas y tiene una definición de hecho tiene la mayoría de los registros que pide 8.3. Lo que suele faltarle es el registro que los enlaza por cambio: qué entrada, qué revisión, qué verificación, qué validación, quién autorizó.\n\n## 8.4 Procesos, productos y servicios suministrados externamente\n\n8.4.1 pide que los proveedores externos se evalúen, seleccionen, hagan seguimiento y reevalúen, con registros; 8.4.2 que el tipo y alcance del control correspondan a cuánto afecta al producto la salida del proveedor; 8.4.3 que se comunique al proveedor lo que se le exige. Para software, los proveedores externos son de tres clases: la plataforma en la nube y las herramientas SaaS en las que se ejecuta el producto, procesos contratados externamente bajo 8.4.1; los componentes de código abierto y comerciales del producto, productos suministrados externamente; y los contratistas que escriben código. La segunda clase es donde 8.4 y el Cyber Resilience Act se encuentran: [la diligencia debida que el artículo 13(5) pide sobre los componentes](\u002Farticles\u002Fwhat-the-cra-asks-of-you-for-your-dependencies-due-diligence-reporting-upstream-and-known-exploitable-vulnerabilities) es el control 8.4.2 de una dependencia de software, y el mismo registro sirve a ambos.\n\n## 8.5 Producción y provisión del servicio\n\nEl subapartado con más que traducir. 8.5.1, condiciones controladas, es el despliegue: el proceso documentado, el seguimiento en las etapas que importan, la infraestructura y el ambiente, personas competentes, y la validación de los procesos cuya salida no puede verificarse después, que en una empresa de software es la propia canalización de despliegue. 8.5.2, identificación y trazabilidad, son las versiones y los identificadores de compilación: qué compilación está en producción, qué cliente ejecuta qué versión, y la capacidad de rastrear una salida a través de su historial cuando la trazabilidad sea un requisito. 8.5.3, la propiedad perteneciente a los clientes o proveedores externos, es el subapartado que una empresa SaaS debe leer con más cuidado: los datos, las credenciales y los contenidos de los clientes son propiedad del cliente en el sentido de la norma, que hay que identificar, verificar, proteger y salvaguardar, y una pérdida o daño se comunica al cliente con el registro conservado. 8.5.4, preservación, son las copias de seguridad y la integridad del artefacto entregado. 8.5.5, actividades posteriores a la entrega, es el soporte, el mantenimiento y las actualizaciones durante el tiempo que la organización se haya comprometido, que bajo el Cyber Resilience Act se convierte en [el período de soporte](\u002Farticles\u002Fhow-long-is-the-cra-support-period) con actualizaciones de seguridad durante toda su duración. 8.5.6, control de los cambios, es el control de cambios en producción, con la revisión, la persona que autoriza y cualquier acción, conservados.\n\n## 8.6 Liberación de los productos y servicios\n\nLa liberación solo se produce cuando se han completado las disposiciones planificadas, salvo aprobación en contrario de una autoridad pertinente y, cuando sea aplicable, del cliente; el registro muestra la evidencia de conformidad con los criterios de aceptación y quién autorizó la liberación. Para software, esto es la puerta de liberación: los criterios con los que se comprobó la compilación, la evidencia, y la persona designada que la dejó salir. Una empresa que despliega de forma continua sigue teniendo una liberación en el sentido de la norma en cada despliegue, y la puerta son las comprobaciones de la canalización más la aprobación que deja pasar un cambio; el registro es el diario de la canalización, siempre que nombre los criterios y al aprobador.\n\n## 8.7 Control de las salidas no conformes\n\nUna salida que no es conforme se identifica y controla para que no se entregue ni se use de forma no intencionada: se corrige, se separa, se informa al cliente, o se obtiene una concesión; y el registro dice cuál fue la no conformidad, qué se hizo, cualquier concesión y quién decidió. Para software, las salidas no conformes son los errores que llegaron a un cliente, los incidentes, la versión que hubo que retirar. El gestor de errores ya contiene la mayor parte del registro; lo que 8.7.2 añade es la decisión, en particular la concesión, es decir, la decisión de entregar o dejar un defecto conocido, tomada por alguien con autoridad para hacerlo. Un defecto conocido entregado sin esa decisión es la no conformidad que un auditor anota, no el defecto en sí.\n\n## Lo que suma todo esto\n\nLeído así, el apartado 8 para una empresa de software son seis registros que la empresa ya produce en su mayoría en sus herramientas de tickets, revisión de código, integración continua e incidentes, más las decisiones que esas herramientas no registran: la revisión de requisitos antes de un compromiso, la autorización de un cambio de diseño, la aprobación de la liberación y la concesión sobre un defecto conocido. La tarea del sistema de gestión es mantener esas decisiones junto a los artefactos, para que un auditor, o el auditor de un cliente, pueda seguir un cambio de la petición a la liberación con cada comprobación y cada nombre en su sitio. [Para qué subapartados del apartado 8 StandardOS mantiene registros, y para cuáles no, está publicado apartado por apartado](\u002Fiso-9001); los demás apartados, [la información documentada](\u002Farticles\u002Fdoes-iso-9001-2015-require-a-quality-manual-what-clause-7-5-asks-for-instead-the-21-places-the-standard-names-documented-information-and-what-a-manual-is-for-today) y [la revisión por la dirección](\u002Farticles\u002Fthe-iso-9001-management-review-the-13-inputs-and-3-outputs-of-clause-9-3-as-an-agenda-where-each-input-comes-from-and-what-the-minutes-have-to-show) entre ellos, son los que una empresa ISO 27001 ya gestiona.\n\n## Fuentes\n\n- ISO 9001:2015, apartados 8.1 a 8.7, citados por número; el texto es de ISO y no se reproduce.\n- Reglamento (UE) 2024\u002F2847 (CRA), artículo 13(5) y (8), anexo I, para dónde se exigen los mismos registros a un producto de software.\n\nEsto no es asesoramiento de certificación. Hasta dónde se aplica un subapartado a un producto concreto se decide en el alcance de la organización y se justifica allí; la traducción de arriba es nuestra.\n",1789383968033]