PREGUNTAS FRECUENTES

En términos simples, un sistema de gestión de la calidad es un conjunto de procesos y funciones comerciales dirigidos a la mejora continua de la calidad para garantizar que se cumplan o superen las expectativas y los requisitos del cliente.

Expresado como un marco de estructuras, métodos, técnicas, políticas, procedimientos, procesos y recursos organizados, los sistemas de gestión de la calidad también son métodos por los que las empresas pueden garantizar responsabilidades, horarios, relaciones, contratos y acuerdos a la par con el medio ambiente, los alimentos y estándares de seguridad del producto.

Cada empresa tiene su propio conjunto único de productos, objetivos, valores y creencias. Los sistemas de gestión de calidad deberían abarcar y reflejar esas diferencias. Para que esto sea posible, existen muchos tipos diferentes de sistemas de gestión de la calidad, cada uno con su propio conjunto de ventajas, desventajas y capacidades. Los siguientes son los más comúnmente usados.

Los sistemas estandarizados son cualquier sistema de gestión de calidad que sigue un conjunto de códigos y regulaciones federales. Estos incluyen certificaciones ISO, como ISO 9000/9001, ISO 13485, ISO 14000/14001, ISO 14971, ISO 17025, ISO 22000, HACCP, TS 16949; TL 9000; AS 9100; cGxP, 21 CFR Parte 11, QSR Título 21 Parte 820, A2LA u OHSAS 18001. Las organizaciones que intentan seguir estos estándares deben cumplir con todos los criterios y aprobar auditorías detalladas. En algunas industrias, es un requisito. En otros, puede proporcionar beneficios específicos que apelan a los objetivos y objetivos generales de la empresa.

TQM es un enfoque de gestión en el que se enfatiza la calidad en todos los aspectos de un negocio. Los objetivos se centran en el desarrollo a largo plazo de productos y servicios de calidad al descomponer cada proceso y actividad individual para determinar si contribuye o menoscaba los objetivos de productividad y calidad de la empresa. Los procesos y funciones desviados están alineados con los objetivos, valores y creencias de la empresa a través del desarrollo de estrategias flexibles.

CQI es un sistema de calidad que nunca está satisfecho. Su enfoque de mejora continua y constante se centra menos en los procesos y funciones y pone más énfasis en el rol que juegan los equipos y las personas en el camino hacia la calidad. Las recompensas son una parte integral de este sistema de gestión de calidad. Su enfoque de “Planificar, Hacer, Verificar, Actuar” se ha adaptado para adaptarse a muchas industrias y compañías, incluidas aquellas que no pueden usar CQI como su único o principal sistema de gestión de calidad.

Six Sigma es un enfoque y una metodología disciplinados basados en datos que apunta a la perfección en la calidad. Se centra en el proceso de mejora y reducción de la desviación mediante la aplicación de procesos específicamente definidos: definir, medir, analizar, mejorar y controlar. Utilizado por compañías multimillonarias como Motorola y General Electric, las aspirantes a negocios de Six Sigma generalmente se someten a procesos de capacitación intensivos y especializados para aprender cómo funciona este QMS.

No. La redacción del Reglamento General de Protección de Datos no especifica ni impone ningún sistema de certificación en , pero sí fomenta la certificación voluntaria ante organismos sectoriales u organizaciones que cumplan la norma EN-ISO/IEC 17065/2012 y que tengan la autorización de las autoridades de control correspondientes, como la Information Commissioner’s Office (ICO) en el Reino Unido o la Agencia Española de Protección de Datos (AEPD) en el caso de España.

Si bien se fomenta la certificación RGPD como garantía de las medidas de seguridad técnicas y organizativas, entre otras cosas, su obtención tiene especial importancia para las terceras empresas que procesan datos en nombre de otros. Para ello, el grupo de trabajo denominado Cloud Select Industry Group (CSIG) tiene un código de conducta que ha sido aprobado por el ICO y el grupo de trabajo del artículo 29 de la UE.

El RGPD entra en vigor el 25 de mayo de 2018. No existe periodo de gracia ni transitorio para las empresas, por lo que tienes que asegurarte de que la tuya esté preparada para entonces.

En el RGPD no existe obligación de que se realicen auditorías o inspecciones periódicamente, pero las autoridades de control tienen la potestad de llevarlas a cabo dentro de sus competencias de inspección. Sin embargo, esto no significa que las auditorías o inspecciones autoimpuestas no sean aconsejables o incluso un requisito de hecho para el cumplimiento del RGPD.

