PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE RIGE LA CONTRATACIÓN DE UNA PLATAFORMA APP/WEB PARA LA GESTIÓN Y DIFUSIÓN DE LOS EVENTOS CDTI, E.P.E. (PROCEDIMIENTO ABIERTO, TRAMITACIÓN ORDINARIA)
PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE RIGE LA CONTRATACIÓN DE UNA PLATAFORMA APP/WEB PARA LA GESTIÓN Y DIFUSIÓN DE LOS EVENTOS CDTI, E.P.E. (PROCEDIMIENTO ABIERTO, TRAMITACIÓN ORDINARIA)
EXPEDIENTE 9/2019 AB (DG/DC)
1. OBJETO
El objeto del presente pliego es establecer las prescripciones técnicas aplica- bles a la contratación de una plataforma internet multievento que permita gestionar de forma digital la participación de personas y empresas en eventos organizados por el CDTI.
2. CONTEXTO Y MARCO NORMATIVO
El (CDTI-E.P.E.) es una Entidad Pública Empresarial, dependiente del Ministerio de Ciencia, Innovación y Universidades, que promueve la innovación y el desarrollo tecnológico de las empresas españolas.
Sus funciones de entidad de fomento en el I+D+i se encuentran dentro del marco de la Estrategia Española de Ciencia y Tecnología y de Innovación 2013-2020 y del Plan Estatal de Investigación Científica y Técnica y de Innova- ción 2017-2020 y de la Ley 14/2011 de la Ciencia, la Tecnología y la Innova- ción, aprobada el 1 xx xxxxx de 2011.
La prestación de los servicios se llevará a cabo en el siguiente contexto: 1.- Ubicación:
X/ Xxx, xx 0, xx Xxxxxx.
X/ Xxxxxxx XX, 0 - xxxxxx 0x, xx Xxxxxx.
2.- Xxxxx Xxxxxxxxx:
- Ley 39/2015, de 1 de octubre, del Procedimiento Administrativo Común de las Administraciones Públicas.
- Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público.
- Real Decreto 3/2010, de 8 de Enero, de Esquema Nacional de Seguri- dad.
- Guías del CCN.
- Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo de 27 xx Xxxxx de Protección de Datos de Carácter Personal.
- Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Per- sonales y garantía de los derechos digitales
- Directrices y Guías de la Agencia Española de Protección de Datos y del Comité Europeo de Protección de Datos.
- Normativa y directrices específicas de Cloud Computing.
Y cualesquiera otras que sean de aplicabilidad en las tareas descritas en el presente pliego.
Hay información adicional disponible en la página web (xxx.xxxx.xx) y en la sede electrónica (xxxxx://xxxx.xxxx.xxx.xx) del CDTI.
3. DESCRIPCIÓN DE LA NECESIDAD
El CDTI organiza anualmente más de 100 eventos, de diversas dimensiones, duración y localización. Para proporcionar la funcionalidad de una gestión in- tegral e integrada de todos los eventos y facilitar la gestión digital de personas y empresas participantes (registro, reserva de servicios, información sobre agenda y programa, reserva de citas B2B, etc.), se requiere una plataforma de software con las características que se recogen en el siguiente apartado.
4. FUNCIONALIDADES REQUERIDAS
En este punto se detallan los requisitos funcionales considerados como míni- mos por parte del CDTI y de los que deberá disponer la plataforma.
1) EDITOR DE ADMINISTRACIÓN: Que disponga de un espacio digital privado de gestión, diseño y administración, en adelante el editor, accesible por parte de las personas designadas por el CDTI, compuesto por:
• Funcionalidad de base de datos, que permita que el CDTI realice el di- seño personalizado de estructuras de datos para recoger los registros de personas y los servicios a los que se suscriben.
• Funcionalidad de diseño de interface, que permita que el CDTI realice el diseño personalizado del interface gráfico de acceso, las reglas de interacción con las estructuras de datos y el diseño de navegación del interface.
• Acceso de administración a los datos guardados en la arquitectura de datos de cada evento. Específicamente, la plataforma debe incluir la funcionalidad del borrado y/o selección y/o bloqueo selectivo xx xxxxx- tros según criterios como los valores de un campo de la base de datos (e.g. eliminar o bloquear los registros cuyo valor en un campo determi- nado sea NO), un periodo determinado de fechas, etc.
Para ello, el editor deberá disponer de:
• Un panel de control con una interfaz sencilla y amigable.
• La posibilidad de establecer permisos de acceso y/o edición a los dife- rentes servicios del editor desde una cuenta de administrador.
• Gran facilidad de definición del diseño de interface, reglas de interac- ción y diseño de navegación.
• Plantillas para poder mostrar la información de eventos de un mismo ti- po de forma unificada.
2) MULTIEVENTO: La plataforma debe permitir el diseño de múltiples arquitec- turas de datos asociadas a diseños de interface específicos. Cada combi- nación única de arquitectura de datos más interface será denominada evento, con sus características propias. La plataforma debe permitir la convivencia concurrente de un número ilimitado de eventos de forma si- multánea.
Además, la plataforma deberá permitir la duplicación y copia de eventos, para aquellos casos en los que el CDTI organiza un mismo evento de forma recurrente y la arquitectura de datos y los diseños de interface, reglas de interacción y navegación ya han sido definidos en una primera edición.
También deberá permitir que los datos de un evento puedan ser copiados desde y a, duplicados y/o compartidos dentro de otro/s evento/s.
3) VISOR: Que disponga de un espacio digital público de visualización e in- teracción pública, en adelante el visor, que despliegue simultáneamente los múltiples eventos diseñados en el editor y los ejecute de acuerdo a las reglas de interacción que defina el CDTI dentro de la plataforma para ca- da evento. Cada evento diseñado en el editor será desplegado de forma transparente y automática (sin precisar compilación o intervención de los gestores CDTI a nivel de código fuente) en el visor como un micrositio web o app.
El visor debe poder ser accesible:
• Desde una dirección URL, que deberá poder recibir redireccionamiento desde un dominio proporcionado por y propiedad del CDTI y que apuntará a una página web principal contenedora (o página índice) generada por la plataforma y accesible en ordenadores a través de navegadores habituales (Chrome, Explorer, Firefox, etc.), en la que se presenten a modo de índice todos los eventos activos del CDTI y cada elemento del índice dé acceso al micrositio web de cada evento.
• Desde una app nativa, proporcionada por la plataforma y descarga- ble a través de las tiendas de Android e iOS, en la que se presenten a modo de índice todos los eventos activos del CDTI y cada elemento del índice dé acceso al micrositio app de cada evento. Cuando se hagan modificaciones en el diseño de menús de evento desde el editor, la app no necesitará una nueva validación de Apple o Google ni una nueva descarga por parte del usuario.
En todos los casos, tanto el acceso a través de navegador web como de app móvil deberán estar sincronizados entre sí y mostrar la misma informa- ción de datos básicos (inscripciones, ponentes, programa, expositores, etc.) que refleje el estado actual de cada evento según los datos alma- cenados en la base de datos del editor.
Los usuarios públicos no podrán modificar o alterar a través del visor ni las estructuras de datos ni los diseños de interface ni de las reglas de interac- ción ni de navegación del interface, solo introducir datos y gestionar la in- formación relativa a su participación en cada evento.
En el visor, cada usuario público deberá poder seleccionar el evento que sea de su interés a partir de la página índice tanto en el formato web co- mo en el formato app móvil.
La plataforma debe ofrecer la posibilidad de limitar el acceso a determi- nadas áreas de los micrositios mediante usuario y contraseña a las perso- nas que se registren. Las contraseñas deberán seguir unos determinados parámetros de seguridad, que cada licitador deberá explicar en su oferta.
4) MARCA BLANCA: El CDTI deberá poder incorporar sus propios elementos de identidad gráfica y corporativa tanto en el editor como en el visor, sin que aparezca ninguna otra referencia empresarial relacionada con el desarrollo, la comercialización o la gestión de la plataforma. Además, la url del visor de la plataforma debe también poder utilizar un dominio propie- dad del CDTI para acceder a la página índice y los correos electrónicos enviados desde la plataforma deben poder utilizar una dirección remiten- te correspondiente al dominio del CDTI.
5) MICROSITIOS WEB: Los micrositios web que genere la plataforma para ca- da evento, además de ser accesibles a través del visor, deberán contar con una url que les permita recibir redirecciones desde dominios propie- dad del CDTI para poder acceder de forma directa a través de un nave- xxxxx. Cada micrositio web generado por la plataforma deberá tener pro- tocolos de cifrado HTTPS y deberá solicitar el consentimiento de la política de privacidad y de la política de cookies al entrar en ella.
6) IDIOMAS: La plataforma debe ofrecer la posibilidad de ofrecer los microsi- tios de cada evento en varios idiomas, cambiando de uno a otro con faci- lidad, incluyendo los formularios de registro, agendas y programas, opcio- nes de menú, todas las cláusulas de protección de datos u otros consenti- mientos, entre otros. Asimismo, si el contenido existiera en varios idiomas, el sistema deberá poder determinar el idioma en el que mostrar la informa- ción según esté configurado el idioma del dispositivo móvil de cada usua- rio.
7) CONCURRENCIA MÚLTIPLE: La plataforma deberá permitir la concurrencia simultánea de, como mínimo, 5.000 usuarios a la vez, ya sea en un solo evento o en varios. Además, deberá permitir la concurrencia de hasta 50 gestores CDTI a la vez en el editor.
8) AUTONOMÍA E INSTALACIÓN: El CDTI pretende ser autónomo en la gestión de la plataforma, por lo que el editor de la plataforma debe poder ser ejecutado y ser accesible mediante contraseñas privadas en el ámbito cloud; es decir, que no precise de la instalación de software local.
9) ÍNDICE DE EVENTOS: La página índice del visor de eventos podrá ser acce- sible de forma libre tanto en el formato web como en la app móvil, de modo que los usuarios públicos puedan conocer qué eventos organiza el CDTI y sus contenidos públicos (fechas, sede, agenda de trabajo, etc).
10) ENTORNO CLOUD: La plataforma, al ejecutarse en un entorno cloud, debe poder actualizar de forma inmediata y automática en el visor cualquier cambio, modificación e interacción que se haya producido en los datos contenidos en la base de datos, presentando la información siempre ac- tualizada.
11) DISEÑO WYSIWYG: El editor ofrecerá herramientas de diseño de arquitectu- ras de datos y de diseño gráfico de interfaces (páginas, texto, gráficos, vi- deos, botones, enlaces, etc.), de reglas de interacción con los datos (campos obligatorios, campos predefinidos, etc.) y de navegación del in- terface (navegación entre páginas del micrositio de cada evento y sus contenidos y aplicaciones: registro de personas y empresas, reserva de ci- tas B2B, etc).
Todas las herramientas de diseño de la plataforma, salvo casos muy ex- cepcionales, deben ser del tipo WYSIWYG, es decir, completamente visua- les y no exigir ningún conocimiento de programación. Estas herramientas y elementos de diseño deben estar accesibles como elementos y recursos individuales sueltos (páginas, ventanas de gráficos, cajas de texto, campos visualizadores de datos, botones de acción, flujos de navegación, enlaces entre páginas, etc.) que puedan ser enlazados con las arquitecturas de datos y colocados en superficies de visualización como páginas u otros contenedores dentro de cada micrositio y, adicionalmente, deben estar accesibles como módulos preconfigurados especializados ya listos para su uso, que combinen de forma determinada varios de los elementos y recur- sos individuales disponibles en la plataforma para permitir al gestor de ca- da evento añadir con rapidez funcionalidades ya prediseñadas y especia- lizadas en tareas habituales de la gestión profesional de eventos: registro de participantes, registro de expositores, cobros, reserva de servicios, etc. En adelante, se describen algunos de los módulos que se consideran obli- gatorios dentro de la plataforma.
12) MODULARIDAD: La plataforma deberá permitir el diseño modular de even- tos, es decir, que le permitirá al CDTI seleccionar y combinar en su diseño de eventos aquellos módulos prediseñados que desee incorporar a un evento determinado. Estos módulos también se podrán combinar con otros elementos individuales (e.g. páginas de texto) para crear interfaces de navegación particulares para cada micrositio de cada evento.
13) REGISTRO DE PARTICIPANTES: La plataforma deberá disponer obligatoria- mente de un módulo de registro de participantes, con las siguientes carac- terísticas:
a. El módulo de registro de participantes se visualizará en el visor web y app, dentro del micrositio correspondiente a cada evento, como un formulario de inscripción. Este formulario será personalizable para cada evento dentro del editor, permitiendo incluir campos de texto, de fecha, numéricos, gráficos (para fotografías), campos enlazados a urls, documentos (currículum), etc. Además, permitirá diversas ca-
tegorías de participantes o de servicios mediante campos predefi- nidos y/o seleccionables. También deberá permitir campos x xxxxxxxx de rellenado obligatorio, que deberán poder ser configurables de modo que, si un usuario público no las selecciona en señal de acep- tación, la navegación no permitirá que el usuario se registre ni que deposite sus datos personales en la base de datos de la plataforma.
b. El módulo de participantes deberá permitir integrar una serie xx xxxxxx comunes a todos los eventos de forma predefinida como, por ejemplo, campos x xxxxxxxx de aceptación obligada sine qua non, para crear, por ejemplo, un control del tratamiento de los da- tos según RGPD y otros consentimientos que el CDTI quiera incorpo- rar.
c. Uno de los tipos de campo disponibles en los formularios ha de ser el de subida de archivos, que tendrán que poder quedar almacena- dos en la plataforma y accesibles y visibles en el editor.
d. Se debe poder condicionar la aparición de un campo a diferentes circunstancias, como la respuesta previa a otro campo.
e. En el caso de que cambiara la legislación sobre protección de da- tos o cualquier otra que afectara al CDTI, la plataforma debe estar dotada de los recursos de modificación y comunicación necesarios para poder volver a recabar de todos los usuarios públicos activos en el sistema un nuevo consentimiento, mediante una comunica- ción dirigida a través del visor que incluya una nueva petición de consentimiento cuya prueba inequívoca pueda ser, de nuevo, al- macenada en el registro de cada usuario y/o cambios en la confi- guración o seguridad de la plataforma.
f. La plataforma deberá incluir la posibilidad de inscripción de un nú- mero ilimitado de participantes a cada evento y a todos los eventos de forma global pero también debe poder limitar el número xx xxxx- tentes que se pueden registrar.
g. Todos los datos de la base de datos de cada evento deben poder ser exportados, de forma directa, a ficheros xlsx o csv.
h. La plataforma debe permitir importar registros de participantes des- de un fichero xlsx o csv.
i. La plataforma debe permitir definir y programar fechas de apertura y cierre de inscripción para cada evento, de modo que se desacti- ve automáticamente la funcionalidad de nuevos inscritos cuando se alcance la fecha predeterminada.
j. La plataforma deberá ofrecer la posibilidad de que el registro al evento sea público o privado.
k. La plataforma debe poder permitir que cada usuario seleccione, dentro de su inscripción, aquellos servicios a los que quiere suscribir- se a partir de un catálogo que se podrá definir para cada evento dentro del editor: asistencia a sesiones, citas, reserva de servicios, etc.
l. También deberá permitir que el registro sea automático o previa aprobación del gestor del evento. Esta aprobación o moderación manual del registro debe poder limitarse a diferentes categorías de usuarios (por ejemplo, el gestor puede querer que los usuarios públi-
cos se registren como asistentes convencionales pero no como po- nente, en cuyo sería precisa una aprobación previa)
m. Los usuarios deberán poder acceder a su perfil y cambiar sus datos.
n. La plataforma deberá incluir la opción de enviar a una cuenta de correo electrónico que se determine para cada evento una notifi- cación por cada nueva inscripción o por cada modificación que realice un usuario ya registrado.
14) DISEÑO Y ENVÍO DE ACREDITACIONES: La plataforma deberá disponer de un módulo con la funcionalidad de diseño y envío de acreditaciones per- sonalizadas, de forma automatizada o a iniciativa del gestor del evento. Estas acreditaciones deben generar códigos QR asociados a los datos de cada usuario registrado y deben poder ser diferenciadas según el tipo de participante.
15) GESTIÓN DE CHECK-IN DE ACREDITACIONES: La plataforma deberá dispo- ner de un módulo con la funcionalidad de check-in o comprobación de acreditaciones, que se emplea para la recepción y comprobación de los participantes durante la celebración física de cada evento. Este módulo deberá poder leer los códigos QR presentados, comprobarlos contra la base de datos para confirmar que no hayan sido ya presentados para el mismo servicio (comprobación de duplicidades) y registrar los accesos en cada registro de la base de datos. También debe permitir discriminación por servicio (sesión de trabajo, visita técnica, etc.), funcionar offline por si fallara la conexión online y posibilitar la sincronización entre varios dispositi- vos.
16) AGENDA DEL EVENTO: La plataforma deberá disponer de un módulo de agenda o programa de evento. Este módulo ha de permitir dos tipos de vi- sualización de sesiones o servicios del programa de cada evento:
a. Públicas, visibles para todos los usuarios inscritos.
b. Privadas, visibles solo para los usuarios de determinadas categorías. Cada sesión de trabajo o servicio incluido en la agenda deberá poder mostrar usuarios registrados de determinadas categorías (e.g. ponentes) asociados a esa sesión, de modo que el módulo ofrezca un enlace auto- mático a su curriculum vitae, previamente proporcionado por cada po- nente al hacer su registro.
17) PONENTES: La plataforma deberá disponer obligatoriamente de un módulo de gestión de ponentes que, de forma adicional a la inscripción común, permita añadir contenido de valor añadido para esta tipología de usuario. Este módulo interactuará entre el módulo de registro de participantes y el de agenda para configurar automáticamente la información de ponentes a la que tendrá acceso el participante convencional.
18) NETWORKING/B2B: La plataforma deberá contar con un módulo específico de encuentros bilaterales que permita gestionar relaciones de networking entre los participantes registrados a un evento. Este módulo, como mínimo, deberá poder:
a. Diseñar formularios para perfiles diferenciados.
b. Filtrar perfiles por determinados campos que se especifiquen (normalmente sector de actividad, tipo de entidad, país, etc.)
c. Permitir la interacción entre los participantes para solicitarse en- tre ellos reuniones y aceptarlas o rechazarlas.
d. Gestionar las mesas o espacios designados para los encuentros bilaterales, con flexibilidad para la limitación de franjas horarias y de fijación de tiempos para los encuentros.
e. Ofrecer estadísticas de las reuniones establecidas.
19) EXPOSITORES: La plataforma deberá disponer obligatoriamente de un mó- dulo que permita gestionar expositores, permitiendo, además del registro convencional de participantes:
a. Rellenar perfiles específicos de expositores para que aparezcan en la información del evento y para que su información esté disponible en el módulo de networking.
b. Gestionar de forma completa la asignación de stands de diferentes tipos y de otros servicios asociados.
20) ABSTRACTS Y CALL FOR PAPERS: La plataforma deberá disponer de un mó- dulo que permita la gestión de abstracts, posters y call for papers.
21) PATROCINADORES: La plataforma deberá disponer de un módulo que permita incluir en los micrositios un apartado de patrocinadores, en el que se muestren los logotipos y el contenido que se determine para cada uno de ellos. Debe tener la posibilidad de incluir el registro de patrocinadores a partir de un fichero xlxs o csv. Los patrocinadores deben poder categori- zarse.
22) SISTEMA DE PREGUNTAS EN DIRECTO: La plataforma deberá disponer de un módulo que permita implementar un sistema de preguntas y respuestas en directo con servicio de moderación.
23) ENCUESTAS: La plataforma deberá disponer de un módulo que permita generar varios tipos de consultas en formato encuestas, tanto antes como durante o después de la celebración de cada evento.
24) NOTIFICACIONES PUSH: La plataforma deberá disponer de un módulo que permita realizar notificaciones push a los usuarios registrados, con la posibi- lidad de realizar filtrados según varios criterios. Estas notificaciones deben poder ser programadas en el tiempo y diferenciadas por tipo de asistente.
25) REDES SOCIALES: La plataforma deberá ofrecer la posibilidad de que los usuarios accedan desde dentro del micrositio web o app a las cuentas so- ciales que determine el gestor de cada evento. Además, debe incorporar un social media feed para mostrar todas las publicaciones referentes a un determinado hashtag.
26) PASARELA DE PAGO: Para eventos con cuota de inscripción y servicios de pago, la plataforma debe incluir la funcionalidad de realizar pagos on-line por parte de los usuarios públicos y de emitir facturas numeradas que po- drán ser diseñadas libremente por el gestor de cada evento.
Cada oferta debe especificar qué métodos de cobro permite su pasarela (entre los cuales, obligatoriamente, debe figurar la transferencia bancaria) y definir los requisitos que se exigen para implementar cada uno de ellos, indicando claramente qué datos e información se tratan en la plataforma y cuáles vía pasarela de terceros.
La plataforma debe permitir el establecimiento de precios diferentes según los criterios que se definan, incluidos descuentos por pronto pago o por al- guna otra circunstancia, y también el pago de otros servicios sueltos adi- cionales a la inscripción.
En el punto 5 del presente pliego se refieren las obligaciones en relación a las medidas de seguridad correspondientes al nivel de impacto a la priva- cidad de los datos tratados según el RGPD y el ENS.
27) SERVICIO DE CORREO MASIVO: La plataforma debe incluir la funcionalidad de comunicaciones masivas vía correo electrónico a partir de datos incor- porados a través de una hoja Excel o similar o de la propia base de datos de los participantes a los eventos, debiendo poder establecerse filtros para seleccionar los destinatarios.
28) REPOSITORIO DE DOCUMENTOS: La plataforma debe permitir el almace- namiento y la descarga de documentos en los más variados formatos (doc, pdf, zip, vídeo, imagen, etc…). El licitador deberá especificar qué medidas de seguridad se pueden establecer para este repositorio de do- cumentos, ya que, aunque la mayoría de ellos serán de acceso público, podría darse el caso de que se suban documentos confidenciales.
29) ENLACES EXTERNOS: La plataforma debe permitir enlazar textos, páginas, imágenes o cualquier otro contenido disponible en internet mediante hi- pervínculos del tipo http, mailto, tel…
30) ESTADÍSTICAS: La plataforma debe poder mostrar en todo momento esta- dísticas globales o por cada evento sobre registro de participantes por ca- tegorías, pagos, etc. y también indicadores numéricos del volumen de ac- cesos a cada micrositio a través de web y app móvil, pero sin recabar nin- gún tipo de dato de carácter personal y manteniendo la información de acceso completamente anónima.
31) SOPORTE TÉCNICO: La oferta deberá incluir el soporte técnico y correctivo de todas las funcionalidades de la plataforma durante todo el tiempo que dure el contrato, así como la adaptación de la plataforma con nuevos desarrollos o funcionalidades originados en cambios normativos de obli- gado cumplimiento para el CDTI.
32) FORMACIÓN: La oferta deberá incluir también una formación anual pre- sencial o telemática para las personas que designe el CDTI.
5. PRIVACIDAD DESDE EL DISEÑO y SEGURIDAD DE LA INFORMACIÓN
La plataforma deberá cumplir con la normativa de protección de datos vi- gente (RGPD y LOPDGDD) y actualizarse según cambie la normativa a lo lar- go de la duración del contrato. De esta forma, se deberán tener presente las directrices establecidas en el Esquema Nacional de Seguridad (ENS) en el momento de implementar y adaptar los distintos módulos y las funcionalida- des de la aplicación a fin de cumplir con el principio de privacidad desde el diseño y por defecto establecido en el artículo 25 del RGPD.
A este respecto, la oferta técnica deberá detallar necesariamente en un punto específico y de forma descriptiva, no reproduciendo los literales de es- te pliego o de la normativa, las medidas de seguridad establecidas por el lici- tador para salvaguardar la integridad, disponibilidad, confidencialidad, au- tenticidad y trazabilidad de los datos, contemplando como mínimo las si- guientes:
• Mecanismos de autenticación protegida de usuarios, incluyendo la pa- rametrización establecida en el caso de utilizar contraseñas y las medi- das adoptadas para evitar autenticaciones de usuarios automáticos (robots).
• Protocolos y/o técnicas de cifrado adoptados al almacenamiento, al acceso y al intercambio de la información mediante conexiones remo- tas según el riesgo para la privacidad de los datos tratados y la confi- dencialidad de la información.
• Especificaciones establecidas para el Servidor o CPD, donde se alojará la información y, especialmente, los datos personales, con expresa indi- cación de si se encuentra en el Espacio Económico Europeo (EEE) o en país con protección equiparable según la Agencia Española de Protec- ción de Datos.
• Procedimiento establecido para la realización periódica de copias de seguridad.
• Generación de logs de seguridad relativos a todos los sistemas que den soporte a la información del CDTI y periodo establecido para la conser- vación de éstos, en su caso.
• Modelo de gestión y notificación de incidencias al CDTI en caso de producirse un incidente de seguridad.
• Modelo de realización de auditorías por terceros especialistas en mate- ria de seguridad de la información y protección de datos personales.
• Detalle de las posibles subcontrataciones ya existentes de los licitadores, especialmente si son empresas radicadas fuera del territorio de la Unión Europea, controles establecidos para la subcontratación de los servicios prestados al CDTI y procedimiento de información al CDTI durante la vi- gencia del contrato.
• Metodología para determinar la realización de evaluaciones de impac- to para los tratamientos de datos personales susceptibles de ello.
• Acreditación de la realización de las evaluaciones de impacto en el ca- so de tratamiento de datos de geolocalización, de tratamientos en cloud y de tratamiento de los pagos de la plataforma. En su defecto el análisis inicial que ha determinado la no realización de la evaluación de impacto.
• Medidas y mecanismos adoptados para la portabilidad de la informa- ción a los sistemas del CDTI y/o a terceros en caso de ejercicio de este derecho por parte de los titulares.
• Mecanismos y/o medidas establecidas para garantizar la correcta seg- mentación entre los sistemas que dan soporte al CDTI y los sistemas habi- litados para otros clientes de la entidad licitadora asegurando el aisla- miento de los datos y la información del CDTI.
• Modelo establecido para la separación de entornos y la gestión de los usuarios respecto a éstos.
• Modelo de bastionado de los sistemas operativos de los servidores y las bases de datos, incluyendo las medidas implantadas para asegurar el bastionado de estos recursos.
Asimismo la plataforma, aplicación y web deben permitir incorporar previo al tratamiento de los datos las preceptivas cláusulas de información y permitir recabar el consentimiento expreso de los titulares y describir cómo la plata- forma, la web y la app incorpora, modifica, recaba, registra y conserva de forma que se identifique titular-consentimiento, los consentimientos expresos necesarios, y las cláusulas relativas al derecho de información según el trata- miento en el que se requiera, así como cláusulas relativas a la propiedad inte- lectual/industrial, etc. en su caso.
Y cómo permite el ejercicio de derechos de protección de datos por parte de los titulares, indicando el procedimiento y/ o cómo la plataforma informa al Responsable del Tratamiento (CDTI) o gestiona o registra estos derechos.
En el caso concreto del tratamiento de datos de carácter personal en rela- ción con los pagos asociados a los eventos, la plataforma preferiblemente no debe conservar el número de tarjeta o número de cuenta bancaria.
En todo caso, tanto la plataforma como la pasarela de pago, ya sea del propio licitador o de terceros, deberán contar con las medidas de seguridad acordes al nivel de privacidad de los datos y del análisis de riesgos efectuado y cumplir con el estándar PCI DSS, que es el estándar de seguridad que de- xxx cumplir las entidades que procesan, guardan o transmiten datos de tar- jetas de crédito y/o débito.
6. FASES DEL SERVICIO
Los servicios objeto del presente pliego se llevarán a cabo en distintas fases:
1. Planificación y coordinación del servicio: se determinará en una o más reuniones iniciales para arrancar el proyecto.
2. Formación inicial a los administradores: se realizará una formación presen- cial o telemática en el CDTI para las personas que gestionarán la plata- forma en el plazo de un mes desde la firma del contrato.
3. Implantación y adecuación de la plataforma a las necesidades del CDTI. El licitador deberá poner en marcha el sistema en los siguientes plazos:
a. En un plazo de dos meses desde la formalización del contrato, la plataforma deberá estar en condiciones de publicar, como mínimo, los siguientes módulos para un evento: gestor de contenidos, ima- gen personalizada, app, web, agenda, registro, encuentros bilatera- les, pasarela de pago, módulo de expositores y módulo multi- idioma.
b. En un plazo de cuatro meses la plataforma deberá estar comple- tamente operativa para la funcionalidad multievento con todos los módulos -los ya publicados y los que restaran por poner en marcha-.
4. Formación a los editores del CDTI: se realizará una formación presencial o telemática en el CDTI para las personas que puedan incluir eventos en la plataforma y gestionarlos desde sus diferentes áreas en un plazo de cuatro meses desde la formalización del contrato.
5. Mantenimiento, soporte y actualización:
a. El adjudicatario deberá dar soporte a la gestión de incidencias, mantenimiento correctivo y actualización de versiones de la plata- forma durante el periodo de ejecución y garantía del contrato.
b. Cualquier cambio legislativo estatal o autonómico o desarrollo del mismo que afecte al proyecto o a los trabajos desarrollados serán cubiertos por el adjudicatario dentro del soporte, mantenimiento y actualización de la plataforma durante el periodo de ejecución y garantía del contrato.
7. DOCUMENTACIÓN
El adjudicatario deberá entregar, una vez completada la implementación de la plataforma, un manual de usuario para administradores y editores de even- tos del CDTI.
8. ACUERDO DE NIVEL DE SERVICIO
El nivel de servicio exigido para la plataforma será 24 h. x 7 días. El licitador deberá explicar en su oferta el plan de contingencia a implementar en caso de caída del servicio por cualquier causa imputable a sus sistemas.
Por otro lado, el licitador deberá proponer un procedimiento y sistema para la comunicación de incidencias, que necesariamente debe contemplar la nor- mativa de protección de datos en relación a la comunicación y gestión de brechas de seguridad. Esta operativa deberá incluir la comunicación por email o por teléfono. La comunicación deberá realizarse en castellano, y co- municarse en un plazo máximo de 12 horas, en horario de lunes a viernes de 9:00 a 18:00 h (hora española).
Una vez comunicada una incidencia, el adjudicatario tendrá un tiempo má- ximo de respuesta de 4 horas y un máximo de 48 horas para su resolución si la incidencia no es urgente y 8 horas para resolución de aquellas incidencias que se hayan indicado como urgentes.
9. PENALIZACIONES POR INCUMPLIMIENTO DEL PLAZO DE RESPUESTA Y RESOLUCION DE INCIDENCIAS
Cuando el adjudicatario, por causas imputables a él mismo, hubiere incurrido en demora respecto al cumplimiento de los plazos establecidos en el acuer- do de nivel de servicio se le aplicarán las penalizaciones establecidas en este apartado.
Las penalizaciones establecidas se detraerán en la factura con fecha inme- diatamente posterior a la fecha del incumplimiento del acuerdo de nivel de servicio.
En el caso de superar el plazo establecido como máximo para la prestación de asistencia técnica (de 48 horas para la resolución de una incidencia no urgente o de 8 horas para la resolución de una incidencia de carácter urgen- te), se aplicarán las siguientes penalizaciones con carácter acumulativo:
• Un día laborable de retraso: 1% sobre el coste trimestral del servicio de soporte.
• Dos días laborables de retraso: 2% sobre el coste trimestral del servicio de soporte.
• Tres días laborables de retraso: 3% sobre el coste trimestral del servicio de soporte.
• Cuatro días laborables o más de retraso: 4% sobre el coste trimestral del servicio de soporte.
Firmado digitalmente por XXXXXXX XXXXX, XXXXX DE LOS XXXXX (FIRMA)
Fecha: 2019.06.26
08:27:26 +02'00'