¿El desarrollo de software cae bajo NIS2?
El desarrollo de software como actividad no aparece en los anexos de la Directiva NIS2 con esas palabras exactas. No existe un sector llamado "constructores de software". Lo que sí aparece son categorías relacionadas: la computación en la nube y los servicios en la nube caen bajo infraestructura digital, y los servicios de TIC gestionados y los servicios de seguridad gestionados caen bajo servicios de TIC. Si desarrolla software personalizado para clientes sin prestar usted mismo un servicio en la nube o un servicio gestionado, es probable que no caiga directamente bajo la Directiva.
Eso no significa que el desarrollo de software quede fuera de la imagen. Tres cosas determinan en conjunto dónde se encuentra usted: la naturaleza exacta de lo que entrega (sector), el tamaño de su organización y la cuestión de si sus clientes son en sí mismos sujetos obligados. Este último aspecto afecta en la práctica a muchos más desarrolladores que el primero.
Sector: lo que los anexos mencionan y lo que no
La Directiva distingue entre sectores esenciales (Anexo I) e importantes (Anexo II). La infraestructura digital y los servicios de TIC figuran en el Anexo I, y esta última categoría se refiere específicamente a partes que gestionan o supervisan el entorno de TIC de terceros — piense en proveedores de servicios gestionados. Si entrega un producto SaaS en el que usted gestiona la infraestructura para los clientes, u ofrece junto con su software también gestión, supervisión u hospedaje, se acerca a esa categoría. Si solo entrega una aplicación que el cliente gestiona y hospeda por sí mismo, es diferente.
La clasificación es menos una cuestión de cómo se llame a sí mismo y más de lo que realmente hace por el cliente. Dos empresas que se llamen ambas "desarrollador de software" pueden tener resultados diferentes en cuanto una de ellas también asume la gestión. Una prueba estructurada a lo largo del sector, tamaño y posición en la cadena proporciona una claridad más rápida que una conversación suelta sobre listas de verificación. en unas pocas preguntas, ver dónde se encuentra su empresa
Tamaño: el umbral también se aplica si el sector coincide
Incluso si su actividad cae dentro de una categoría mencionada, hay umbrales de tamaño: la Directiva distingue entre empresas medianas y grandes, con un resultado diferente para organizaciones más pequeñas. Un pequeño equipo de desarrollo que, por casualidad, también ofrece hospedaje, no cae automáticamente en la misma categoría que un gran proveedor de servicios en la nube. Los límites exactos y las excepciones que existen se encuentran en la Directiva y su transposición nacional; no se trata de algo sobre lo que deba decidir basándose en una regla empírica.
Posición en la cadena: afectado sin ser sujeto obligado en sí mismo
Aquí está el lado práctico de la historia para la mayoría de empresas de software. La obligación de diligencia (artículo 21) requiere que las entidades esenciales e importantes también evalúen la seguridad de sus proveedores. Si desarrolla software para un hospital, una empresa energética o un municipio, es probable que ese cliente le envíe un cuestionario de seguridad sobre su proceso de desarrollo — independientemente de la cuestión de si usted mismo cae bajo la Directiva.
Esos cuestionarios rara vez se refieren a principios de política abstracta. Preguntan concretamente cómo identifica y remedia vulnerabilidades, cómo llegan los parches al cliente, y quién dentro de su empresa tiene acceso al código fuente y al entorno de producción. Quien recibe tales preguntas por primera vez, a menudo lo experimenta como una sorpresa que pone el contrato bajo presión; con un conjunto de respuestas fijas, la segunda vez va considerablemente más rápido. los temas seleccionados según cada situación
Dos capas de seguridad: el producto y la línea de desarrollo
En el desarrollo de software se solapan dos preguntas, y es útil mantenerlas separadas. La primera se refiere a qué construye: ¿existe un proceso para identificar y resolver vulnerabilidades en el código, se realiza un seguimiento de las dependencias y bibliotecas, y con qué rapidez llega una actualización de seguridad al cliente? La segunda se refiere a cómo construye: ¿quién tiene acceso al repositorio de código fuente, cómo está asegurada la canalización de CI/CD, y quién puede implementar realmente en producción?
Un cuestionario de seguridad de un cliente suele afectar ambas capas simultáneamente, incluso si el cliente no las distingue explícitamente. Los reguladores y clientes observan en este tipo de preguntas si existe un proceso reconocible y si ese proceso está documentado, no solo la intención detrás de él.
Lo que puede hacer ahora
Si el desarrollo de software en su caso cae bajo NIS2 depende del servicio exacto que proporciona, el tamaño de su organización y el sector en el que operan sus clientes. No existe un "sí" o "no" inequívoco para todo el sector, y la evaluación final de su situación corresponde a un abogado o a la autoridad reguladora, no a un artículo de blog.
Lo que sí puede hacer es: determinar en cuál de las tres posiciones se encuentra —obligado por ley, afectado a través de un cliente, o aún no afectado— y desde ahí establecer qué preguntas puede esperar. Más información sobre cómo se realiza esta clasificación y de dónde proceden las fuentes utilizadas, puede leerlo en la página sobre la metodología. Si desea hacer esa primera clasificación para su propia empresa, puede completarla en unos minutos, sin necesidad de crear una cuenta. las preguntas más frecuentes sobre la clasificación proporcionan una perspectiva adicional sobre cómo otras empresas de desarrollo se enfrentan a la misma pregunta.