Para los terceros que ofrecen servicios de tratamiento de datos a otros, la situación es un poco más compleja. Ellos tendrán que poner a disposición de la empresa que los contrata toda la información necesaria que demuestre el cumplimiento de sus obligaciones con arreglo al RGPD. También deberán permitir y colaborar en las auditorías o inspecciones que la empresa contratante les pida.

Aun así, el RGPD introduce nuevos requisitos trascendentes y molestos de llevanza de registros para todas las empresas. No basta con simplemente cumplir el RGPD. Cualquier empresa debe estar en condiciones de demostrar que lo hace.

Cabe resaltar que existe la posibilidad de que los gobiernos dicten procesos formales y periódicos de auditoría cuando apliquen el RGPD en la legislación nacional.

Sí. El RGPD afecta a cualquier persona física o jurídica que desarrolle una actividad económica y que procese datos de carácter personal, incluidas entidades como sociedades, instituciones benéficas o clubes. Es indiferente si están reconocidas legalmente o no.

Probablemente sí. El RGPD deja sin efecto toda la legislación actual de protección de datos de los Estados miembros de la UE (en el caso de España, la LOPD). Los requisitos del RGPD van mucho más allá de la ley vigente de protección de datos, por lo que es muy poco probable que una empresa ya los cumpla.

Las diferencias son tan amplias que es imposible resumirlas en una respuesta rápida.

Tu empresa podría recibir una sanción de hasta el 4 % de su volumen de negocio anual en todo el mundo o de 20 millones de euros (la que sea de mayor cuantía). Cabe destacar que es posible infringir el RGPD sin que exista pérdida de datos en sí.

El Gobierno británico ha dicho que está aplicando el RGPD en el nuevo proyecto de ley de protección de datos y que continuará en vigor cuando el Brexit tenga lugar en 2019.

Es probable que para una empresa media acarree algunos o incluso todos los gastos siguientes:

• Una cuota de registro ante el organismo oficial del país respectivo, que sería pagada por las organizaciones que procesen datos de carácter personal, que dependerá del tamaño y el volumen de negocio y también podrá tener en cuenta la cantidad de datos personales procesados.
• Auditoría de todos los procesos de todos los departamentos, a ser posible por una persona o empresa cualificada.
• Modificaciones, como la formación del personal o la adaptación de los sistemas informáticos.
• Posible designación y formación de un delegado de protección de datos.
• Establecimiento y mantenimiento de procesos continuos de documentación que demuestren el cumplimiento del RGPD.
• Costes de certificación voluntaria, en especial si la empresa procesa datos en nombre de otros (recordando que sólo deben usarse organismos de certificación que cumplan la norma EN-ISO/IEC 17065/2012 y que tengan la autorización de las autoridades de control correspondientes, como la ICO en el Reino Unido o la AEDP en España).

Las empresas de algunos tipos tendrán que hacerlo. Entre ellas se incluyen los organismos públicos, las que tengan una actividad principal que consista en el seguimiento de personas a gran escala (incluida la elaboración de perfiles) o las que gestionen datos en categorías especiales, como datos médicos o relativos a condenas o infracciones penales.

El delegado de protección de datos podría ser un empleado actual o se podría contratar a alguien de fuera de la empresa, pero tendrás que informar de quiénes son a la autoridad de control y también deberán tener la formación adecuada.

El RGPD afecta a cualquier empresa de cualquier parte del mundo que procese datos de personas de la UE. De hecho, si ofreces bienes o servicios a personas de la UE o controlas su comportamiento, probablemente deberías tener a un representante en la EU para que gestione las cuestiones relativas al RGPD. Además, debes comunicar por escrito a la autoridad de control quién es. En Internet se encuentran muchos terceros que ya están especializados en cumplir este requisito de representación. Como mínimo, podrás preguntarles si se trata de un requisito para tu empresa.

Antes de la entrada en vigor del RGPD, es difícil prever las consecuencias que tendrá para las empresas situadas fuera de la UE que infrinjan el RGPD, pero podrían incluir la prohibición de hacer negocios en la UE hasta que se demuestre el cumplimiento, lo cual podría llevar tiempo. El efecto podría ser demoledor porque, además de a las ventas, podría afectar a las compras.

