Respuesta a incidentes de seguridad

Última actualización: 15 de octubre de 2026 · Lic. Nicolás Dubois (Dubois Ferreiros Nicolas, RUT 218615110016) · nicolas@licnicolasdubois.com

Este documento describe qué hace PymbuPay cuando algo sale mal con los datos que trata por cuenta de un comerciante. Complementa el acuerdo de tratamiento de datos, que compromete el aviso «sin demora indebida»; acá ese compromiso tiene plazos y pasos concretos.

Está escrito para poder cumplirse. PymbuPay es un servicio chico y este documento lo dice donde corresponde, en vez de prometer una capacidad que no existe. Un procedimiento que nadie puede seguir es peor que ninguno: crea la expectativa sin el respaldo.

1. Qué cuenta como incidente

Cualquier hecho que comprometa la confidencialidad, integridad o disponibilidad de los datos que tratamos por cuenta del comerciante:

Acceso no autorizado a la base de datos o a las credenciales de Plexo de un comercio.
Exposición de datos de un comercio a otro.
Pérdida o alteración no intencional de registros de pago.
Compromiso de una credencial de PymbuPay (llave maestra, tokens de administración, acceso al alojamiento).
Una vulnerabilidad explotable encontrada en la aplicación, aunque todavía no se haya explotado.

Qué NO es un incidente de seguridad

Una caída de Plexo, de Shopify o del proveedor de alojamiento. Es un problema de disponibilidad, no de datos, y se comunica por la página de estado.
Un cobro rechazado, un pedido descuadrado o un error de configuración de promociones.

La distinción importa: mezclarlas haría que el canal de incidentes se llene de cosas que no lo son, y el día que haya uno de verdad nadie lo mire.

2. Cómo nos enteramos

Vía	Qué detecta	¿Automática?
Monitoreo de disponibilidad	Que el servicio no responda o que su chequeo interno falle. Corre cada 60 segundos y avisa por correo	Sí
Registros de la aplicación	Errores y comportamiento anómalo, al investigar	No — se consultan, no vigilan solos
Aviso de un proveedor	Shopify, Plexo o el proveedor de alojamiento	No depende de nosotros
Reporte de una persona	Un comerciante, un comprador, un investigador	—

No tenemos detección automática de intrusiones, y decirlo acá es parte del punto. Un acceso indebido se descubriría por los registros, por un aviso de un proveedor o por un reporte, no por una alarma. ⚠️ Y los registros se borran a los 90 días —el plazo que promete la política de privacidad— así que un incidente descubierto después se investiga con menos material: es la consecuencia deliberada de no guardar datos más tiempo del necesario.

3. Qué hacemos, en orden

Contener. Cortar el acceso: rotar la credencial comprometida, retirar la registración afectada, o dejar la aplicación fuera de servicio si es la única forma de detener la exposición. Contener va antes que entender: un incidente que sigue corriendo mientras se investiga es más grande cada minuto.
Preservar la evidencia. Antes de arreglar nada, guardar los registros del período y el estado de la base. Un arreglo apurado borra lo que hacía falta para saber qué pasó.
Determinar el alcance: qué comercios, qué datos, en qué ventana, y si hubo extracción o solo acceso.
Avisar, según los plazos del punto 4.
Remediar y verificar el arreglo con una prueba que falle antes y pase después.
Escribir qué pasó y por qué fue posible, junto al código que lo permitió.

4. Cuándo y qué avisamos

Momento	Qué se comunica
Dentro de las 24 horas de tomar conocimiento	Que hubo un incidente, qué datos pueden estar afectados y qué contención se aplicó — aunque el alcance todavía no esté cerrado
Dentro de las 72 horas	El alcance determinado hasta ese momento, la causa si se conoce y las medidas correctivas
Después	Actualizaciones a medida que haya información nueva, y un cierre cuando el incidente se resuelva

El primer aviso no espera a tener el cuadro completo. El comerciante es el responsable del tratamiento y tiene sus propias obligaciones de notificación, con plazos que corren desde que él se entera: retenerle la información hasta tener certeza le consume el plazo a él.

El aviso va por correo, al comercio afectado, a la dirección de contacto de su cuenta de Shopify.

5. Qué le pedimos al comerciante

Reportar lo que vea, a nicolas@licnicolasdubois.com. Quien nota algo raro suele enterarse antes que nosotros.
No intentar reproducir una vulnerabilidad sobre datos reales.
Cumplir sus obligaciones de notificación —a sus compradores y a la autoridad de control— que como responsable del tratamiento le corresponden a él. Nosotros le damos la información que necesite para hacerlo.

6. Los límites, dichos

No hay guardia 24/7. El monitoreo es automático; la respuesta humana ocurre cuando alguien la ve. Los plazos del punto 4 se cuentan desde la toma de conocimiento y están fijados para ser cumplibles con esa realidad.
No hay auditorías ni certificaciones externas de seguridad.
Ningún sistema conectado a internet es invulnerable. Este documento describe cómo se responde; no garantiza que no vaya a pasar.

7. Contacto

nicolas@licnicolasdubois.com — el mismo canal para reportar un incidente, una vulnerabilidad o una duda sobre este documento.

Si encontraste una vulnerabilidad: contanos qué es y cómo reproducirla, y no la publiques hasta que esté corregida. Vamos a responderte.

Ver también la política de privacidad y el acuerdo de tratamiento de datos.