Contribuyentes de IRE GENERAL: Deberán cumplir con el siguiente parámetro:
Donde dice: a.1 Ratio de Liquidez: activo corriente / pasivo corriente
Deberá ser igual o mayor que 1, en promedio, en los 3 (tres) últimos años (2022, 2023 y 2024).
a.2. Endeudamiento: pasivo total / activo total
No deberá ser mayor a 0,80 en promedio, en los 3 (tres) últimos años (2022, 2023 y 2024).
Solicitamos:
Son criterios que no pueden ser visto de manera aislada, ya que es importante considerar la identificación de los estándares de Endeudamiento del sector en el que se desempeña, así como también las inversiones para desarrollar de nuestro sector. Estos puntos puede ser parámetro importante para determinados tipos de procesos licitatorios que requieren fuertes cantidades de inversión para el inicio de obras. Ante lo mencionado, solicitamos la consideración de modificar el “Ratio de Liquidez mayor o igual a 0,90" y el "Nivel de Endeudamiento No deberá ser mayor a 0,91".
Si bien entendemos que los números de ratios financieros, son estándares establecidos por la DNCP, y en varias consultas realizadas a la DNCP nos mencionan que son solo niveles "sugeridos" por la misma y por ende cambiarlos queda a cargo de la convocante.
A nuestro criterio, realizar esta modificación dará la oportunidad de participar en esta Licitación a más oferentes, con beneficio directo para la Entidad ya que garantizará la posibilidad de obtener los mejores precios y calidad de servicio.
Contribuyentes de IRE GENERAL: Deberán cumplir con el siguiente parámetro:
Donde dice: a.1 Ratio de Liquidez: activo corriente / pasivo corriente
Deberá ser igual o mayor que 1, en promedio, en los 3 (tres) últimos años (2022, 2023 y 2024).
a.2. Endeudamiento: pasivo total / activo total
No deberá ser mayor a 0,80 en promedio, en los 3 (tres) últimos años (2022, 2023 y 2024).
Solicitamos:
Son criterios que no pueden ser visto de manera aislada, ya que es importante considerar la identificación de los estándares de Endeudamiento del sector en el que se desempeña, así como también las inversiones para desarrollar de nuestro sector. Estos puntos puede ser parámetro importante para determinados tipos de procesos licitatorios que requieren fuertes cantidades de inversión para el inicio de obras. Ante lo mencionado, solicitamos la consideración de modificar el “Ratio de Liquidez mayor o igual a 0,90" y el "Nivel de Endeudamiento No deberá ser mayor a 0,91".
Si bien entendemos que los números de ratios financieros, son estándares establecidos por la DNCP, y en varias consultas realizadas a la DNCP nos mencionan que son solo niveles "sugeridos" por la misma y por ende cambiarlos queda a cargo de la convocante.
A nuestro criterio, realizar esta modificación dará la oportunidad de participar en esta Licitación a más oferentes, con beneficio directo para la Entidad ya que garantizará la posibilidad de obtener los mejores precios y calidad de servicio.
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remítase al Pliego de Bases y Condiciones.
2
1) Datos sensibles / mensajes de error
Solicitamos a la convocante considerar modificar el requerimiento “Debe incluir una protección que enmascare o bloquee información confidencial proveniente de la aplicación incluyendo mensajes de errores del servidor y número de tarjetas de crédito.” porque al listar “número de tarjetas de crédito” se introduce una categoría específica de datos que puede restringir soluciones equivalentes y mezclar requisitos de DLP con controles de WAAP. Proponemos mantener la exigencia de enmascaramiento/bloqueo de mensajes de error del servidor, sin enumerar tipos de datos particulares, a fin de preservar la neutralidad tecnológica.
Solicitamos a la convocante considerar modificar el requerimiento “Debe incluir una protección que enmascare o bloquee información confidencial proveniente de la aplicación incluyendo mensajes de errores del servidor y número de tarjetas de crédito.” porque al listar “número de tarjetas de crédito” se introduce una categoría específica de datos que puede restringir soluciones equivalentes y mezclar requisitos de DLP con controles de WAAP. Proponemos mantener la exigencia de enmascaramiento/bloqueo de mensajes de error del servidor, sin enumerar tipos de datos particulares, a fin de preservar la neutralidad tecnológica.
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remítase a lo establecido en Adenda Nº:1.
3
2) GraphQL – “importar SDL Schemas”
Solicitamos a la convocante considerar modificar el requerimiento "La solución debe poseer la capacidad de importar SDL Schemas, para brindar protección para APIs que empleen GRAPHQL." porque exigir importación de esquemas obliga a un enfoque técnico específico y excluye mecanismos de protección equivalentes. Sugerimos admitir alternativas funcionales de protección de GraphQL (p. ej., validaciones de consulta por profundidad, tamaño, etc.) sin condicionar la solución a la importación de SDL.
Solicitamos a la convocante considerar modificar el requerimiento "La solución debe poseer la capacidad de importar SDL Schemas, para brindar protección para APIs que empleen GRAPHQL." porque exigir importación de esquemas obliga a un enfoque técnico específico y excluye mecanismos de protección equivalentes. Sugerimos admitir alternativas funcionales de protección de GraphQL (p. ej., validaciones de consulta por profundidad, tamaño, etc.) sin condicionar la solución a la importación de SDL.
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remitirse a lo establecido en el Pliego de Bases y Condiciones publicado.
4
3) Schema Enforcement (formatos)
Solicitamos a la convocante considerar modificar el requerimiento "La solución debe realizar Schema Enforcement en XML y JSON validando el método, endpoint, query parameters, header parameters, cookie parameters y body parameters." porque limitarlo a XML y JSON descarta implementaciones modernas que emplean otros formatos. Pedimos flexibilizar el requisito para mantener JSON y admitir al menos uno entre XML o YAML, preservando la validación de método, endpoint y parámetros.
Solicitamos a la convocante considerar modificar el requerimiento "La solución debe realizar Schema Enforcement en XML y JSON validando el método, endpoint, query parameters, header parameters, cookie parameters y body parameters." porque limitarlo a XML y JSON descarta implementaciones modernas que emplean otros formatos. Pedimos flexibilizar el requisito para mantener JSON y admitir al menos uno entre XML o YAML, preservando la validación de método, endpoint y parámetros.
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remítase a lo establecido en Adenda Nº:1.
5
4) Portal de gestión – métricas mostradas
Solicitamos a la convocante considerar modificar el requerimiento **"El portal debe mostrar como mínimo la siguiente información relacionada con el plan adquirido:
Número de aplicaciones adquiridas / número de aplicaciones aprovisionadas
Ancho de banda adquirido / ancho de banda promedio / ancho de banda pico
Periodo de Subscripción.
Servicios adicionales contratados."**
porque centrarse en “plan” y “ancho de banda” puede no reflejar métricas operativas clave de todos los fabricantes. Solicitamos que el portal reporte indicadores del servicio efectivamente prestado (por ejemplo, aplicaciones/subdominios protegidos, volumen de tráfico inspeccionado y solicitudes procesadas, periodo de suscripción y funcionalidades activas), manteniendo trazabilidad y transparencia.
Solicitamos a la convocante considerar modificar el requerimiento **"El portal debe mostrar como mínimo la siguiente información relacionada con el plan adquirido:
Número de aplicaciones adquiridas / número de aplicaciones aprovisionadas
Ancho de banda adquirido / ancho de banda promedio / ancho de banda pico
Periodo de Subscripción.
Servicios adicionales contratados."**
porque centrarse en “plan” y “ancho de banda” puede no reflejar métricas operativas clave de todos los fabricantes. Solicitamos que el portal reporte indicadores del servicio efectivamente prestado (por ejemplo, aplicaciones/subdominios protegidos, volumen de tráfico inspeccionado y solicitudes procesadas, periodo de suscripción y funcionalidades activas), manteniendo trazabilidad y transparencia.
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remitirse a lo establecido en el Pliego de Bases y Condiciones publicado.
6
5) Notificaciones ante falla de servidores de origen
Solicitamos a la convocante considerar modificar el requerimiento “El servicio deberá permitir crear notificaciones que puedan ser enviadas por correo o SMS en caso de falla de alguno de los Servidores de origen.” porque exigir SMS como canal obligatorio limita integraciones operativas modernas y puede excluir soluciones equivalentes. Proponemos que se admitan canales configurables (p. ej., correo electrónico y webhooks HTTP, entre otros), manteniendo la capacidad de alertamiento sin imponer un medio específico.
09-09-2025
17-09-2025
5) Notificaciones ante falla de servidores de origen
Solicitamos a la convocante considerar modificar el requerimiento “El servicio deberá permitir crear notificaciones que puedan ser enviadas por correo o SMS en caso de falla de alguno de los Servidores de origen.” porque exigir SMS como canal obligatorio limita integraciones operativas modernas y puede excluir soluciones equivalentes. Proponemos que se admitan canales configurables (p. ej., correo electrónico y webhooks HTTP, entre otros), manteniendo la capacidad de alertamiento sin imponer un medio específico.
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remitirse a lo establecido en el Pliego de Bases y Condiciones publicado.
7
6) Servicio administrado por el fabricante (7x24x365)
"Solicitamos a la convocante considerar modificar el requerimiento “La solución debe ser un servicio de seguridad administrado por el fabricante con disponibilidad 7x24x365” porque condiciona el modelo de implementación y no contempla la experiencia del adjudicatario en implementaciones similares. Proponemos que:
La implementación sea responsabilidad del proveedor adjudicado, en coordinación con el cliente, respaldada por experiencia comprobable (referencias o certificaciones de implementaciones exitosas previas de alcance y complejidad similares).
La administración y operación 7x24x365 puedan ser realizadas por el proveedor y/o por el cliente, según el SLA definido en el contrato."
09-09-2025
17-09-2025
6) Servicio administrado por el fabricante (7x24x365)
"Solicitamos a la convocante considerar modificar el requerimiento “La solución debe ser un servicio de seguridad administrado por el fabricante con disponibilidad 7x24x365” porque condiciona el modelo de implementación y no contempla la experiencia del adjudicatario en implementaciones similares. Proponemos que:
La implementación sea responsabilidad del proveedor adjudicado, en coordinación con el cliente, respaldada por experiencia comprobable (referencias o certificaciones de implementaciones exitosas previas de alcance y complejidad similares).
La administración y operación 7x24x365 puedan ser realizadas por el proveedor y/o por el cliente, según el SLA definido en el contrato."
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remitirse a lo establecido en el Pliego de Bases y Condiciones publicado.
8
7) Implementación y materiales del fabricante
Solicitamos a la convocante considerar modificar el requerimiento "El servicio administrado debe proporcionar asistencia durante la fase de implementación de las aplicaciones por parte del fabricante.
El proveedor deberá dar acceso web y/o entregar los manuales de uso u otros materiales requeridos para la utilización del software adquirido."
porque asigna la implementación al fabricante y puede limitar la competencia. Solicitamos aclarar que la implementación será responsabilidad del proveedor adjudicado, en coordinación con el cliente, incluyendo transferencia de conocimiento y provisión de documentación/acceso web necesarios.
Solicitamos a la convocante considerar modificar el requerimiento "El servicio administrado debe proporcionar asistencia durante la fase de implementación de las aplicaciones por parte del fabricante.
El proveedor deberá dar acceso web y/o entregar los manuales de uso u otros materiales requeridos para la utilización del software adquirido."
porque asigna la implementación al fabricante y puede limitar la competencia. Solicitamos aclarar que la implementación será responsabilidad del proveedor adjudicado, en coordinación con el cliente, incluyendo transferencia de conocimiento y provisión de documentación/acceso web necesarios.
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remitirse a lo establecido en el Pliego de Bases y Condiciones publicado. Se aclara que la implementación será responsabilidad del proveedor adjudicado con asistencia del fabricante, en coordinación con el cliente, incluyendo transferencia de conocimiento y provisión de documentación/acceso web necesarios.
9
8) Estándares y certificaciones
Solicitamos a la convocante considerar modificar el requerimiento **"El servicio debe contar, como mínimo, con los siguientes estándares de seguridad y calidad:
ISO/IEC 27001:2013 (Information Security Management Systems).
ISO/IEC 27032:2012 (Security Techniques -- Guidelines for Cybersecurity)
ISO 27017:2015 (Information Security for Cloud Services)
ISO 27018:2014 (Information Security Protection of Personally identifiable information (PII) in public clouds)"**
porque incluye versiones desactualizadas y omite marcos de privacidad/controles relevantes. Solicitamos actualizar a las revisiones vigentes y admitir certificaciones complementarias de privacidad y controles de servicio (p. ej., ISO/IEC 27701, revisiones 2019/2022 donde corresponda, y SOC 2 Type II), manteniendo equivalencias verificables.
Solicitamos a la convocante considerar modificar el requerimiento **"El servicio debe contar, como mínimo, con los siguientes estándares de seguridad y calidad:
ISO/IEC 27032:2012 (Security Techniques -- Guidelines for Cybersecurity)
ISO 27017:2015 (Information Security for Cloud Services)
ISO 27018:2014 (Information Security Protection of Personally identifiable information (PII) in public clouds)"**
porque incluye versiones desactualizadas y omite marcos de privacidad/controles relevantes. Solicitamos actualizar a las revisiones vigentes y admitir certificaciones complementarias de privacidad y controles de servicio (p. ej., ISO/IEC 27701, revisiones 2019/2022 donde corresponda, y SOC 2 Type II), manteniendo equivalencias verificables.
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remítase a lo establecido en Adenda Nº:1.
10
9) Modelo de integración “basado en API, sin cambios de DNS o BGP”
Solicitamos a la convocante considerar modificar el requerimiento:
**"La solución debe soportar un modelo de integración basado en API que no requiera cambios de DNS o BGP para proteger las aplicaciones y que cuente con las siguientes características:
En la arquitectura basada en API no se requiere compartir el certificado digital.
En la arquitectura basada en API los requerimientos van directamente a la aplicación."**
Dado que se enfoca únicamente en el patrón de integración y no incorpora atributos críticos de una solución WAAP en la nube, tales como disponibilidad del servicio, presencia regional (PoPs) y mecanismos de continuidad operativa ante la caída de un punto de presencia.
09-09-2025
17-09-2025
9) Modelo de integración “basado en API, sin cambios de DNS o BGP”
Solicitamos a la convocante considerar modificar el requerimiento:
**"La solución debe soportar un modelo de integración basado en API que no requiera cambios de DNS o BGP para proteger las aplicaciones y que cuente con las siguientes características:
En la arquitectura basada en API no se requiere compartir el certificado digital.
En la arquitectura basada en API los requerimientos van directamente a la aplicación."**
Dado que se enfoca únicamente en el patrón de integración y no incorpora atributos críticos de una solución WAAP en la nube, tales como disponibilidad del servicio, presencia regional (PoPs) y mecanismos de continuidad operativa ante la caída de un punto de presencia.
Sírvanse considerar para la elaboración de sus ofertas lo siguiente: Remitirse a lo establecido en el Pliego de Bases y Condiciones publicado. Se mantiene el requisito de integración basada en API sin cambios de DNS/BGP, por ser un modelo seguro y eficiente.