ISO 27001 es una norma internacional emitida por la International Standardization Organization (ISO) que define los sistemas de gestión de seguridad de la información. Su nombre completo es ISO/IEC 27001:2013. Esta norma fue desarrollada a partir de la norma británica BS 7799-2, fue publicada inicialmente como ISO/IEC 27001:2005 y ahora se ha convertido en una de las principales normas internacionales para la seguridad de la información.

La implementación de ISO 27001 reduce los riesgos relacionados con la confidencialidad, disponibilidad e integridad de la información en una organización. También ayuda a la organización a dar cumplimiento a la legislación que regula la protección de información confidencial, de sistemas de información, de datos personales, etc. que ya está establecida en la mayoría de los países. Finalmente, la implementación de la norma debería reducir los costos comerciales debido a la menor cantidad de incidentes y a las mejoras en la comercialización por la publicidad que se puede conseguir con la norma.

La norma internacional ISO 27002 (nombre completo: ISO/IEC 27002:2013) define directrices para la implementación de los controles detallados en ISO 27001. ISO 27001 especifica 114 controles que se pueden usar para disminuir los riesgos de seguridad mientras que ISO 27002 proporciona más información sobre cómo implementar esos controles. Las organizaciones pueden obtener la certificación para la norma ISO 27001, pero no para ISO 27002. A ISO 27002 anteriormente se la conocía como ISO/IEC 17799 y surgió de la norma británica BS 7799-1.

Esta era una norma británica cuyo nombre completo era BS 25999-2:2007 y que definía los sistemas de gestión de la continuidad del negocio. Esta norma fue sustituida por ISO 22301 en 2012.

ISO 27001 define la gestión de seguridad de la información, que también incluye la gestión de la continuidad del negocio. Sin embargo, ni ISO 27001 ni ISO 27002 describen cómo se debe implementar la gestión de la continuidad del negocio, por eso es mejor utilizar ISO 22301 (anteriormente BS 25999-2) con este objetivo. Además, las normas ISO 27001 e ISO 22301 contienen elementos que son casi idénticos (gestión de documentación, auditorías internas, revisión por parte de la dirección, medidas correctivas y preventivas); por eso estas normas son completamente compatibles.

Sí. En ese caso, el énfasis estará sobre cómo garantizar la disponibilidad de la información y los procesos de negocio ante el caso de un desastre, etc. pero sin garantizar la confidencialidad e integridad de la información.

¡Seguro! Algunas partes de ISO 27001, ISO 22301 (ex BS 25999-2) e ISO 9001 son prácticamente las mismas; por ejemplo, gestión de documentación, auditorías internas, revisión por parte de la dirección y medidas correctivas. Si se utilizaron los procedimientos mencionados para ISO 9001, también pueden ser utilizados para ISO 27001 o ISO 22301 con algunas mínimas modificaciones. Es decir, a las organizaciones que ya han implementado ISO 9001 les será más sencillo implementar ISO 27001 o ISO 22301 (y viceversa).

Esto realmente depende de una gran cantidad de factores pero, generalmente, las organizaciones más pequeñas pueden necesitar de 3 a 6 meses, las organizaciones de hasta 500 personas necesitarán de 8 a 12 meses y las organizaciones más grandes necesitarán 12 meses o más. Utilice este Calculador del tiempo de implementación para calcular la duración con mayor precisión.

No. Es posible establecer un alcance de la implementación para una parte de la organización solamente; esto tiene sentido en organizaciones de gran envergadura que funcionan en diferentes ubicaciones y/o en diferentes países. Para las organizaciones pequeñas, cuya actividad comercial se desarrolla en menor cantidad de ubicaciones, es mejor implementar la norma para toda la organización.

Es real que ISO 27001 requiere algunos documentos obligatorios, pero la cantidad depende del tamaño y complejidad de la organización: una organización pequeña sin grandes requerimientos de seguridad solo necesitará unos doce documentos aproximadamente, un gran banco puede necesitar varios cientos de documentos. Lo importante al confeccionar la documentación es definir sólo las reglas que son realmente exigidas, para que la organización no desacelere sus operaciones de negocio.

