PLIEGO DE PRESCRIPCIONES TECNICAS
PLIEGO DE PRESCRIPCIONES TECNICAS
CONTRATACIÓN DE LOS SERVICIOS INFORMÁTICOS PARA LA PUESTA EN MARCHA DE UN SISTEMA DE LICITACIÓN ELECTRÓNICA EN LA NUBE, EN LA MODALIDAD DE SOFTWARE AS A SERVICE (SaaS), INCLUIDO SU SOPORTE FUNCIONAL Y TÉCNICO
Expediente: SOLPED 3603
ÍNDICE
1. OBJETO DE LA CONTRATACIÓN 3
4. REQUERIMIENTOS DE LA SOLUCIÓN 9
5. DESCRIPCIÓN Y REQUISITOS DEL PROYECTO 10
Anejo 1: Detalle de las tareas a realizar 17
Anejo 2: Modelo Operativo para la aplicación de Licitación 18
Anejo 3: Modelo Operativo para la aplicación de Registro Xxxxxxx xx Xxxxxxx x Xxxxxx 00
Xxxxx 0: Requisitos del proyecto 27
Anejo 5: Requisitos de seguridad 39
1. OBJETO DE LA CONTRATACIÓN
El objeto del presente procedimiento es la contratación de los servicios informáticos para la puesta en marcha de un sistema de licitación electrónica para el Imprenta de Billetes, S.A., Medio Propio del Banco de España (en adelante, IMBISA). Estos servicios serán proporcionados desde «la nube» por el proveedor, en la modalidad «Software as a Service» (en adelante, SaaS), e incluirán un soporte funcional y técnico, que se encargará de la atención a usuarios y de la resolución de incidencias.
1.1 Información general
Los objetivos que se pretenden alcanzar con este proyecto son:
- Seleccionar, configurar e integrar una plataforma de aplicaciones en la nube - SaaS (Software as a Service) que proporcione una solución de licitación electrónica además de una solución de registro general de entradas y salidas de documentación.
- Permitir la licitación electrónica en los procesos de contratación de IMBISA, cumpliendo los requisitos establecidos por la normativa de aplicación (actualmente están contenidos en la directiva 2014/24/UE del Parlamento Europeo y del Consejo, de 26 de febrero de 2014, así como las Reglas de contratación de IMBISA). Igualmente permitirá el cumplimiento de los requisitos establecidos en el Real Decreto Legislativo 3/2011, de 14 de noviembre, por el que se aprueba el texto refundido de la Ley de Contratos del Sector Público, o en el texto legal que lo sustituirá a partir del 9 xx xxxxx de 2018 (Ley 9/2017, de 0 xx xxxxxxxxx, xx Xxxxxxxxx xxx Xxxxxx Xxxxxxx, por la que se transponen al ordenamiento jurídico español las Directivas del Parlamento Europeo y del Consejo 2014/23/UE y 2014/24/UE, de 26 de febrero de 2014), y su normativa de desarrollo.
- La adquisición de un sistema que permita gestionar de forma integrada todas las entradas y salidas de documentación oficial de IMBISA, identificándolas de forma unívoca indicando, al menos, fecha y hora de entrada, emisor de la documentación y receptor de la misma. Deberán además poder generarse las etiquetas que se consideren necesarias.
- Permitir crecer en la nube apostando por la innovación y la estandarización de una manera eficaz y eficiente.
El sistema de licitación electrónica y de registro general de entradas y salidas de documentación que se seleccione deberá ser una herramienta integral, y deberá contemplar al menos las siguientes funcionalidades, ya sea de forma monolítica o modular:
- Portal interno de licitación: definir licitaciones, tramitar su publicación, recibir la documentación asociada, proceder a la apertura de las ofertas y su adjudicación y gestionar las entradas y salidas de documentos oficiales, incluyendo aquellos que no correspondan a licitaciones públicas, como por ejemplo registro de recepción y emisión de documentos físicos ajenos al propio proceso de licitación.
- Portal externo de licitación: consultar las licitaciones vigentes y participadas, descargar pliegos y documentación sobre las licitaciones, presentar ofertas, recibir y consultar apuntes de registro y consultar el estado de las licitaciones y participaciones.
- Portal interno de Registro General de Entadas y Salidas: Registrar Entradas, Registrar Salidas, consultar registros y dar acceso a la información registrada a los usuarios internos.
- Notificaciones: enviar notificaciones o comunicaciones a licitadores o destinatarios de Salidas, presentar subsanaciones o respuestas.
- Integraciones: publicación de anuncios en boletines externos e integración con los sistemas propios de IMBISA.
Estas funcionalidades son detalladas en los anejos que acompañan a este pliego de prescripciones técnicas.
El proyecto se compone de los siguientes elementos:
- Plataforma: derechos de uso del sistema por los empleados de IMBISA que lo requieran y de los operadores económicos en general. Cualquier evolución futura en la plataforma consecuencia de cambios normativos o evoluciones desarrolladas por el adjudicatario estará así mismo incluida.
- Trabajos de configuración: para incluir los datos y el modelo de trabajo diseñado por IMBISA.
- Soporte y mantenimiento: atención a usuarios internos y externos, tanto técnica como funcional, y mantenimiento correctivo de los trabajos de configuración.
2. ANTECEDENTES
La tramitación de las licitaciones que tienen lugar en IMBISA se desarrolla, a día xx xxx, con un único órgano tramitador que es el Departamento de Compras.
En la situación actual, los licitadores presentan los documentos relacionados con un proceso de licitación en soporte físico, entregándolos habitualmente en el Registro General de IMBISA en la calle Xxxx Xxxxxxxxx, 13, Planta 9ª, aunque residualmente también realizan la entrega mediante el servicio de Correos.
A pesar de que el sistema actual funciona de manera adecuada, la directiva 2014/24/UE del Parlamento Europeo y del Consejo, de 26 de febrero de 2014, sobre contratación pública, así como la Ley 9/2017, de 8 de noviembre, de Contratos del Sector Público, por la que se transpone al ordenamiento jurídico español la mencionada Directiva 2014/24/UE, establecen que los medios de información y comunicación electrónicos deben convertirse en el método estándar en los procedimientos de contratación pública. Para dar cumplimiento a esta normativa se requiere disponer de un sistema que automatice las tareas y la gestión de los documentos implicados en los procesos de licitación, garantizando la fiabilidad, confidencialidad, simultaneidad y la aplicación de los principios informadores establecidos por IMBISA, la Directiva 2014/24/UE del Parlamento Europeo y del Consejo y la Ley 9/2017 de Contratos del Sector Público.
En este contexto, IMBISA precisa de un sistema que permita a los licitadores depositar sus documentos electrónicos con las garantías de confidencialidad, integridad, autenticidad y trazabilidad de acuerdo con lo dispuesto en la ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público y el Real Decreto 3/2010 por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica y requeridas en los procesos de licitación según las normas de contratación de IMBISA, así como la coexistencia de la presentación física y electrónica de documentos.
Adicionalmente, IMBISA dispone en la actualidad de un sistema de registro de la documentación oficial emitida y recibida por la empresa. Este sistema, instalado on-premise, no puede integrarse contra ningún otro sistema documental de la compañía, por lo que se desea su reemplazo por otro que se integre de forma adecuada contra el portal de gestión de adquisiciones.
3. DESCRIPCIÓN DEL SERVICIO
3.1 Fases del servicio
La ejecución del contrato se dividirá en las siguientes fases:
- Fase de configuración y adaptación del sistema: será necesaria la realización de los trabajos de configuración de las funcionalidades de la plataforma según los requerimientos de IMBISA, así como su integración con los sistemas internos que lo requieran.
Como parte de esta fase se llevarán a cabo pruebas de aceptación en un entorno establecido a tal efecto, que deberán incluir:
o pruebas técnicas a realizar por el equipo de sistemas (seguridad, interfaces, etc.),
o pruebas funcionales por parte de los administradores,
o pruebas de usuario final donde se seleccionará un grupo de empleados como piloto.
- Fase de migración: Será necesario migrar los documentos que están actualmente presentes en la plataforma de registro de entradas y salidas de documentación a la nueva plataforma, de manera que no haya ninguna pérdida de información ni de trazabilidad de los documentos previamente emitidos.
- Fase de uso de la plataforma: se procederá a poner en producción el sistema, una vez que finalicen con éxito las pruebas.
- Fase de soporte y mantenimiento: una vez implantado el sistema dará comienzo el servicio de atención a usuarios, tanto técnico como funcional, así como el mantenimiento evolutivo de los trabajos de configuración y el mantenimiento correctivo.
3.2 Descripción de las actividades de la fase de soporte
Una vez implantado el sistema, se iniciará el servicio de soporte técnico y funcional.
El horario del servicio de soporte será establecido por el adjudicatario y vendrá determinado por la propia naturaleza de los servicios que le sean encomendados. En cualquier caso, deberá cubrir el soporte al menos de lunes a viernes, de 8 a 18 horas, para los días no festivos en Madrid.
Este servicio deberá incluir las siguientes funcionalidades:
- Soporte funcional: soporte necesario para la resolución de dudas funcionales del sistema. El soporte deberá ser para todos los usuarios del sistema pertenecientes a IMBISA y para los operadores económicos que liciten usando el sistema, pudiendo solicitarse por vía telefónica, correo electrónico o mediante una herramienta de gestión provista por el prestador del servicio.
- Soporte técnico: soporte especializado por personal adecuado y con conocimiento del servicio prestado a IMBISA, para dar soporte técnico en las siguientes tareas:
o Soporte y atención de incidencias técnicas relacionadas con el uso inadecuado de la plataforma.
o Evaluación de nuevas versiones, realizando la presentación de las mismas a los administradores de IMBISA.
o Cambios en la configuración de los diferentes procesos que puedan ser acometidos al estar soportados por el estándar de la plataforma.
- Trabajos extraordinarios: trabajos realizados fuera del horario habitual para la fase de uso de la plataforma incluido su mantenimiento y soporte.
El soporte deberá mantener un registro de incidencias y consultas atendidas, incluyendo al menos los siguientes datos:
- identificación de la atención solicitada,
- datos del usuario que solicita el soporte,
- datos de la persona que atiende el soporte,
- datos de la persona que realiza los trabajos requeridos,
- fecha y hora en que se recibe la petición,
- fecha y hora en que se comienzan los trabajos,
- fecha y hora en que se resuelve la petición,
- descripción de los trabajos realizados para atender el soporte solicitado.
3.3 Características del servicio de soporte funcional y técnico
El licitador deberá proponer el número de personas que conformarán el equipo de soporte que debe prestar el servicio, de forma que se asegure la presencia de personal en el horario de cobertura y la gestión y organización del servicio. Para ello se deberá especificar:
- Número de personas que se consideran necesarias para el equipo de soporte y cómo se ha determinado ese número.
- Horario y organización del servicio (turnos, perfiles, funciones asignadas a cada perfil, tipología de conocimientos, habilidades, etc.).
- Características que la empresa considera que deben satisfacerse para prestar el servicio con garantías (años totales de experiencia, experiencia en el mantenimiento del sistema, etc.), las cuales deberán cumplirse por las personas que se vayan a encargar del servicio.
- Medidas que se adoptarán para asegurar la estabilidad del servicio y su funcionamiento ante incidencias de cualquier tipo y concretamente en el personal encargado del mismo (por ejemplo, cobertura del servicio ante bajas médicas, períodos vacacionales, etc.).
- Mecanismos que se proponen para el control y seguimiento del servicio, incluyendo los procedimientos utilizados y la estructura y contenido de los informes de seguimiento.
Considerando lo dispuesto en el Pliego de Cláusulas Particulares respecto a la subcontratación, la empresa adjudicataria indicará, en su caso, si parte del servicio va a ser cubierto por empresas subcontratadas, en cuyo caso explicitará el reparto de tareas y responsabilidades entre las empresas.
3.4 Entorno tecnológico
La plataforma objeto de este contrato estará basado en un modelo Software as a Service (SaaS).
La plataforma deberá integrarse con los siguientes servicios y sistemas de IMBISA:
- Perfil del contratante de IMBISA, ubicado en su página web que se ejecuta sobre tecnología WORDPRESS.
- Correo electrónico (Lotus Notes, Microsoft Exchange)
Así mismo deberá ser capaz de integrarse en el futuro con la solución de gestión documental que se ponga en funcionamiento, así como con el ERP actual de la empresa basado en tecnología SAP.
Para que los licitadores puedan dimensionar adecuadamente las necesidades actuales, como punto xx xxxxxxx se facilita la siguiente información:
- Número aproximado de gestores de contratación actuales en IMBISA: 50
- Número aproximado de registradores que realizan entradas y salidas de documentos en IMBISA: 15.
- Número aproximado de licitaciones publicadas: 125 / año.
- Número aproximado de usuarios externos / operadores económicos: 150.
- Número aproximado de documentos registrados en el sistema de entradas y salidas: 5.000/año.
4. REQUERIMIENTOS DE LA SOLUCIÓN
Los requerimientos se hallan descritos en el presente documento en:
- Anejo 2 “Modelo Operativo de la aplicación de licitación”
- Anejo 3 “Modelo Operativo de la aplicación de Registro”
- Anejo 4 “Requisitos del Proyecto”
- Anejo 5 “Requisitos de seguridad”
5. DESCRIPCIÓN Y REQUISITOS DEL PROYECTO
5.1 Descripción de los trabajos
La oferta deberá contemplar los siguientes elementos:
- Servicios de desarrollo para la configuración y adaptación: para incluir los datos y el modelo de trabajo diseñado por IMBISA.
- Servicios de uso de la plataforma: utilización de la plataforma por los gestores de contratación de IMBISA e integrantes de las mesas de contratación, así como por parte de los operadores económicos para las funcionalidades externas y de los usuarios internos que requieran la utilización del sistema de registro de documentos.
- Soporte: atención a usuarios, tanto técnica como funcional y mantenimiento de los trabajos menores de configuración como por ejemplo modificaciones en los flujos de aprobación, modificaciones en las notificaciones por correo electrónico, etc.
- Trabajos extraordinarios: bolsa de horas para trabajos realizados fuera del horario para la fase de uso de la plataforma, incluido su mantenimiento y soporte.
Los trabajos describirán las siguientes actividades:
- Plan de proyecto.
- Análisis y diseño técnico.
- Adecuación a los requisitos de seguridad.
- Formación a usuarios participantes en el proyecto.
- Configuración.
- Plan de pruebas.
- Implantación.
- Traspaso de conocimientos.
- Manual de usuario funcional y técnico. (en lengua castellana e inglesa)
- Soporte funcional y técnico.
- Descripción del modelo de funcionamiento del soporte funcional y técnico:
- Mecanismos de comunicación para consultas, resolución de incidencias y nuevas versiones de la plataforma.
- Intervinientes en el servicio.
En el Anejo 1 se incluye el detalle de las tareas a realizar.
5.2 Documentación de los trabajos
Como parte de los trabajos objeto del contrato, el adjudicatario se compromete a generar toda la documentación que sea aplicable según lo especificado en la metodología establecida por IMBISA para este tipo de proyectos. Esta documentación se deberá ir
realizando en paralelo a la implantación de los sistemas para asegurar su completitud y coherencia.
La documentación será de propiedad exclusiva de IMBISA sin que el contratista pueda conservarla, ni obtener copia de la misma o facilitarla a terceros. El adjudicatario deberá suministrar a IMBISA las nuevas versiones de la documentación que se vayan produciendo.
Toda la documentación se entregará en español, correctamente encuadernada y con la cantidad de copias que se determinen para cada documento, y será elaborada siguiendo la imagen corporativa de IMBISA. Asimismo, se entregará en soporte electrónico, en formato Microsoft Word XP o superior para facilitar su tratamiento, actualización y reproducción.
5.3 Metodología de los trabajos
El proveedor del servicio deberá explicar claramente la metodología a utilizar en el desarrollo del proyecto.
5.4 Duración de los trabajos
El plazo establecido para los trabajos de toma de requerimientos, configuración, adaptación y pruebas, será el que indique el adjudicatario en su oferta, con un máximo de tres meses.
La duración del servicio de utilización de la plataforma y su soporte será el tiempo resultante de restar a los cuatro años de duración del contrato inicial el período necesario para los trabajos de toma de requerimientos, configuración, adaptación y pruebas, de forma tal que la duración de este servicio se computará a partir de la aceptación de los trabajos de toma de requerimientos, configuración, adaptación y pruebas de la plataforma.
El contrato podrá ser prorrogado a partir de la fecha de su vencimiento mediante acuerdo expreso de las partes, por periodos mínimos de un año, si bien se podrán acordar prórrogas por plazos superiores siempre y cuando la duración total del contrato, incluidas estas posibles prórrogas, no supere los seis años.
5.5 Planificación, dirección y seguimiento de los trabajos
Para el control de la ejecución del contrato, existirá un Comité de Seguimiento con el detalle y funciones descritos en el Pliego de Cláusulas Particulares. Al inicio de la prestación de los servicios contratados ambas partes deberán designar a las personas que compondrán dicho Comité. Al respecto, IMBISA designará un Jefe de Proyecto cuyas funciones en relación con el objeto del presente pliego serán las siguientes:
- Velar por el cumplimiento de los trabajos exigidos y ofertados.
- Emitir las certificaciones parciales de recepción de los mismos.
El Jefe de Proyecto podrá delegar sus funciones en una persona de su equipo. Asimismo, podrá incorporar al proyecto durante su realización, las personas que estime necesarias para verificar y evaluar todas las actuaciones a su cargo.
El seguimiento y control del proyecto se efectuará sobre las siguientes bases:
- Seguimiento continuo de la evolución del proyecto entre el responsable del equipo de trabajo por parte del adjudicatario y el Jefe de Proyecto de IMBISA.
- Reuniones de seguimiento y revisiones técnicas, del responsable del equipo de trabajo por parte del adjudicatario, y del Jefe de Proyecto de IMBISA o persona en quien delegue, al objeto de revisar el grado de cumplimiento de los objetivos, las reasignaciones y variaciones de efectivos de personal dedicado al proyecto, las especificaciones funcionales de cada uno de los objetivos y la validación de las programaciones de actividades realizadas.
- Tras las revisiones técnicas, de las que se levantará acta, el Jefe de Proyecto de IMBISA podrá rechazar en todo o en parte los trabajos realizados, en la medida que no respondan a lo especificado en las reuniones de planificación o no superasen los controles de calidad acordados.
5.6 Nivel de servicio
El nivel de servicio estará basado en el nivel de disponibilidad y en el nivel de soporte.
5.6.1 Nivel de disponibilidad de servicio
El nivel de disponibilidad de servicio estará basado en el tiempo de indisponibilidad no planificada de la plataforma. Para esto se utilizará la siguiente fórmula:
NS: Nivel de Servicio o Porcentaje de disponibilidad (%)
TD: Tiempo disponible contratado. Para el cálculo de este tiempo se considerarán las 24 horas diarias solicitándose por tanto un servicio 24x7.
IP: Tiempo de indisponibilidad planificada. Para el cálculo de este tiempo se considerarán únicamente las indisponibilidades planificadas dentro del período de las 24 horas diarias comprendiendo hasta un xxxxxx xx xxxx horas al mes. Todo el tiempo de indisponibilidad planificada que supere estas diez horas se considerará como tiempo de indisponibilidad no planificada.
INP: Tiempo de indisponibilidad no planificada, considerándose para el cálculo de este tiempo toda parada que se haya producido dentro del tiempo disponible contratado durante el mes que corresponda y que no responda a una indisponibilidad planificada.
)
( ) (
Según el nivel de servicio obtenido se asignará una puntuación, la cual se utilizará para calcular las penalizaciones pertinentes.
Tramos | Penalización |
99%≤NS<100% | 0 puntos |
98%≤NS<99% | 25 puntos |
97%≤NS<98% | 50 puntos |
96%≤NS<97% | 75 puntos |
NS<96% | 100 puntos |
TOTAL MÁXIMO | 100 puntos |
El cálculo de este indicador se irá llevando desde el inicio de la prestación.
En cada periodo de cálculo, el valor de la Disponibilidad de Servicio no debe ser menor del 99%. El sobrepasar el mínimo indicado puede conllevar hasta una penalización de 100 puntos según los tramos indicados.
5.6.2 Nivel de soporte
El cálculo del nivel de soporte se realizará en base al tiempo de respuesta y a la criticidad de las solicitudes planteadas. Para esto se dividirán en:
- Incidencias: Suponen la pérdida de cualquier funcionalidad de la plataforma para uno o varios usuarios dentro del horario de disponibilidad del servicio de soporte.
- Consultas: Es una petición de información para resolver dudas acerca del uso de la aplicación.
5.6.2.1 Incidencias
Las incidencias deberán de tener un tiempo de resolución no superior a 8 horas dentro del horario de disponibilidad del servicio soporte. Para calcular el nivel de servicio de dichas incidencias se utilizará la siguiente fórmula:
NI: Número de incidencias presentadas en el mes que corresponda.
NIFP: Número de incidencias presentadas y resueltas fuera de plazo en el mes que corresponda.
NSI (%): Nivel de servicio o porcentaje de incidencias resueltas en plazo en el mes que corresponda.
( ) ( )
Según el nivel de servicio obtenido se asignará una puntuación, la cual se utilizará para calcular las penalizaciones pertinentes.
Tramos | Penalización |
NSIncidencias=100% | 0 puntos |
99%≤NS<100% | 25 puntos |
98%≤NS<99% | 50 puntos |
97%≤NS<98% | 75 puntos |
NS<97% | 100 puntos |
TOTAL MÁXIMO | 100 puntos |
5.6.2.2 Consultas
Las consultas deberán tener un tiempo de resolución menor a 24 horas dentro del horario de soporte. Para calcular el nivel de servicio de dichas consultas se utilizará la siguiente fórmula:
NI: Número de consultas presentadas en el mes que corresponda
NICP: Número de consultas presentadas y resueltas fuera de plazo en el mes que corresponda.
NSC (%): Nivel de servicio o porcentaje de consultas resueltas en plazo en el mes que corresponda.
)
( ) (
Según el nivel de servicio obtenido se asignará una puntuación, la cual se utilizará para calcular las penalizaciones pertinentes.
Tramos | Penalización |
NSC=100% | 0 puntos |
99%≤NS<100% | 5 puntos |
98%≤NS<99% | 10 puntos |
97%≤NS<98% | 15 puntos |
NS<97% | 20 puntos |
TOTAL MÁXIMO | 20 puntos |
5.6.3 Penalizaciones
Se impondrá una penalización de facturación como resultado del servicio entregado con un límite máximo del 20% según la siguiente fórmula:
( )
6. OFERTA TÉCNICA
El licitador deberá presentar una oferta técnica que deberá recoger los trabajos a realizar, la estimación del esfuerzo necesario para su desarrollo y su planificación, así como cualquier otra información adicional que considere de interés.
La oferta técnica no deberá superar, en ningún caso, las 100 páginas, a una cara, formateadas en un tamaño de página A4, con interlineado de quince puntos y tamaño de letra xx xxxx puntos con tipografía «Arial» o similar. Aquellas ofertas que excedan sustancialmente de dicha extensión serán excluidas de la licitación.
Estructura normalizada y contenido de la propuesta técnica.
Con independencia de que el licitador pueda adjuntar a su propuesta técnica cuanta información complementaria considere de su interés, deberá estar obligatoriamente estructurada de la siguiente forma:
- Índice.
- Características generales.
- Identificación de la propuesta.
- Adecuación funcional y técnica de la oferta.
Se incorporará al inicio de este apartado el resumen de los aspectos más significativos y relevantes de la solución aportada.
Se deberá incluir información detallada de la propuesta en relación con los requisitos de este pliego y siguiendo su misma estructura.
Se incluirá en este capítulo la descripción de las medidas dispuestas por el oferente para asegurar la calidad de los trabajos: metodologías, medios materiales, aseguramiento de calidad, seguridad y confidencialidad, así como aquellas otras que se prevé aplicar para vigilar y garantizar el adecuado cumplimiento del contrato.
Se indicará en este apartado el periodo de garantía ofrecido ampliando, en su caso, el mínimo de seis meses establecido en el Pliego de Cláusulas Particulares.
La arquitectura de la plataforma deberá estar diseñada para tener en cuenta los requerimientos de disponibilidad correspondientes al nivel de servicio ofertado.
- Planificación del desarrollo del proyecto
Se indicarán los distintos procedimientos utilizados para definir las fases del proyecto, sus actividades y cronograma de trabajos. Se informará del plazo de realización del proyecto, y expresamente las fases de configuración y adaptación. El cronograma deberá mostrar la planificación detallada del trabajo a realizar semanalmente, las fechas de inicio y finalización de todas las fases y etapas y el esfuerzo estimado en horas/hombre para cada una de ellas.
- Características del servicio de soporte funcional y técnico
Durante la vigencia del contrato es necesario disponer de un servicio de soporte que garantice la operatividad del sistema; por ello se describirá en este apartado, conteniendo
información respecto del:
- Tipo y características de soporte así como perfil del personal que lo realizará, para dar el adecuado servicio al requerimiento solicitado.
- Nivel de servicio:
Se describirá en este apartado los mecanismos y procedimientos que se proponen para medir el nivel de servicio.
Se deberá incluir, dentro de la descripción del nivel de servicio, responsabilidades y los roles de seguridad de las partes implicadas en relación con al menos los siguientes procesos, cuando afecten a la información de IMBISA:
- Protección frente a código malicioso (malware).
- Copias de seguridad.
- Controles criptográficos.
- Gestión de vulnerabilidades.
- Gestión de incidentes de seguridad.
- Pruebas de seguridad y comprobación del cumplimiento técnico.
- Gestión de pistas de auditoría y protección de evidencias.
- Protección y entrega de la información a la finalización del acuerdo.
- Autenticación y control de acceso.
- Gestión de identidades y derechos de acceso.
Anejo 1: Detalle de las tareas a realizar
1. Plan de proyecto. Al inicio del contrato se realizará un plan detallado de todas las tareas y actividades que se tienen que llevar a cabo en el proyecto, indicando para cada una de ellas los recursos y perfiles que las tienen que realizar.
En este plan de proyecto se deberá definir las diferentes fases, los participantes, las responsabilidades de cada uno de los participantes en el proyecto (Proveedor/IMBISA), y los entregables de cada fase, adjuntando una matriz de responsabilidades donde se detallen estos aspectos.
2. Análisis y diseño técnico de la solución informática.
La empresa adjudicataria deberá elaborar, en colaboración con el personal de IMBISA, un documento en el que se recogerá el diseño técnico del sistema, entendiendo como tal las configuraciones y adaptaciones a llevar a cabo en el transcurso del proyecto. Este documento recogerá al menos los siguientes aspectos:
- Definición de las cargas iniciales en el sistema.
- Configuración y personalización del producto.
- Integración de la solución con el sistema de correo electrónico usado en IMBISA.
- Publicación de la solución en el portal de contrataciones de la web pública de IMBISA.
- Definición de usuarios, roles y permisos de los distintos usuarios del sistema.
- Análisis de la integración de los usuarios, roles y permisos con los sistemas de seguridad de IMBISA.
3. Configuración y personalización del software de la plataforma. La configuración debe contemplar entornos separados para pruebas y producción.
4. Tareas de integración del software de la plataforma con los sistemas de IMBISA indicados en el punto 3.4.
5. Gestión de la seguridad de acceso a la plataforma seleccionada, tanto desde puestos de IMBISA como desde otras ubicaciones, e integración con sistemas internos de autenticación de la empresa.
6. Redacción de la documentación entregable.
7. Elaboración del plan de pruebas.
8. Tareas de soporte a las pruebas de integración y a las pruebas de usuario previas a la puesta en producción del sistema.
9. Traspaso de conocimientos necesarios para el personal de los departamentos de Compras y Sistemas de Información de IMBISA, mediante sesiones formativas apoyadas en material generado al efecto.
Anejo 2: Modelo Operativo para la aplicación de Licitación
1. Introducción
La tramitación de las licitaciones que tienen lugar en IMBISA es realizada por el Departamento de Compras. Para llevar a buen fin las licitaciones, los implicados en estos procesos realizan, principalmente, los siguientes trabajos y funciones:
Coordinación de las distintas actividades y de la gestión de los documentos que constituyen la licitación de obras, bienes o servicios incluyendo, si es necesario, la publicación de los Pliegos en el perfil del contratante de IMBISA.
Gestión y envío de cartas de invitación a los posibles licitadores, si el procedimiento de contratación lo requiere.
Tramitación de las solicitudes de participación, en su caso, y de las ofertas recibidas de los licitadores, así como toda aquella documentación complementaria que se requiera dentro del ciclo de vida de una licitación.
Gestión de los informes de evaluación de las ofertas emitidos por los órganos que tienen encomendada la gestión del bien o servicio licitado.
Coordinación de los informes que constituyen la propuesta de adjudicación que ha de ser enviada al órgano de adjudicación o a la mesa de contratación, según corresponda.
Comunicación a los distintos licitadores del resultado de la adjudicación de una licitación.
Publicación del resultado del proceso de licitación en el perfil del contratante de IMBISA, si este así lo requiere.
Publicación de anuncios de licitación y de resultados.
2. Información a tratar
El proyecto tratará la siguiente información:
Documentación acreditativa de la capacidad de obrar y de la concurrencia de los requisitos necesarios para contratar, correspondientes a los licitadores.
Documentación para la selección de candidaturas.
Ofertas recibidas de los licitadores.
Comunicaciones y notificaciones de todo tipo enviadas por IMBISA.
Comunicaciones de todo tipo recibidas de los candidatos y licitadores.
Información relacionada con la firma electrónica de los documentos recibidos: NIF del firmante, nivel de autorización, etc.
Información relativa a las distintas fases y estados por los que pasa un proceso de licitación.
Datos, documentos e información de todo tipo que definan una licitación: fechas límites, pliegos, composición de los sobres, condiciones de apertura de los sobres, procedimiento de adjudicación, tipo o modalidad de contrato, etc.
3. Productos a obtener
Los productos a obtener son los siguientes:
Información acerca de atributos y eventos de todo tipo relacionados con documentos presentados, enviados o recibidos por vía electrónica.
Un sistema de recepción electrónica de solicitudes de participación y ofertas.
Un sistema integrado y coordinado con el sistema de registro de la documentación en el proceso de una licitación.
Un sistema de gestión de notificaciones electrónicas, para envío y recepción de todo tipo de comunicaciones y requerimientos, que permita tener constancia de la recepción por parte de las personas e entidades que se relacionan con IMBISA.
4. Participantes y funciones
El sistema tiene participantes tanto externos como internos, así como sistemas de información ya existentes en IMBISA. Se realiza una breve descripción de los primeros, seguida de una asignación de funciones principales:
Operadores económicos (véase el glosario).
Gestores de contratación (véase el glosario).
Mesa de contratación: grupo de personas que realiza aperturas en algunos procesos de contratación.
Autorizadores: responsables de los gestores de contratación que realizan la autorización de ciertas acciones de estos.
Participante | Función | ||
Externo | | Presentar ofertas de licitación y/o solicitudes de participación | |
Operadores | | Recibir notificaciones | |
económicos | | Enviar comunicaciones | |
| Presentar documentación para una licitación | ||
Interno | | Definir los datos, incluyendo la composición de los sobres (conjuntos | |
estructurados de documentos) de una licitación | |||
| Enviar notificaciones a los operadores económicos | ||
Gestores de | | Xxxxxxxx y enviar anuncios para su publicación en los medios que sean | |
contratación | necesarios (perfil del contratante y DOUE en su caso) | ||
| Gestionar los documentos recibidos de los operadores económicos | ||
| Acceder a los datos de auditoría del proceso de licitación | ||
| Realizar la apertura electrónica de sobres | ||
Miembro de la | | Realizar la apertura electrónica de sobres en los procedimientos para los | |
mesa de | que esté establecida su competencia | ||
contratación | | Gestionar los documentos recibidos de los operadores económicos | |
Supervisores Autorizadores | | Autorizar acción | |
Interfaz | Perfil del contratante de IMBISA | Redirigir a los operadores económicos al sistema para que puedan realizar operaciones en él |
Aplicación de registro de documentos | Gestionar la documentación recibida indicando fecha y hora de llegada, receptor de la documentación y número de serie |
5. Descripción general del sistema
5.1. Subsistemas
Las principales soluciones comerciales para la gestión de la licitación electrónica cubren las distintas funcionalidades mediante módulos o subsistemas que suelen ser bastante similares. La plataforma de licitación a implantar en IMBISA debe contar con los siguientes módulos o conjuntos de funcionalidades: licitador, gestor, notificaciones e integraciones.
Licitador (módulo externo)
Módulo que debe permitir la participación como operador económico en las licitaciones en curso. Dentro de esta participación, debe permitir la presentación de solicitudes de participación, la presentación de ofertas, la remisión de escritos, el acceso a los pliegos y la obtención de apuntes de registro.
Gestor (módulo interno)
Módulo que debe permitir la definición de los datos de una licitación, la publicación de la misma, la recepción de consultas, la apertura de sobres, gestión de subsanaciones y la adjudicación de la licitación.
Notificaciones
Módulo que debe permitir el registro y envío de notificaciones y la puesta a disposición del notificado, así como el acceso a la notificación y el registro fehaciente del mismo.
5.2. Proceso previo a la puesta en producción del sistema
En este apartado se describen las tareas que deben realizarse antes de la implantación en producción de la solución. Se definen primero algunos de los conceptos utilizados en las tablas que se presentan en los apartados siguientes:
Soporte: medio material mediante el que se cubrirá la función.
Perfil: qué perfil de los disponibles en el sistema tiene asignada la función descrita. Se han considerado los siguientes perfiles:
o GES: Gestor de contratación de IMBISA.
o MES: Miembro de la Mesa de Contratación.
o AUT: Autorizador.
o ECO: Operador económico.
o INF: Responsables informáticos
o LIC: Proveedor del servicio de licitación electrónica.
o WBE: perfil del contratante de IMBISA.
o REG: Aplicación REG (Registro general).
Las siguientes tareas deberán ser realizadas como paso previo a la implantación del nuevo sistema:
Descripción | Funciones | Perfil |
Provisión de usuarios | Carga inicial de usuarios con acceso a la aplicación. | INF / LIC |
Parametrización de valores | Carga de tablas maestras y ajuste de valores a los límites existentes en IMBISA | GES / LIC |
Carga de festivos | Carga de días festivos y no hábiles en el sistema para el cómputo de plazos. | LIC |
No se realizará, en el paso a producción, la migración de las licitaciones en curso al nuevo sistema. Estas licitaciones seguirán realizándose con el método anterior.
5.3. Secuencia operativa de funcionamiento
En este apartado se describe, desde el punto de vista de los participantes, la secuencia de actividades que son necesarias para una explotación adecuada del sistema.
5.3.1. Operador económico (ECO)
Descripción | Funciones | Soporte | Perfil |
El operador económico accede al perfil del contratante. | Consulta de licitaciones. Detalle de una licitación | Navegador | ECO |
El operador económico se suscribe a la recepción de avisos cuando se publican licitaciones de un determinado tipo. | Suscripción a alertas. | Navegador | ECO |
El operador económico expresa interés por participar en una licitación. | Inscripción a una licitación. | Navegador | ECO |
El operador económico presenta una solicitud de participación o una oferta. | Presentación de ofertas. Presentación de solicitudes de participación. | Navegador | ECO |
El operador económico accede a una notificación recibida | Recepción de notificaciones | Navegador | ECO |
El operador económico remite escritos a IMBISA | Remisión de escritos y respuestas | Navegador | ECO |
El operador económico accede al estado de sus licitaciones | Consulta del estado de las licitaciones | Navegador | ECO |
5.3.2. Gestor de contratación
Descripción | Funciones | Soporte | Perfil |
El gestor de contratación define una licitación. | Creación de licitaciones. | Navegador | GES |
El gestor de contratación publica una licitación. | Publicación de licitaciones. | Navegador | GES |
El gestor de contratación realiza una notificación. | Envío de notificaciones. | Navegador | GES |
El gestor de contratación realiza una modificación de una licitación. | Modificación de licitaciones. | Navegador | GES |
El gestor de contratación envía un aviso. | Emisión de avisos. | Navegador | GES |
El gestor de contratación abre sobres. | Apertura de sobres. | Navegador | MES / GES |
El gestor de contratación accede a las comunicaciones o envíos recibidos. | Recepción de comunicaciones. | Navegador | GES |
El gestor de contratación incorpora documentación recibida en papel. | Incorporación de ofertas en papel. | Navegador | GES / MES |
El gestor de contratación consulta las comunicaciones/ notificaciones practicadas | Consulta de las comunicaciones/notificaciones practicadas. | Navegador | GES |
5.3.3. Miembro de la Mesa de contratación
Descripción | Funciones | Soporte | Perfil |
La mesa de contratación realiza la apertura sobres. | Apertura de sobres. | Navegador | MES / GES |
5.3.4. Autorizador
Descripción | Funciones | Soporte | Perfil |
Autorizar notificaciones. | Autorizar acciones. | Navegador | AUT |
Glosario de términos
1. Abreviaturas
CET: Central European Time.
CEST: Central European Summer Time.
CPV: Common Procurement Vocabulary.
DOUE: Diario Oficial de la Unión Europea.
SaaS: Software as a Service.
URL: Uniform Resource Locator
WCAG: Web Content Accesibility Guidelines
2. Conceptos
Gestor de contratación: cualquier empleado de IMBISA con permisos de acceso sobre el sistema a desarrollar.
Tipo o modalidad de contrato: determina si el contrato se encuadra en obras, servicios o suministros.
Operador económico: cualquier persona física o jurídica, organización, o grupos de empresas (UTE) u otras organizaciones, que provee servicios, suministros u otros tipos de trabajos a cualquier poder adjudicador.
Órgano tramitador: cualquier departamento o unidad con capacidad reconocida para tramitar licitaciones de forma autónoma en la normativa de IMBISA. Hasta la fecha sólo el departamento de Compras tiene esta capacidad.
Procedimiento de adjudicación: cualquiera de los procedimientos para seleccionar al adjudicatario que se prevén en la normas internas de IMBISA, así como en la normativa española y europea aplicable que regulan la contratación pública: procedimiento abierto, restringido, etc.
Anejo 3: Modelo Operativo para la aplicación de Registro General de Entrada y Salida
1. Introducción
La aplicación realizará el Registro de Entrada y Salida, digitalizando la documentación recibida y seleccionando los departamentos y/o destinatarios a los cuales se va a distribuir.
La gestión del registro de Entradas y Salidas de documentación interno en IMBISA incluye los siguientes trabajos y funciones:
Registro de Entrada y Salida de Documentos en distintos departamentos situados en las distintas sedes de la empresa.
Distribución de la información de Entrada, ya sea por email o por notificaciones a los departamentos y destinatarios internos de la empresa.
Distribución de la información de Salida, ya sea por email, por correo físico o por notificaciones electrónicas, a los destinatarios externos de la empresa.
Al efectuar la entrada y salida de documentos se emitirán las correspondientes etiquetas para certificar el número, fecha y hora de la entrada.
2. Registro de Entrada
2.1. Entrada del documento
Se definirá un formulario para el Registro de Entrada durante la fase de análisis que determinará la conveniente adaptación del mismo a las necesidades de los usuarios de IMBISA.
Se seleccionará los campos Origen y Destinatario, cuyas listas de valores se pueden haber definido previamente con el fin de facilitar el alta a las personas encargadas del registro.
El encargado del registro rellenará el correspondiente formulario, digitalizará el documento y marcará los departamentos internos o usuarios individuales de IMBISA que sean destino del documento. Igualmente las listas de los departamentos internos y sus responsables o los datos del personal de IMBISA podrán haberse cargado previamente o definirse en el momento durante el proceso Entrada.
A cada destino seleccionado se le enviará de forma automática un aviso por correo electrónico indicando la existencia de un nuevo documento en el Registro de Entrada.
2.2. Emisión de la etiqueta
Tras realizar la entrada, el usuario de registro imprimirá la etiqueta cuyo diseño se habrá realizado previamente desde la herramienta de administración.
Dicha etiqueta se configurará de acuerdo a las necesidades de los usuarios.
Esta misma etiqueta se puede introducir como sello virtual en el documento digitalizado, incluyendo aquellos datos que queramos del Registro de entrada.
De esta forma finalizará el proceso de realizar una nueva entrada en el Registro General. A partir de este momento la documentación estará disponible para los destinatarios desde la propia aplicación.
2.3. Distribución de los documentos
Una vez que se ha registrado la documentación de entrada, los usuarios individuales o los responsables de los departamentos seleccionados como destinatarios, podrán consultar la documentación.
Cuando un registro tenga como destino a un departamento interno, este incluirá una lista de responsables que serán los usuarios que actuarán en nombre del departamento y opcionalmente una dirección email genérica del propio departamento interno. Las notificaciones para un departamento se emitirán al email genérico y a los emails individuales de esa lista.
Cada usuario/departamento solo verá aquellos registros a los que sea asignado como destinatario.
2.4. Acceso de los usuarios al registro de entrada
Cada movimiento realizado sobre el registro se almacenará en un histórico sobre la tramitación seguida por el mismo, de forma que siempre los usuarios del Registro General puedan conocer la situación del documento y los pasos seguidos desde su registro inicial.
Los datos almacenados por cada tramitación realizada se podrán consultar en un informe.
Se definirá el flujo de trabajo a seguir para cada tipo de documento en el momento de la toma de requisitos.
3. Registro de Salida
3.1. Salida del documento
Para el Registro de Salida se seguirá un planteamiento similar al del Registro de Entrada. El punto xx xxxxxxx será un formulario de datos que será definido en la fase de análisis.
Se definirá el flujo de trabajo a seguir para cada tipo de documento en el momento de la toma de requisitos.
4. Integración con la Licitación electrónica y notificaciones
Toda la información producida durante la licitación electrónica se incorporará en el registro correspondiente de Entrada o Salida de forma transparente, usándose la misma numeración y sellos de tiempo del registro interno.
Las salidas de documentación que estén en formato electrónico se podrán efectuar a través del módulo de notificaciones electrónicas de la plataforma.
5. Libros de registro
Se podrán generar en cualquier momento los informes de los Libros de Registro, para visualizar de esta forma, por ejemplo, las Entradas producidas en el mes en curso, en un rango de fechas, desde un Origen determinado, etc.
El formato del informe será totalmente personalizable y se adaptará a las necesidades de los usuarios. Estos informes se obtendrán siempre a partir de una búsqueda sobre el histórico del registro, tanto de entrada como de salida, y posteriormente se generará el informe incluyendo los datos obtenidos tras la búsqueda.
Existirá la posibilidad de crear Libros de registro independientes para cada departamento.
6. Acceso a la aplicación de Registro General de Entrada y Salida
La aplicación de registro en ningún caso podrá ser accedida por usuarios externos.
Se podrá acceder a la aplicación de Registro General independientemente del acceso a la parte interna de la aplicación de Licitación electrónica.
Anejo 4: Requisitos del proyecto
1. Introducción
A continuación se describen los requerimientos del sistema informático en el momento de la implantación y puesta en producción, diferenciando los que se consideran obligatorios de los considerados como opcionales.
2. Requisitos funcionales obligatorios
En este apartado se describen los requisitos funcionales obligatorios con los que debe contar la plataforma.
2.1. Requisitos funcionales generales de la plataforma
Modelo SaaS/Cloud
La plataforma deberá seguir el modelo SaaS (Software as a Service) para poder beneficiarse de una constante evolución tecnológica, reducción de costes y aumento de eficacia y eficiencia.
Se deberá garantizar el compromiso con la innovación a través de la existencia de un número adecuado de versiones anuales.
Solución de notificaciones modular
La plataforma deberá contar con un módulo de notificaciones que permita ser utilizado por otras aplicaciones de IMBISA para realizar la remisión de notificaciones.
Extracción de la información
La plataforma deberá posibilitar la descarga de información de manera sencilla (preferentemente por medio de hojas de cálculo y gestores de texto) por parte del usuario.
Carga de información
La plataforma deberá contar con herramientas para la carga de información de manera sencilla (preferentemente por medio de hojas de cálculo y gestores de texto) por parte del usuario.
Usabilidad de la plataforma
La herramienta debe ser intuitiva y fácil de utilizar, que permita un aprendizaje sencillo a todos los actores implicados, tanto externos como internos, redundando en un ahorro de costes de formación en la utilización de la funcionalidad de la plataforma.
Multilenguaje
La herramienta permitirá el acceso a la misma en diferentes idiomas, siendo el mínimo castellano e inglés.
Almacenamiento de la información de licitación
El sistema almacenará la información de los sobres remitidos por los operadores económicos de forma cifrada, impidiendo el acceso a los mismos hasta el cumplimiento de la fecha y
hora de apertura de cada sobre, tras la cual solo permitirá el descifrado de los documentos a los usuarios autorizados a esa función.
Formatos de ficheros admitidos
La plataforma aceptará exclusivamente los siguientes formatos de fichero: PDF, PDF/A, PS, DOC, DOCX, XLS, XLSX, ODT, ODS, TXT, JPG, PNG, TIFF, SVG, GZ (Gnu ZIP), ZIP, CSV y MHTML.
Estos formatos podrán actualizarse posteriormente en caso de que aparezcan nuevos estándares.
Certificados admitidos para firma
Herramientas de logs
Se requiere la existencia de logs del sistema para registro de las operaciones realizadas y los errores producidos, incluyendo entre otros eventos, la fecha y hora de presentación de solicitudes de participación, ofertas y documentación complementaria, aclaraciones y subsanaciones, comunicaciones y notificaciones, rectificaciones y modificaciones, autorizaciones, así como de los licitadores, gestores y usuarios que han realizado la acción, etc.. Como se establece en los Requisitos de Seguridad, SEG-18, ha de almacenar eventos de las actividades realizadas por los usuarios de la plataforma y por el proveedor de la misma, tanto de las funcionalidades de negocio como relacionadas con la gestión de usuarios (ej. altas y bajas de usuario) como de los derechos de acceso.
El sistema deberá disponer de herramientas o procedimientos adecuados que permitan realizar de forma sencilla por todos los departamentos intervinientes en el proceso de contratación y la Intervención Delegada del Banco de España, la consulta y explotación de la información registrada, la cual deberá estar disponible para su consulta al menos 5 años. Adicionalmente, esta información deberá poder volcarse en un repositorio externo en un formato legible por aplicaciones ofimáticas normales. Este volcado deberá poder realizarse de forma sencilla y con diferentes filtros de selección de datos a exportar.
Integración con registro electrónico
Las aplicaciones de licitación electrónica y de notificaciones electrónicas estarán integradas con la aplicación de registro de entradas y salidas, tanto para los documentos de entrada como para los de salida.
Sistema de autenticación
Empleo de un sistema seguro para la autenticación y autorización de usuarios que permita la definición de diferentes perfiles tanto para las tareas de gestión como de consulta.
2.2. Requisitos funcionales respecto a la interfaz de usuario
Soporte de navegadores
Las páginas web del sistema estarán optimizadas para las versiones de los principales navegadores, debiendo visualizarse correctamente al menos en Microsoft Internet Explorer, Microsoft Edge, Mozilla Firefox, Google Chrome y Safari.
Nivel de accesibilidad Web
Las páginas web del sistema cumplirán con las normas de accesibilidad nivel Doble A WCAG.
Inclusión de la imagen institucional de IMBISA
El sistema deberá presentar la información usando el diseño de la imagen institucional de IMBISA, tanto en subsistemas externos o internos, como en los documentos y correos generados por el sistema.
2.3. Requisitos funcionales respecto al módulo de licitaciones externo
Consulta de licitaciones
El sistema permitirá a un usuario consultar las licitaciones en curso, filtrándolas según criterios, entre los que estarán al menos los siguientes: objeto del contrato, valor estimado y adjudicado, en su caso, del contrato, tipo o modalidad de contrato, código CPV y fase de licitación (anuncio, presentación, adjudicación, adjudicado).
Detalle de una licitación
El sistema mostrará a cualquier usuario debidamente identificado la información de detalle de la licitación solicitada. En el detalle, el sistema mostrará la información relevante de la licitación, entre otra, el código identificativo de la licitación, el procedimiento, el importe estimado de licitación, la fecha de publicación, la fecha y hora límite de presentación si existiera (incluyendo en cualquier caso la zona horaria aplicable), los documentos que rigen la contratación si aplican, el código CPV y un enlace para poder participar en el proceso, si aplica.
Información horaria
El sistema presentará al usuario, de forma permanente, la hora oficial en ese momento, indicando además el huso horario que se muestra, el cual será CET (Hora Central Europea) o CEST (Hora Central Europea xx Xxxxxx) según corresponda al momento del año.
Inscripción a una licitación
El sistema deberá registrar, mediante una acción clara y distinguible, el interés de un operador económico en una licitación. Una vez expresado este interés, el sistema permitiría al operador económico el acceso a las funcionalidades de presentación e interacción con la licitación.
Presentación de solicitudes de participación y ofertas
Los operadores económicos debidamente identificados podrán presentar solicitudes de participación y ofertas a una licitación. El sistema pedirá la identificación mediante
certificado digital. Se comprobará que el/los sobre/s presentado/s se ajusta/n a la estructura definida por los gestores de contratación.
En el momento de la presentación, el sistema pedirá al usuario la firma de la misma y sellará y cifrará en el acto de registro la documentación de solicitud de participación u oferta. Acto seguido, tras su registro, presentará al usuario el justificante de registro correspondiente. El sistema almacenará los datos firmados, sellados y cifrados y garantizará la identidad del licitador, la confidencialidad, la integridad, el no repudio y su inaccesibilidad hasta la apertura de las solicitudes de participación o de las ofertas.
Durante el proceso de preparación del envío, el sistema proporcionará al operador económico una visión del formato de los sobres a presentar, indicando claramente cuáles de los documentos son obligatorios, así como el progreso de completitud de los mismos.
Consulta del estado de las licitaciones
El sistema mostrará al operador económico un listado de las licitaciones en las que ha realizado alguna acción, detallando para cada una su estado general y en qué condición actúa el operador económico en la misma (interesado, licitador, seleccionado, adjudicatario, etc.). En caso de existir algún apunte de registro asociado al operador y la licitación, el sistema permitirá la descarga del mismo.
Remisión de escritos y respuestas
El sistema debe permitir a los operadores económicos remitir escritos dirigidos a IMBISA, así como enviar respuestas a notificaciones que reciban. Si la notificación requiere respuesta con una estructura determinada, el sistema mostrará dicha estructura al operador económico para su cumplimentación. En todos los casos, el operador económico siempre podrá incluir texto libre y los documentos adjuntos que considere necesarios. Los escritos y los documentos adjuntos formarán parte del expediente de contratación.
2.4. Requisitos funcionales respecto al módulo de licitaciones interno
Creación de licitaciones
El sistema permitirá al gestor de contratación crear una nueva licitación, definiendo sus datos identificativos: tipo de licitación, valor estimado de licitación, composición de los sobres, composición de la mesa, fecha y hora límite de presentaciones, fecha y hora de apertura de los sobres, pliegos, etc.
Consulta de licitaciones
El sistema presentará al gestor de contratación una lista de las licitaciones almacenadas en el sistema, pudiendo filtrar la misma, al menos, por los criterios siguientes: objeto del contrato, valor estimado del contrato, tipo o modalidad de contrato, código CPV y fase de licitación (anuncio, presentación, adjudicación, adjudicado).
Publicación de licitaciones
El sistema permitirá al gestor de contratación publicar una licitación ya creada. La publicación permitirá el acceso a la licitación desde el módulo externo.
Modificación de licitaciones
El sistema permitirá al gestor de contratación modificar los datos de una licitación ya existente. Se garantizará la trazabilidad de los datos modificados. Si los datos modificados alteran de forma sustancial una licitación publicada, el sistema alertará a los interesados y publicará, a instancia del gestor de contratación, la información necesaria en el módulo externo.
Emisión de avisos
El sistema permitirá al gestor de contratación realizar un aviso a los operadores económicos interesados en la licitación. El sistema permitirá incluir texto libre y documentos asociados. El aviso se realizará por correo electrónico, no mediante una notificación. El sistema dará la posibilidad al gestor de publicar el aviso en el apartado de la licitación del módulo externo.
Apertura de sobres
El sistema permitirá a la Mesa de contratación o al gestor de contratación, según corresponda, la apertura de los sobres. Cada sobre no podrá ser abierto hasta que se cumpla el plazo fijado para dicho sobre en la aplicación. El sistema permitirá, en la definición de la licitación, establecer el quorum necesario de la Mesa para poder proceder a la apertura y garantizará que solo los miembros de la Mesa o el gestor de contratación, según corresponda, tengan capacidad para la apertura.
Recepción de comunicaciones
El sistema permitirá a los gestores de contratación acceder a las comunicaciones y envíos de documentación complementaria que realicen los operadores económicos participantes en una licitación.
Constancia de la presentación de ofertas en papel
El sistema permitirá a los gestores de contratación y a la Mesa de contratación dejar constancia de la presentación de ofertas recibidas en papel. El sistema permitirá la entrada de datos estructurados y dejará constancia de la presentación de documentos en papel.
Autorizar acciones
El sistema marcará como pendientes de autorizar las acciones que requieran dicha autorización (publicación de licitaciones, envío de comunicaciones, etc.). Además, permitirá a los autorizadores visualizar las acciones que tengan pendientes de autorizar. Para cada acción, se podrá consultar el contenido generado por el gestor de contratación y proceder a su devolución o aprobación. En caso de autorizar una acción, el sistema la ejecutará.
Envío de notificaciones
El sistema debe permitir al gestor de contratación remitir una notificación a un operador económico que esté participando en una licitación. El sistema debe permitir al gestor de contratación la introducción de una estructura de respuesta normalizada, así como texto libre y documentos adjuntos. El sistema almacenará la notificación marcándola como
pendiente de autorización, y la pasará al autorizador correspondiente. El sistema utilizará el módulo de notificaciones para la práctica final de la notificación.
Consulta de notificaciones practicadas
El sistema debe permitir al gestor de contratación la comprobación del estado de una notificación. Esa consulta incluirá, al menos, un texto descriptivo sobre el estado de la notificación (pendiente, recibida, rechazada, vencida, etc.), un identificador claro del destinatario, la fecha y hora de remisión, y la fecha y hora de recepción, si existiera. Adicionalmente, se permitirá el acceso al contenido de los datos remitidos en la notificación, así como al acuse de recibo del acceso por parte del operador económico, si este existiese.
2.5. Requisitos funcionales respecto al registro interno de Entradas y Salidas
Registro de documentación
El sistema deberá disponer de un registro de documentación que permita identificar de forma unívoca cualquier documento recibido o emitido por IMBISA, indicándose quién ha sido el responsable de su emisión/recepción, fecha y hora de la emisión, título y cualquier otro que sea conveniente. El sistema deberá poder generar etiquetas para pegar en cada documento, utilizando para ello las impresoras actualmente en uso (modelo SII SLP620). Las etiquetas obtenidas deberán ser iguales a las utilizadas actualmente.
Registro de Entradas
El sistema permitirá a los registradores efectuar las entradas de documentación. Los registradores generales tendrán acceso a todas las entradas, los registradores de departamento solo a las entradas de su departamento.
Registro de Salidas
El sistema permitirá a los registradores efectuar las salidas de documentación. Los registradores generales tendrán acceso a todas las salidas, los registradores de departamento solo a las salidas de su departamento.
Consultas e Informes de Registros
Los registradores podrán consultar los registros efectuados, ya sea en forma de consultas por pantalla, ya sea en forma de libros de registros. Al igual que en otros apartados, los registradores generales tienen acceso a todos los registros, y los registradores de departamento únicamente a los registros de su departamento.
Acceso de los usuarios internos de IMBISA a los registros
Los usuarios que hayan sido designados como destinatarios de un registro podrán acceder bien conectándose directamente al portal interno del registro, bien pulsando un enlace incluido en el mensaje de notificación de entrada que hayan recibido en su correo electrónico. Solo podrán acceder a los registros de los que sean destinatarios.
Acceso de los usuarios internos responsables de departamento de IMBISA a los registros
Los usuarios que hayan sido designados como responsables de departamento podrán acceder bien conectándose directamente al portal interno del registro, bien pulsando un
enlace incluido en el mensaje de notificación de entrada que hayan recibido en su correo electrónico o en el correo genérico del departamento. Solo podrán acceder a los registros de los que sea destinatarios el departamento.
2.6. Requisitos funcionales respecto a las notificaciones
IMBISA prevé utilizar el módulo de comunicaciones y notificaciones electrónicas (a partir de ahora, módulo de notificaciones) del sistema para realizar todas sus comunicaciones y notificaciones electrónicas.
General.
El módulo de notificaciones debe cumplir con los requisitos de la ley 39/2015, de 1 de octubre de 2015, sobre el “Procedimiento Administrativo Común de las Administraciones Públicas”, relativos a comunicaciones y notificaciones telemáticas, que apliquen a IMBISA, así como con el resto de la normativa vigente.
El módulo de notificaciones debe permitir, a cualquier persona física, jurídica, apoderados o representantes (a partir de ahora, interesados), la recepción de las comunicaciones y notificaciones telemáticas, que IMBISA deba comunicar formalmente, con las mismas garantías que los mecanismos de envío tradicional.
El módulo de notificaciones deberá garantizar el no repudio en origen y en destino a las notificaciones.
Plataforma del servicio.
Emisión de las comunicaciones y notificaciones.
El módulo de notificaciones debe permitir a IMBISA la emisión de comunicaciones y notificaciones electrónicas de forma programática, mediante mecanismos de integración aplicación-aplicación (servicio web), que permitan indicar al menos los siguientes datos:
- NIF, nombre y email de aviso del interesado.
- Asunto, procedimiento y referencia del expediente.
- En el caso de notificaciones, plazo de vencimiento.
- Documentos a notificar en formato PDF.
- Unidad administrativa de IMBISA emisora de la notificación.
El módulo de notificaciones debe almacenar las comunicaciones, notificaciones y acciones de los interesados en una base de datos que sea accesible por IMBISA.
El módulo de notificaciones debe informar al interesado, por correo electrónico, de la puesta a disposición de una comunicación o notificación, adjuntando un enlace a la URL donde se puede realizar el acceso a la misma y realizar la comparecencia en sede electrónica.
Acceso a las comunicaciones y notificaciones.
El acceso para la recepción de las notificaciones se deberá hacer mediante la comparecencia en la sede electrónica, entendiendo como comparecencia en sede electrónica, el acceso por el interesado o su representante, debidamente identificado, al contenido de la notificación.
El módulo de notificaciones debe requerir a los interesados el acceso a la comparecencia en sede electrónica mediante la autenticación a través de certificado digital.
Al realizar la comparecencia en sede electrónica, el módulo de notificaciones debe presentar al interesado un aviso del carácter de notificación del acceso, y debe permitir al interesado aceptar o rechazar la notificación. Ambas acciones deben ser firmadas digitalmente por el interesado y almacenadas por el módulo de notificaciones.
El módulo de notificaciones debe marcar de forma automática como vencidas las notificaciones que no hayan sido accedidas por el interesado en el plazo estipulado en la normativa vigente para el procedimiento de que se trate. Dicha marca debe almacenarse firmada digitalmente.
El módulo de notificaciones deberá acreditar, en formato PDF y firmado, la fecha y hora en la que la notificación se pone a disposición del interesado. Este justificante podrá ser descargado por el interesado para acreditar el momento de puesta a disposición de la notificación.
El módulo de notificaciones deberá acreditar, en formato PDF y firmado, la fecha y hora en la que se actúa sobre la notificación practicada, cuando el interesado accede a la notificación para su aceptación o rechazo, o en el caso del vencimiento de la notificación. Además, en el caso de representaciones, deberá identificar claramente quién ha realizado la comparecencia. Este justificante podrá ser descargado por el interesado para acreditar el momento de la actuación sobre la notificación.
El módulo de notificaciones debe permitir configurar, para cada procedimiento, si es necesaria la firma mediante certificado digital por parte de los interesados para aceptar o rechazar una notificación.
Histórico de las comunicaciones y notificaciones
El módulo de notificaciones debe permitir al interesado acceder al listado de comunicaciones y notificaciones que le han sido remitidas, incluyendo, entre otros, su asunto / procedimiento / referencia del expediente, cuáles se han leído, cuándo y si hubieran sido aceptadas, rechazadas o vencidas, facilitando filtros para realizar búsqueda sobre ellas.
El módulo de notificaciones debe permitir al interesado la comprobación del estado de una comunicación o notificación. Esta consulta incluirá, al menos, un texto descriptivo sobre el estado (pendiente, recibida, rechazada, vencida), la identificación del interesado, la fecha y hora de puesta a disposición, y la fecha y hora de aceptación o rechazo, si existiera.
El módulo de notificaciones debe permitir al interesado el acceso al contenido de los datos remitidos en la comunicación (en todos los casos) o notificación (únicamente si esta ha sido aceptada), así como a las acreditaciones en formato PDF de puesta a disposición, aceptación, rechazo o caducidad, según corresponda.
Representantes y representados de interesados.
El módulo de notificaciones debe permitir a las personas físicas indicar los representantes que puedan actuar en su nombre.
El módulo de notificaciones debe permitir a las personas jurídicas indicar las personas físicas autorizadas para actuar en representación suya.
La gestión de estas representaciones se realizará íntegramente en el módulo de notificaciones.
Seguimiento de las comunicaciones y notificaciones.
El módulo de notificaciones debe permitir a los empleados de IMBISA debidamente autorizados conocer el estado de las comunicaciones y notificaciones en su conjunto o individualmente, obtener informes sobre su uso y realizar aquellas acciones que, legalmente, permitan tener una gestión ágil y eficiente de las mismas.
El módulo de notificaciones debe proporcionar mecanismos de integración aplicación- aplicación para que sistemas externos debidamente autorizados (como pueden ser otras aplicaciones de IMBISA) puedan acceder al estado de las comunicaciones y notificaciones de forma programática (servicio web), así como a las acreditaciones generadas en formato PDF por el módulo en el momento de puesta a disposición, aceptación, rechazo o vencimiento de las notificaciones.
Gestión de roles y perfiles de acceso.
El módulo de notificaciones debe proporcionar mecanismos de seguridad que garanticen que los empleados de IMBISA únicamente tienen acceso a las notificaciones emitidas por su unidad administrativa, así como, a la obtención de informes filtrados por las notificaciones de su competencia.
El módulo de notificaciones deberá limitar los procedimientos sobre los que pueda notificar cada unidad administrativa.
El módulo de notificaciones debe proporcionar mecanismos de seguridad que permita, a los empleados de IMBISA que se determinen como administradores del módulo de notificaciones, el acceso a todas las comunicaciones y notificaciones.
3. Requisitos funcionales opcionales
En este apartado se describen los requisitos funcionales identificados que no son de cumplimiento obligatorio en el sistema, pero que son convenientes si la plataforma lo permite.
3.1. Requisitos funcionales opcionales generales de la plataforma
No se identifica ningún requisito funcional opcional.
3.2. Requisitos funcionales opcionales respecto a la interfaz de usuario
No se identifica ningún requisito funcional opcional.
3.3. Requisitos funcionales opcionales respecto al módulo externo
Suscripción a alertas
El sistema debería permitir que un operador económico se suscriba a anuncios de licitaciones. Estas suscripciones se podrían realizar indicando los criterios permitidos en los filtros generales del sistema.
Cumplimentación de cuestionarios / modelo de entrada de datos
El sistema debería permitir la cumplimentación, por parte de los operadores económicos, de los cuestionarios que hayan sido definidos.
3.4. Requisitos funcionales opcionales respecto al módulo interno
Envío de alertas
El sistema, al darse de alta una nueva licitación, debería remitir alertas a los operadores económicos que estén suscritos a la recepción de avisos de licitaciones del mismo tipo que la creada. Esta alerta consistirá en un correo electrónico de aviso, incluyendo un enlace al elemento de la licitación creado en el perfil del contratante. En ningún caso se practicará una notificación en este tipo de alertas.
Publicación en DOUE
El sistema debería permitir al gestor de contratación elegir, cuando publica la licitación, si desea mandar la licitación para su publicación en el DOUE, para lo cual deberá gestionar la comunicación electrónica al mismo.
Definición de cuestionarios / modelo de entrada de datos
El sistema debería permitir a los gestores de contratación definir cuestionarios como parte del contenido de un sobre.
Remisión selectiva de notificaciones
El sistema debería permitir al gestor de contratación realizar notificaciones a un grupo prefijado de operadores económicos según su tipología, tales como interesados, licitadores, seleccionados, etc.
3.5. Requisitos funcionales opcionales respecto a las notificaciones
No se identifica ningún requisito funcional opcional.
4. Interacción del sistema con los sistemas actuales de IMBISA
En esta sección se describe la interacción del sistema a desarrollar con aquellos sistemas actualmente operativos en IMBISA que se encuentran afectados por él.
Portales públicos de IMBISA
El sistema propuesto deberá ser accesible desde el perfil de contratante existente en la página web de IMBISA, proveyendo a este de las URL de acceso al módulo externo que sean necesarias, con los mecanismos que se articulen en el proceso de contratación de IMBISA.
5. Descripción del servicio
5.1. Requisitos de la implantación, adaptación y configuración inicial
Configuración inicial
La configuración inicial del sistema de licitación electrónica deberá incluir las siguientes tareas:
Puesta a disposición, a través de HTTPS, de un portal de acceso al subsistema externo y la parte externa del módulo de notificaciones, que incluirá el dominio xxxxxx.xx.
Puesta a disposición, a través de HTTPS, de un portal de acceso al módulo interno y la parte interna del módulo de notificaciones, que incluirá el dominio xxxxxx.xx.
Para la configuración de la funcionalidad HTTPS tanto en el subsistema interno como externo, IMBISA proporcionará certificados de Servidores para ambos subsistemas en el dominio xxxxxx.xx.
Adaptación de la plataforma, en todos sus subsistemas, a la imagen visual institucional de IMBISA según su ámbito (externo o interno).
Adaptación de los distintos módulos a los procesos definidos en IMBISA.
Parametrización del módulo interno para contemplar los distintos procedimientos, tipos o modalidades de contrato, cuantías y fases (al menos dos) de los procesos de contratación actuales y futuros recogidos en la normativa de contratación pública.
Similarmente, configuración de los parámetros de las licitaciones para adaptarse a los plazos y límites definidos en la normativa interna de IMBISA.
Definición xx xxxxxxxxxx de comunicaciones y notificaciones e incorporación a la plataforma.
Creación y configuración de los distintos perfiles de acceso a la plataforma. Gestión de usuarios. Creación de los perfiles en los sistemas de autenticación de IMBISA.
Carga inicial de datos
Se realizará una carga inicial de datos en la nueva aplicación, que comprenderá:
Carga inicial de las configuraciones más usuales de la Mesa de Contratación.
Carga inicial de permisos y usuarios.
Carga inicial de ámbitos (departamentos con capacidad de contratar).
Carga inicial de días festivos.
Acceso a la plataforma y autenticación
Los usuarios podrán autenticarse y acceder a la plataforma de las siguientes maneras:
Mediante usuario y contraseña, con las políticas de seguridad indicadas en el anejo 5.
Acceso con certificado digital o sistema de identificación equivalente.
Requisitos de seguridad
Los requisitos de seguridad aplicables se encuentran descritos en el documento de requisitos de seguridad.
6. Requisitos del servicio
Evaluación de nuevas versiones
Planificación del despliegue en el entorno de test de las nuevas versiones disponibles de la plataforma, y emisión de un informe describiendo tanto los beneficios de las nuevas funcionalidades para IMBISA como el potencial impacto a nivel de seguridad y protección de datos.
Planificación de la activación de la nueva versión en el entorno de producción.
Soporte y atención a incidencias
Gestión del servicio de soporte proporcionado por el proveedor de la plataforma, encargándose de la apertura y seguimiento de casos de soporte en caso de ser necesario.
Recepción y atención de incidencias de los usuarios de la plataforma.
Soporte a las incidencias informáticas de los operadores económicos.
Redirección de las dudas sobre las contrataciones al órgano responsable en IMBISA.
Entornos
El servicio deberá contemplar la existencia de entornos separados de producción y test, siendo este último el entorno idóneo donde poder realizar pruebas tempranas de las actualizaciones de versión.
Idealmente, se debería contar con tres entornos separados: producción, pre-producción y test, para adecuarse a los entornos existentes en SSI de IMBISA.
Carga periódica de datos
Se realizará una carga periódica, anual, de datos en la nueva aplicación, que comprenderá:
Carga de días festivos.
Requisitos de seguridad
Los requisitos de seguridad aplicables se encuentran descritos en el documento de requisitos de seguridad.
Anejo 5: Requisitos de seguridad
1. Introducción
Este documento describe los requisitos de seguridad a tener en cuenta en la contratación e implementación de una plataforma de licitación electrónica basada en una solución en la nube en modalidad Software as a Service (SaaS), así como las prescripciones técnicas aplicables a algunos de los controles de seguridad que se habrán de implementar.
2. Definiciones
Para facilitar la comprensión de los controles que se especifican a continuación, cuando se indique «el cliente» se hace referencia al «cliente del servicio en la nube» y en concreto a
«IMBISA», cuando se indique «clientes» se hace referencia a «los clientes del servicio en la nube, además de IMBISA» y cuando se indique «el proveedor» se hace referencia al
«proveedor del servicio en la nube».
3. Requisitos de seguridad
Este apartado describe los requisitos de seguridad de la información para la plataforma de licitación electrónica. La determinación de dichos requisitos se deriva de las siguientes acciones:
- La valoración de la criticidad realizada por IMBISA en términos de impacto para el negocio, financiero y reputacional en caso de la materialización de amenazas que pongan en riesgo la confidencialidad, integridad y disponibilidad del sistema.
- La identificación de las posibles amenazas a las que sería vulnerable una plataforma de licitación electrónica, especialmente teniendo en cuenta la ubicación de dicho servicio en una nube accesible desde Internet.
- El catálogo de controles de seguridad propuesto por el estándar ISO/IEC 27002:2013, así como las recomendaciones incluidas en los estándares ISO/IEC 27017:2015 e ISO/IEC 27018:2014, sobre controles de seguridad y buenas prácticas para la gestión de datos personales para servicios en la nube.
3.1. Políticas de seguridad de la información
SEG-1. Políticas para la seguridad de la información y funciones y responsabilidades compartidas dentro de un entorno nube.
El proveedor ha de tener definido un conjunto de políticas para la seguridad de la información, aprobado por la dirección, publicado y comunicado a los empleados así como a todas las partes externas relevantes. Así mismo, las responsabilidades de las funciones compartidas de la seguridad de la información en el uso del servicio en la nube deben ser asignadas a figuras identificadas, documentadas y comunicadas por el proveedor.
Las políticas de seguridad definidas por el proveedor han de incluir al menos los siguientes aspectos:
- Requisitos básicos de seguridad aplicables al diseño e implementación del servicio en la nube.
- Acceso a los activos del cliente por parte del personal del proveedor, incluyendo procedimientos de control de acceso de los administradores.
- Aislamiento de cada uno de los clientes, incluyendo detalles del sistema de virtualización.
- Aseguramiento de la continuidad del negocio y recuperación ante desastres, incluyendo información sobre la política de backup.
- Comunicación al cliente de la gestión de cambios.
- Comunicación al cliente de posibles incidentes y brechas de seguridad.
- Requisitos de seguridad aplicables a los datos de carácter personal.
El proveedor debe documentar y comunicar sus capacidades, funciones y responsabilidades de seguridad de la información para el uso de su servicio junto con los roles y responsabilidades que el cliente necesitaría implementar y administrar como parte de su uso.
SEG-2. Cumplimiento de las políticas y normas de seguridad.
El proveedor debe comprobar periódicamente el cumplimiento de las políticas de seguridad, las normas y otros requisitos de seguridad.
Se deben identificar y revisar los requisitos de seguridad definidos en las políticas y asegurar que se cumpla la normativa aplicable. Si se encuentra cualquier incumplimiento como resultado de la revisión se deberá:
- Determinar la causa del incumplimiento.
- Evaluar la necesidad de adoptar medidas para lograr el cumplimiento.
- Aplicar las medidas correctivas apropiadas.
- Revisar las acciones correctivas tomadas para verificar su eficacia y determinar las deficiencias o debilidades.
Los resultados del examen y las acciones correctivas llevadas a cabo por el proveedor deben ser registrados y estos registros mantenidos en el tiempo. Además, tanto la revisión de seguridad como las medidas correctivas deberán ser informadas a un revisor independiente para su valoración.
3.2. Gestión de activos
SEG-3. Devolución de activos y eliminación de los activos del cliente.
Todos los empleados y terceras partes deberán devolver y/o devolverse todos los activos de la organización en el momento de la finalización del empleo, contrato o acuerdo.
En el momento de la finalización del contrato el proveedor deberá devolver al cliente los activos de información que estén en su posesión:
- Se deberá devolver toda la información perteneciente al cliente: Información de usuarios dados de alta, junto a sus autorizaciones, información introducida en la plataforma, registros de auditoría, etc. Esta información se deberá entregar en un formato que facilite su transferencia a otro proveedor.
- Una vez realizada la entrega de los activos el proveedor deberá realizar una destrucción segura de la información propiedad del cliente.
- El proveedor debe proporcionar información sobre la devolución y eliminación de los activos del cliente al finalizar el acuerdo para su uso.
- La devolución y remoción de activos deben estar documentados en el acuerdo. Estos deben especificar los activos que deben devolverse y eliminarse.
3.3. Control de acceso
SEG-4. Gestión de altas y bajas de cuentas de usuario.
Se debe establecer un proceso formal de registro y desregistro de usuarios, en caso de que estos no se realicen automáticamente, como paso previo al alta del usuario y la posterior asignación de derechos de acceso. En el caso del desregistro se procederá a la eliminación de los derechos de acceso y posteriormente a la baja del usuario.
El proveedor debe proporcionar funcionalidades de creación y baja de cuentas de usuario de forma que:
- A cada usuario le sea asignado un identificador único, evitándose el uso de usuarios compartidos.
- Dicha gestión de usuarios ha de poder delegarse a administradores de usuarios internos del cliente, quienes habrán de poder crear cuentas de usuarios, revisar las existentes y borrar las que ya no sean necesarias.
SEG-5. Gestión de los derechos de acceso asignados a usuarios.
Se debe establecer un proceso formal de asignación y desasignación de derechos de acceso de usuario a las distintas funcionalidades ofrecidas por el servicio en la nube.
El proveedor debe proporcionar funcionalidades de asignación y desasignación de derechos de acceso basados en roles para todas las funcionalidades de la plataforma.
- Ha de ser posible la designación de las funcionalidades disponibles para cada uno de los roles de la plataforma y dicha designación se ha de poder delegar en administradores internos del cliente.
- La gestión de autorizaciones de las cuentas de usuarios a cada uno de los roles se ha de poder delegar en administradores internos del cliente.
- Se ha de poder obtener información de forma sencilla (por ejemplo mediante la generación de informes) sobre las autorizaciones que cada usuario tiene asignada para facilitar la revisión periódica.
SEG-6. Gestión de los derechos de acceso con privilegios especiales.
La asignación y uso de derechos de acceso con privilegios especiales ha de estar restringida y controlada.
Tanto el proveedor como el integrador de la solución del cliente deben garantizar que la asignación de los privilegios de acceso como operador o administrador de la plataforma se realiza siguiendo las siguientes pautas:
- Mediante un proceso de autorización formal que siga el principio de ¨necesidad de conocer¨ y durante el tiempo estrictamente necesario para la realización de las funciones de administración correspondientes.
- Los accesos con privilegios especiales han de quedar auditados.
- Cuando los administradores de la plataforma accedan utilizando privilegios especiales deberán autenticarse utilizando un mecanismo de autenticación de múltiples factores.
SEG-7. Gestión de la información confidencial de autenticación de usuarios.
La entrega de credenciales de acceso a los usuarios, en caso de que esta no se realice automáticamente, se ha de llevar a cabo mediante un proceso de gestión formal.
El proveedor debe garantizar que la entrega de credenciales a su usuario se realiza mediante un proceso formal en el que únicamente el usuario interesado, del que se ha verificado previamente su identidad, recibe las credenciales iniciales mediante un canal seguro, y que se ha de forzar la modificación de la contraseña inicial.
SEG-8. Proceso de inicio de sesión seguro.
El acceso a la plataforma se ha de realizar mediante un proceso de inicio de sesión seguro.
Para los accesos de usuarios externos al cliente, el acceso a la plataforma deberá estar basado en un doble factor de autenticación.
Para la integración con las aplicaciones internas del cliente, la autenticación de las aplicaciones en ambas direcciones se basará en un mecanismo de autenticación suficientemente robusto.
SEG-9. Gestión de contraseñas.
El sistema de gestión de contraseñas deberá ser interactivo y deberá asegurar la calidad de las contraseñas.
Los códigos de usuario y contraseñas que pudieran manejarse para la operación de la plataforma de licitación electrónica deberán ser individuales para mantener la auditoría del usuario que ha realizado una determinada acción.
La plataforma ha de ofrecer al usuario una opción para el cambio de contraseña y para su reinicio en caso de olvido.
Se ha de forzar al usuario el cambio periódico de contraseña. Se ha de forzar al usuario a elegir una contraseña de calidad, incluyendo un mínimo de 8 caracteres, incluyendo mayúsculas, minúsculas, números y caracteres especiales.
Se ha de mantener un histórico de las últimas contraseñas utilizadas para evitar su reutilización.
3.4. Criptografía
SEG-10. Política sobre el uso de controles criptográficos.
El proveedor ha de desarrollar e implementar una política sobre el uso de controles criptográficos para proteger la información.
Los controles criptográficos que se implementen han de asegurar que la confidencialidad e integridad de la información gestionada por la plataforma sea aplicable tanto a los datos en tránsito (es decir, intercambiados entre el cliente como de las empresas licitadoras y la nube, tanto en los accesos de usuarios personales como en los de las aplicaciones internas del cliente) como en reposo, (es decir, una vez almacenado en la base de datos y sistema de almacenamiento del proveedor).
3.5. Seguridad operacional
SEG-11. Seguridad Operacional del administrador.
Los procedimientos para las operaciones administrativas de un entorno de nube deben ser definidos, documentados y monitorizados.
El proveedor debe proporcionar documentación sobre las operaciones y procedimientos críticos al cliente que lo requiera.
SEG-12. Supervisión de servicios en la nube.
El cliente debe tener la capacidad de supervisar aspectos específicos de la operación de los servicios en la nube que utiliza.
El proveedor debe proporcionar capacidades que permitan al cliente supervisar aspectos específicos de la operación de los servicios en la nube.
Por ejemplo, para supervisar y detectar si el servicio en la nube se está utilizando como plataforma para atacar a otros o si se están filtrando datos sensibles desde el servicio en la nube.
Los controles de acceso apropiados deben asegurar el uso de las capacidades de monitorización. Las capacidades deben proporcionar acceso sólo a la información sobre las instancias del servicio en la nube del cliente.
El proveedor debe proporcionar documentación de las capacidades de supervisión del servicio al cliente.
La monitorización debe proporcionar datos consistentes con los registros de eventos descritos en la cláusula 12.4.1 ISO 27002:2013 y ayudar con términos de SLA.
SEG-13. Gestión de cambios.
Se han de controlar los cambios en la plataforma que pudieran afectar a la seguridad.
El proveedor deberá proporcionar al cliente la información sobre los cambios que potencialmente pudieran afectar al servicio. En concreto, se ha de proporcionar la siguiente información sobre los cambios:
- Categoría del cambio.
- Fecha y hora del cambio.
- Impacto.
- Funcionalidad afectada.
- Tiempo real de interrupción del servicio.
- Descripción técnica del cambio en el servicio en la nube o en los sistemas base en los que está basado y el procedimiento detallado del Plan de Marcha Atrás si fuera necesario.
- Notificación del inicio y fin del cambio.
SEG-14. Gestión de la capacidad.
Se ha de monitorizar el uso de los recursos, así como realizar estimaciones de las necesidades de incremento de la capacidad para asegurar que se cumplen los objetivos de rendimiento que han sido contratados.
El proveedor ha de poner a disposición del cliente la información que le permita comprobar que la capacidad del servicio (ej. espacio en disco, rendimiento, número de usuarios concurrentes, etc.) es adecuada a las necesidades del cliente, así como para anticipar un posible crecimiento en el número de usuarios o en las funcionalidades ofrecidas.
La oferta debe proporcionar información sobre los límites teóricos de proceso de la solución propuesta en cuanto a usuarios y accesos concurrentes así como proponer planes de escalabilidad de la arquitectura para diferentes tramos de crecimiento.
SEG-15. Separación de entornos de desarrollo, pruebas y producción.
Los entornos de desarrollo, pruebas y producción deberán estar separados para reducir los riesgos de accesos no autorizados o cambios en los entornos de producción.
La solución debe contemplar al menos los siguientes entornos de ejecución:
- Entorno de pruebas/desarrollo, para proporcionar un escenario de validación de configuraciones e integraciones con los diferentes servicios.
- Entorno de producción.
SEG-16. Controles contra el código malicioso.
Se han de implementar controles de detección, prevención y recuperación para proteger contra el código malicioso (malware).
El proveedor de la plataforma ha de implementar controles que permitan la detección de código malicioso (malware) y evite su ejecución.
SEG-17. Copias de seguridad.
Se han de realizar y probar periódicamente copias de seguridad.
Se habrá de realizar copia de seguridad de todos los componentes tecnológicos de la plataforma. Aquellos componentes de la solución tecnológica implementada que pudieran encontrarse alojados en el cliente habrán de poder ser integrados con los procedimientos y tecnología de backup ya existentes.
El proveedor debe garantizar que las copias de seguridad son funcionales.
Se deberá garantizar que las copias de ficheros con información de carácter personal, si existieran, no se conservarán por más tiempo que el periodo de retención permitido en virtud de la ley de protección de datos (artículo 4.5 de la Ley 15/1999).
SEG-18. Registro de eventos.
Se ha de almacenar y revisar de forma regular un registro de eventos de las actividades de los usuarios, errores y otros eventos de seguridad. Estos registros deberán mantenerse por un tiempo de 5 años.
La plataforma ha de almacenar eventos de los accesos satisfactorios y fallidos de los usuarios y las actividades realizadas por estos en la plataforma en el uso de las funcionalidades de negocio.
Así mismo, se deberán almacenar eventos de los accesos satisfactorios y fallidos de los usuarios privilegiados y sus acciones relacionadas con la gestión de usuarios (ej. altas y bajas de usuario) y de la asignación de los derechos de acceso.
Esta información ha de poder ser revisada de forma sencilla (por ejemplo, mediante la generación de informes) por parte de los administradores del cliente.
SEG-19. Protección de registro de eventos.
Los registros de eventos deben estar protegidos contra la manipulación y el acceso no autorizado.
Se debe proteger el acceso contra cambios no autorizados a la información del registro. Los archivos de registro no deben ser editados o eliminados, ya que si los datos pueden ser modificados o borrados, su existencia puede dar una falsa sensación de seguridad.
SEG-20. Registro de actividad del operador y administrador del sistema.
Las actividades de los operadores y administradores del proveedor se han de almacenar en un registro protegido y se han de revisar de forma regular. El proveedor ha de registrar las actividades realizadas por parte de los operadores y administradores del sistema en relación con la información asociada al sistema del cliente, y dicha información habrá de estar disponible ante una posible solicitud por parte del cliente.
SEG-21. Gestión de vulnerabilidades técnicas.
Se ha de obtener periódicamente información sobre las vulnerabilidades existentes en las tecnologías utilizadas para la provisión del servicio en la nube, evaluar la exposición de la plataforma a dichas vulnerabilidades, y tomar las medidas oportunas para atajar los posibles riesgos.
El proveedor ha de proporcionar al cliente la información sobre el procedimiento de gestión de vulnerabilidades e instalación de parches en la plataforma a contratar.
SEG-22. Notificación de puntos débiles en la seguridad.
Todo aquel que utiliza el sistema de información y los servicios deben observar y reportar cualquier deficiencia de seguridad detectada o sospechosa de serlo.
Todo aquel que utiliza el sistema debe informar de estas cuestiones al punto de contacto determinado tan pronto como sea posible a fin de evitar incidentes de seguridad. El mecanismo de información debe ser lo más fácil, accesible y disponible como sea posible.
SEG-23. Evaluación y decisión sobre los eventos de seguridad.
Los eventos de seguridad de la información deben ser evaluados y se debe decidir si han de ser clasificados como incidentes de seguridad. Se han de analizar los eventos de seguridad y, utilizando una escala de clasificación de incidentes de seguridad, decidir si el evento debe ser clasificado como un incidente y gestionarlo convenientemente.
3.6. Seguridad de las comunicaciones
SEG-24. Controles de red.
Se han de gestionar y controlar las redes para proteger la información en los sistemas y las aplicaciones.
El proveedor ha de implementar controles de seguridad de red efectivos para asegurar un nivel de protección adecuado a la plataforma cuando es accedida desde redes públicas.
También deberá asegurar las comunicaciones utilizadas por el proveedor para acceder al sistema.
SEG-25. Segregación de redes y segregación en entornos de virtualización.
Se debe establecer segregación en redes diferentes de los diversos grupos de sistemas de información, servicios ofrecidos y usuarios de la plataforma.
El entorno virtual del cliente que se ejecuta en un servicio en la nube debe estar protegido de otros clientes y personas no autorizadas.
El proveedor ha de asegurar la segregación en redes diferentes de los sistemas de información que componen la plataforma en la nube. Dicha segregación ha de realizarse en base a:
- Los distintos clientes de la plataforma.
- Los accesos por parte de los usuarios de la plataforma y los accesos de los operadores y administradores del proveedor.
El proveedor debe aplicar la segregación lógica apropiada de los datos de los clientes, las aplicaciones virtualizadas, los sistemas operativos, el almacenamiento y la red para:
- La separación de los recursos utilizados por los clientes en entornos con múltiples clientes.
- La separación de la administración interna del proveedor de los recursos utilizados por los clientes.
Cuando el servicio en la nube implica arrendamiento múltiple, el proveedor debe implementar controles de seguridad de la información para asegurar el aislamiento apropiado de los recursos utilizados por los diferentes clientes.
El proveedor debe considerar los riesgos asociados con la ejecución de software suministrado por otro proveedor asegurando que cumplen todos los requisitos especificados para el servicio.
3.7. Adquisición, desarrollo y mantenimiento de los sistemas de información
SEG-26. Principios de ingeniería segura de sistemas.
Los principios de ingeniería segura de sistemas se deben establecer, documentar, mantener y aplicar a cualquier sistema de información.
La arquitectura propuesta para la solución a implementar en el cliente deberá estar validada y soportada por el fabricante, para asegurar su mantenimiento futuro.
La plataforma deberá estar configurada de acuerdo con las buenas prácticas recomendadas por el fabricante.
3.8. Gestión de incidentes de seguridad
SEG-27. Responsabilidades y procedimientos.
Se han de establecer responsabilidades de gestión y procedimientos que aseguren una respuesta rápida, efectiva y ordenada de los incidentes relacionados con la seguridad.
Como parte de las especificaciones del servicio, el proveedor deberá definir los procedimientos y la asignación de responsabilidades entre el cliente y el proveedor para gestionar los incidentes de seguridad. Se ha de proporcionar documentación que incluya al menos la siguiente información:
- Ámbito de los incidentes de seguridad que el proveedor notificará al cliente.
- Tiempo objetivo de notificación de los incidentes de seguridad desde su detección.
- Procedimiento a seguir para la notificación de los incidentes de seguridad.
- Información de contacto en relación con la gestión de incidentes de seguridad.
- Compromiso de datos personales.
SEG-28. Los incidentes de seguridad deben ser atendidos de acuerdo a los procedimientos documentados.
Los incidentes de seguridad deben ser atendidos de acuerdo a los procedimientos documentados.
Los incidentes de seguridad deben recibir un tratamiento desde un punto definido de contacto y de personas relevantes de la organización o partes externas.
La respuesta debe contemplar:
- La recogida de pruebas tan pronto como sea posible.
- La realización de análisis forense de la información de seguridad, según sea necesario.
- La progresividad, según sea necesario.
- Garantizar que todas las actividades de respuesta involucradas se registran adecuadamente para su análisis posterior.
- Que se comunica la existencia del incidente de seguridad o cualquier detalle pertinente del mismo a otras personas internas y externas u organizaciones que tengan necesidad de conocerlas.
- Una vez que el incidente ha sido tratado con éxito, se cerrará y grabará formalmente.
El análisis post-incidente debe tener lugar, según sea necesario, para identificar el origen del incidente.
SEG-29. Notificación de eventos de seguridad.
Los eventos relacionados con la seguridad se han de reportar lo más rápido posible siguiendo los canales de gestión apropiados.
El proveedor deberá ofrecer mecanismos para que:
- El cliente pueda informar al proveedor sobre eventos de seguridad que ha detectado.
- El proveedor pueda informar al cliente sobre eventos de seguridad que ha detectado.
- El cliente pueda realizar un seguimiento de la situación de un evento de seguridad que ha sido informado.
3.9. Aspectos de seguridad en la gestión de la continuidad del negocio
SEG-30. Planificación de la continuidad de la seguridad.
La organización deberá determinar sus requisitos de seguridad y continuidad de la gestión de la seguridad en situaciones adversas, por ejemplo durante una crisis o un desastre.
El proveedor ha de asegurar que, en caso de una situación de crisis o un desastre, los requisitos de seguridad se mantienen como parte del plan de continuidad del negocio y del proceso de recuperación ante desastres.
3.10. Cumplimiento normativo
SEG-31. Identificación de la legislación aplicable.
Se ha de identificar, documentar y mantener actualizada la información relacionada con la legislación relevante que es de aplicación al servicio, así como la forma en la que la organización plantea el cumplimiento de los requisitos normativos.
El proveedor ha de informar al cliente sobre las jurisdicciones legales aplicables a la provisión del servicio.
El proveedor habrá de asegurar que la infraestructura técnica en la que almacene la información relativa al sistema del cliente se encuentra ubicada en territorio de la Unión Europea.
El proveedor habrá de asegurar el cumplimiento de los requisitos legales que afecten a la plataforma por su propia naturaleza funcional o por su ubicación geográfica, por ejemplo, en relación con la protección de la información de carácter personal almacenada en el sistema.
Si el cliente lo demanda, el proveedor habrá de proporcionar evidencias del cumplimiento de la legislación aplicable y requisitos contractuales.
SEG-32. Protección de datos y privacidad de la información personal.
Se ha de asegurar la protección de la información relacionada con datos personales que se almacene en el sistema.
El proveedor deberá asegurar el cumplimiento de la legislación en materia de protección de datos personales que sea de aplicación al cliente, como propietario de la información, teniendo la consideración de encargado del tratamiento.
En concreto, el proveedor deberá dar cumplimiento a los requisitos descritos en el apartado 3.11.
SEG-33. Revisión independiente de la seguridad.
El enfoque de la organización para gestionar la seguridad así como su implementación (ej. políticas, procesos y procedimientos de seguridad) se ha de revisar de forma independiente a intervalos planificados o cuando se produzcan cambios significativos.
El proveedor deberá proporcionar evidencias documentadas e independientes (por ejemplo, mediante un informe de auditoría independiente) de que los procedimientos y controles de seguridad de la plataforma están siendo aplicados convenientemente. En caso de detectarse algún incumplimiento, se deberán tomar las oportunas acciones correctivas, así como realizar un seguimiento de las recomendaciones abiertas, informando al cliente convenientemente.
Adicionalmente, el cliente se reservará el derecho de encargar una auditoría de seguridad del servicio contratado.
3.11. Requisitos adicionales para la protección de datos personales
SEG-34. Cumplimiento de los derechos ARCO.
Se debe posibilitar el ejercicio de los derechos ARCO. El proveedor deberá proporcionar la información necesaria para el ejercicio de los derechos de acceso, rectificación, cancelación y oposición, e implementar los procesos para que estos derechos puedan ser proporcionados en los plazos legales.
SEG-35. Finalidad de los datos.
Los datos no podrán utilizarse para otra finalidad diferente para la que fueron recogidos.
El proveedor deberá cumplir con los principios de limitación de la finalidad comprometiéndose a no utilizar los datos para una finalidad diferente a la señalada por el cliente.
SEG-36. Revelación de los datos.
Toda revelación de los datos deberá ser registrada incluyendo el destinatario y la fecha.
El proveedor deberá registrar la salida de información a terceras partes ya sea en operaciones habituales o por causas legales. Esta información deberá incluir los datos cedidos, la fecha y el destinatario de la información.
SEG-37. Subcontratación del tratamiento.
La subcontratación del tratamiento de datos personales tendrá que ser aprobada por parte de cliente.
La subcontratación del tratamiento tendrá que ser especificada en el contrato o, en el caso de llevarse a cabo posteriormente, deberá de ser comunicada y aprobada por el cliente con antelación.
SEG-38. Notificación del acceso no autorizado a datos personales.
Todo acceso no autorizado a datos personales deberá ser notificado al cliente comunicando si como resultado de este acceso se ha producido perdida, divulgación o alteración de los mismos.
El proveedor debe contemplar la notificación al cliente de accesos no autorizados a datos personales, su pérdida, divulgación o alteración, determinando el tiempo máximo para esta comunicación.
La notificación deberá incluir la descripción de los datos comprometidos.
SEG-39. Conservación de políticas de seguridad.
Disponibilidad de copia de las políticas de seguridad y de los procedimientos de operación.
El proveedor deberá guardar copia de sus políticas de seguridad y procedimientos de operación que hayan sido actualizadas al menos durante un periodo de cinco años.
SEG-40. Constancia de recuperación de datos. Control de las operaciones de recuperación de datos.
El proveedor deberá guardar un registro de las operaciones de recuperación que se lleven a cabo: indicando la persona que ejecutó el proceso, los datos restaurados y, en su caso, qué datos ha sido necesario grabar manualmente en el proceso.
4. Prescripciones técnicas
En este apartado se incluyen las especificaciones técnicas para algunos de los controles de seguridad que se habrán de implementar en la plataforma.
4.1. Seguridad de red
SEG-41. Cortafuegos de aplicación.
Se implementarán controles de seguridad a nivel de aplicación para asegurar que la información intercambiada con las distintas interfaces de la plataforma está convenientemente protegida. En concreto, se implementará:
- Un Web Application Firewall en las interfaces web de la plataforma.
- Proceso de validación de XML (XML Firewall) en las interfaces Web Services de la plataforma.
5. Conformidad con el Esquema Nacional de Seguridad
SEG-42. Conformidad con el Esquema Nacional de Seguridad.
De conformidad con la Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público y el Real Decreto 951/2015, de 23 de octubre, de modificación del Real Decreto 3/2010, de 8
de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica, el proveedor de la plataforma deberá presentar una Declaración de Conformidad con el Esquema Nacional de Seguridad, en base a los criterios y procedimientos previstos en la Guía CCN-STIC-809 «Declaración y Certificación de Conformidad con el ENS y Distintivos de Cumplimiento» y según el art. 34 y Anexo III del RD 3/2010.
Esta declaración se realizará al menos cada dos años y también en el caso de producirse modificaciones sustanciales en el sistema de información que pudieran repercutir en las medidas de seguridad requeridas.