No. La seguridad de TI es parte de la seguridad de la información: la primera incluye, por ejemplo, procedimientos de respaldo o utilización de cortafuegos, mientras que la seguridad de la información también incluye la definición de roles y responsabilidades de seguridad, procedimientos operativos, capacitación y concienciación, relaciones legales con empleados y proveedores, seguridad física, etc. La seguridad de TI es, generalmente, el 50% de la seguridad de la información.

Es casi imposible calcular el costo antes de completar la evaluación de riesgos y la Declaración de aplicabilidad. La mayor parte de los gastos generalmente no están relacionados con hardware o software sino con desarrollar y hacer funcionar procedimientos, con la generación de concienciación y formación de los empleados, con la certificación, etc. Los costos también dependen del tamaño de la empresa, pero es bueno saber que no todos los controles de seguridad deben ser implementados inmediatamente sino que se puede postergar la implementación algunos de ellos.

En el mundo de la tecnología hay errores comunes con términos que no siempre conseguimos diferenciar adecuadamente. Por ejemplo, aunque todos entendemos bastante bien la diferencia entre el software privativo y el no privativo, no siempre pasa lo mismo a la hora de separar los conceptos de software libre y el de código abierto.

En primer lugar, el software libre no es sinónimo de gratuito, aunque en inglés la palabra free pueda significar ambas cosas. Por otro lado, aunque es siempre de código abierto u Open Source, no todo el software de código abierto es libre. Aunque para entenderlo lo mejor será ver qué es cada cosa y ver después cuales son las diferencias más significativas.

Y es que, tal y como defiende el propio Richard Stallman, “el movimiento por el software libre y el movimiento por el código abierto son como dos frentes políticos entre la comunidad de software libre“. Ambos persiguen un objetivo común de dar mayor libertad y transparencia al mundo del software, pero difieren bastante en sus maneras de llevarlo a cabo.

Estas son las cuatro libertades esenciales de los usuarios tal y como las define la FSF:

• La libertad de ejecutar el programa como se desea, con cualquier propósito (libertad 0).
• La libertad de estudiar cómo funciona el programa, y cambiarlo para que haga lo que usted quiera (libertad 1). El acceso al código fuente es una condición necesaria para ello.
• La libertad de redistribuir copias para ayudar a su prójimo (libertad 2).
• La libertad de distribuir copias de sus versiones modificadas a terceros (libertad 3). Esto le permite ofrecer a toda la comunidad la oportunidad de beneficiarse de las modificaciones. El acceso al código fuente es una condición necesaria para ello.

Las cuatro libertades, según explica la fundación, tienen que ser aplicadas en todo el código de un programa. De esta manera, si creamos un software a partir de otro, tenemos que asegurarnos de que tanto la base sobre la que estamos trabajando como las líneas que nosotros hemos añadido al proyecto respeten estas libertades. Vamos, que el software producido a partir de software libre debería ser libre también.

Esto no quiere decir que no pueda ser comercial. Las libertades 2 y 3 para distribuir copias a terceros con o sin modificaciones permiten que se haga de forma gratuita o cobrando una tarifa por la distribución. Mientras el programa respete las cuatro libertades esenciales, seguirá considerándose libre se cobre o no por él.

Por lo tanto, si vamos a vender software libre debemos tener en cuenta que tenemos que permitir y no combatir que cualquier usuario pueda modificarlo a su antojo, tanto si es para mejorarlo y adaptarlo a su uso personal como si quiere difundirlo o incluso cobrar por su distribución. Es por lo tanto una filosofía opuesta de la que siguen las grandes corporaciones con su software privativo, que ni tiene el código abierto ni se suele permitir que se difundan copias modificadas.

Para evitar problemas en el uso comercial, la Free Software Foundation acepta reglas eventuales sobre cómo empaquetar versiones modificadas. Es aceptable, por ejemplo, utilizar licencias que obliguen a que el software libre modificado tenga que utilizar otro nombre, eliminar un logotivo, o identificar las modificaciones que son suyas. El límite está en que las licencias no sean tan agobiantes que dificulten la publicación de las modificaciones.

Por lo tanto, podemos decir que la definición del Software Libre no está tanto en la manera en la que se distribuye como en la ética a la hora de distribuirlo. Es una manera de pensar, y aunque algunos puntos puedan parecer bastante radicales, con ella se está intentando que el software no dependa de empresas y que cualquiera pueda acceder a él independientemente de sus recursos.

El 3 de febrero de 1998, varios integrantes de la comunidad de Software Libre decidieron ir por su cuenta y crearon la Open Source Initiative (OSI). La decisión se tomó justo después del lanzamiento de Netscape, viendo en él una oportunidad para educar a los usuarios y empresas sobre los beneficios prácticos para los proyectos que deciden liberan su código.

Así como la ética del Software Libre se define en cuatro puntos, la Open Source Iniciative tiene diez requisitos a cumplir por parte de un proyecto o las licencias bajo las que se publica para que pueda ser definido como de código abierto:

• Libre redistribución: La licencia del software no debe impedir que este sea regalado o vendido libremente como parte de una distribución mayor que contenga programas de diferentes fuentes. Tampoco debe exigir un pago por hacerlo.
• Código fuente: A la hora de publicar un programa tiene que incluirse su código fuente íntegro o permitir acceder libremente a él.
• Trabajos derivados: Las licencias deben permitir modificaciones y trabajos derivados, y debe permitir que estos se distribuyan bajo los mismos términos que el software original.
• Integridad del código fuente del autor: Se puede impedir la distribución de modificaciones únicamente si se permite la distribución de tales como parches. También se puede requerir que trabajos derivados cambien de nombre o número de versión.
• Sin discriminación de personas o grupos: No se puede discriminar a ninguna persona o grupo a la hora de acceder a un programa o su código.
• Sin discriminación de áreas de iniciativa: Tampoco le se puede restringir su acceso a ninguna iniciativa. Las empresas o grupos de investigación tienen tanto derecho como el resto a utilizar el software.
• Distribución de la licencia: Los derechos asociados en las licencias de los programas deben aplicarse a todos a los que lo redistribuyan sin necesidad de pedir una licencia adicional.
• La licencia no debe ser específica de un producto: Un programa no puede licenciarse únicamente como parte de un software mayor. Podrá ser extraído y utilizado libremente y con todos los derechos en otras soluciones.
• La licencia no debe restringir otro software: El hecho de que un proyecto sea de código abierto no puede obligar a que los programas en los que se incluye sean también de código abierto.
• La licencia debe ser tecnológicamente neutral: Ninguna disposición de la licencia puede basarse en la tecnología o un estilo de interfaz, con lo que, por ejemplo, no se debe requerir su aceptación mediante gestos explícitos como clicks de ratón.

Como veis, los puntos son bastante menos ideológicas y más pragmáticos. No se centran tanto en el hecho que los programas derivados mantengan las características, sino en fomentar la apertura del código que utilizan los programas para que todos puedan colaborar y beneficiarse. Esta flexibilidad les ha permitido ganarse socios de renombre como Facebook, Google, la Linux Foundation o Mozilla.

Por lo tanto, en vez de un manifiesto ético lo que tenemos son puntos prácticos con los que regular una actividad y poner orden previendo cualquier caso o conflicto que se pueda dar. Pero tampoco deja de lado las libertades, ya que en varios de sus puntos exigen que no se discrimine a nadie a la hora de poder acceder al código.

También es importante recalcar que no todos los programas que liberan su código fuente son de código abierto, ya que este código puede estar siendo liberado bajo unas licencias restrictivas que contradigan los principios en los que se basa el proyecto Open Source.

Estamos ante dos maneras de afrontar un objetivo similar, por lo que las diferencias no son demasiadas. La principal es que el código abierto es menos estricto que el software libre, por lo que en la práctica todo software libre se puede calificar como código abierto, aunque no todo el software de código abierto tiene por qué ser libre. Por ejemplo, algunas licencias de Open Source son demasiado restrictivas como para considerarse libres.

Otra pequeña diferencia nos la encontramos a la hora de proteger a los autores originales. La FSF recula con una excepción que permite que los autores puedan pedir que un producto basado en el suyo sea renombrado para evitar confusiones. Mientras, la OSI va un poco más allá permitiendo que se pueda impedir la distribución de algunos subproductos, aunque siempre a cambio de que puedan ser publicados como parches o añadidos para el original.

Pero más allá de eso las diferencias tampoco son demasiadas. A ojos de Stallman, con el software libre se le quiere dar sentido a la libertad que implica el término, mientras que utilizar código abierto no implica que haya siempre libertad, sino disponibilidad a la hora de acceder al código. Aún así, el propio Stallman admite que aunque no están de acuerdo en los principios básicos, sí que lo están en las recomendaciones prácticas y en el colaborar en contra del software privativo.