Checklist de seguridad antes de lanzar tu SaaS: 12 puntos

Estás a pocas semanas de lanzar tu app, SaaS, marketplace o plataforma. La presión por salir al aire es enorme. Marketing presionando. Inversionistas queriendo ver tracción. Y una pregunta que nadie del equipo sabe responder con tranquilidad: ¿es seguro?

Este texto es el checklist honesto. Los 12 puntos de abajo son lo mínimo que tiene que estar resuelto antes de que el primer cliente entre a tu sistema. Cada punto indica el nivel de riesgo si lo ignoras, en un lenguaje que cualquier dueño de empresa entiende.

Cómo usar este checklist

Marca cada punto: ✅ resuelto / ⚠️ en progreso / ❌ olvidado. Los puntos marcados con ❌ deben convertirse en tareas antes del lanzamiento. Los puntos con ⚠️ necesitan un plazo claro.

Si te quedan 4 o más puntos en ❌, considera posponer el lanzamiento 2–4 semanas. Un bug grave en producción cuesta mucho más (en dinero, tiempo y reputación) que un retraso planificado.

1. HTTPS funcionando en todas las direcciones

Qué es: tu sitio tiene que abrir con el candado en el navegador, en todos los subdominios. Sin eso, el navegador muestra el aviso de “sitio no seguro”: Google penaliza y el cliente desconfía.

Cómo verificarlo: abre el sitio, app.tudominio.com y api.tudominio.com. Cada uno debe tener el candado.

Riesgo si lo ignoras: 🔴 Alto. Hoy en día, sin HTTPS, los navegadores bloquean el acceso o lo marcan como inseguro de forma agresiva. Lanzar sin HTTPS = lanzar mal.

2. Contraseñas fuertes y autenticación multifactor (2FA) en el área administrativa

Qué es: cualquier panel de administración (admin, backoffice, panel del equipo) necesita 2FA obligatorio. La contraseña sola no basta.

Cómo verificarlo: intenta entrar al admin como cualquier empleado sin segundo factor. Si puedes, eres vulnerable.

Riesgo si lo ignoras: 🔴 Alto. Todas las semanas se filtran contraseñas en algún sitio. Los empleados reutilizan la misma contraseña en varios lugares (siempre). Sin 2FA, una filtración en cualquier parte se convierte en acceso a tu sistema.

3. La base de datos no puede estar accesible desde internet

Qué es: tu base de datos (PostgreSQL, MySQL, MongoDB) tiene que estar aislada: solo tu aplicación habla con ella, no cualquiera desde internet.

Cómo verificarlo: pregúntale a tu desarrollador: ¿nuestra base de datos está en una VPC privada (red privada)? Si duda, alerta.

Riesgo si lo ignoras: 🔴 Crítico. Base de datos accesible directamente desde internet = un atacante la encuentra con un escáner en minutos, prueba contraseñas comunes y se lleva todos tus datos. Las filtraciones gigantes empiezan exactamente así.

4. Las claves de API y las contraseñas NO pueden estar en el código (GitHub)

Qué es: las claves de Stripe, AWS, OpenAI, de la base de datos: todo eso tiene que estar en variables de entorno, nunca en el código que va a Git.

Cómo verificarlo: pídele al desarrollador que corra una herramienta como git-secrets o truffleHog en el repositorio. Te da la lista de todo lo que está expuesto.

Riesgo si lo ignoras: 🔴 Crítico. Los atacantes monitorean GitHub público en tiempo real buscando claves filtradas. Tiempo promedio entre el commit y la explotación: unos pocos minutos. En una empresa SaaS pequeña, basta una clave de AWS filtrada para recibir una factura de US$ 100.000 por minería de criptomonedas.

5. Backup automatizado, probado y en un lugar separado

Qué es: tener el backup solo en la misma nube donde está la aplicación no cuenta: si el atacante tumba la nube, tumba ambos. El backup tiene que estar en un proveedor separado, con la restauración ya probada.

Cómo verificarlo: pregúntale al dev: ¿cuándo fue la última vez que probaron restaurar desde un backup? Si la respuesta es “nunca”, tienen una copia, pero no un backup confiable.

Riesgo si lo ignoras: 🔴 Alto. En un ataque de ransomware, un backup no probado equivale a no tener backup. Cerca de 1 de cada 3 organizaciones que pagan el rescate no recuperan todos sus datos (Sophos, Veeam): pagar no es la solución.

6. Permisos correctos: el cliente A NO puede ver los datos del cliente B

Qué es: en cualquier plataforma multicliente (SaaS, marketplace, app), el sistema tiene que garantizar que cada usuario acceda solo a lo que es suyo. Parece obvio, pero es la falla número 1 en APIs.

Cómo verificarlo: haz esta prueba: crea 2 cuentas con emails distintos, en planes distintos. Desde la cuenta A, intenta cambiar la URL para ver los datos de la cuenta B. Si lo logras, eres vulnerable.

Riesgo si lo ignoras: 🔴 Crítico. Tiene nombre técnico (BOLA / IDOR), ocupa el primer lugar de la lista de fallas más comunes en APIs en 2026 y casi nadie la detecta antes de que un cliente la denuncie.

7. Contraseñas de los usuarios guardadas con hash + salt (no en texto plano)

Qué es: cuando tu cliente crea una cuenta con contraseña, no puedes guardar “su” contraseña. Guardas una versión irreconocible (hash). Estándar moderno: bcrypt, argon2 o scrypt.

Cómo verificarlo: pídele al dev que te muestre cómo se ven las contraseñas en la base de datos. Si ves “contraseña123”, está mal. Si ves una secuencia larga que empieza con $2b$ o $argon2id$, está bien.

Riesgo si lo ignoras: 🔴 Catastrófico. Si algún día se filtra la base de datos y las contraseñas están en texto plano, acabas de entregarle al atacante la contraseña que tu cliente usa en varios sitios. El daño se vuelve global, no solo de tu sistema.

8. Logs (registros) de quién accedió a qué, con retención mínima de 90 días

Qué es: tu sistema tiene que registrar quién inició sesión, quién cambió qué y quién borró qué. Esos logs ayudan a entender si algo anda mal y son indispensables para investigar después de un incidente.

Cómo verificarlo: “¿cuál es nuestra retención de logs de autenticación?” Si la respuesta es “no tenemos” o “7 días”, alerta.

Riesgo si lo ignoras: 🟡 Medio. Sin logs, ante un incidente quedas a ciegas: no puedes responder “¿quién hizo esto?”, y la autoridad de protección de datos puede considerarlo negligencia (en Brasil, la ANPD, la Autoridad Nacional de Protección de Datos).

9. Plan de respuesta a incidentes por escrito (aunque sea simple)

Qué es: un documento de 2 a 5 páginas que diga: “cuando algo sale mal, fulano hace X, mengano hace Y, perengano avisa a Z”. No tiene que ser complejo. Tiene que existir.

Cómo verificarlo: pregunta: “¿tenemos un plan de incidentes?” Si recibes silencio, hay que escribir uno.

Riesgo si lo ignoras: 🟡 Alto en el momento del incidente. En plena emergencia, nadie razona bien. Plan escrito de antemano = decisiones correctas tomadas en frío.

10. Límites de intentos (rate limit) en puntos sensibles

Qué es: un formulario de login no puede aceptar 1.000 intentos por minuto. El registro no puede permitir la creación de 500 cuentas en 1 minuto. Si no, los atacantes abusan hasta descubrir una contraseña real o crear cuentas falsas en masa.

Cómo verificarlo: intenta ingresar mal la contraseña 20 veces seguidas en tu propio login. Si el sistema nunca te bloquea, no tienes rate limit.

Riesgo si lo ignoras: 🟡 Alto. Los atacantes usan “listas” de contraseñas comunes filtradas en otros sitios. Si no bloqueas, las prueban todas en horas.

11. Política de privacidad y términos publicados (LGPD)

Qué es: si operas en Brasil, antes de recopilar cualquier dato personal de tus clientes, la LGPD (la ley brasileña de protección de datos) exige que publiques una política de privacidad clara y los términos de uso, y que designes a un encargado de datos (DPO).

Cómo verificarlo: intenta abrir tusitio.com/privacidad. Si da 404, falta. Si la política está desactualizada (cita CCPA o GDPR, pero no la LGPD), está mal.

Riesgo si lo ignoras: 🟡 Alto. La ANPD puede multar incluso sin incidente, solo por falta de transparencia. Y los clientes enterprise se niegan a firmar con un proveedor que no tiene una política pública.

12. Pentest formal antes del lanzamiento (tercero independiente)

Qué es: antes de que entre el primer cliente real, contratar a una empresa especializada en seguridad ofensiva para que ataque la plataforma como un atacante real. No es el equipo de QA. No es el desarrollador revisando su propio código. Es un tercero con mirada adversarial.

Cómo verificarlo: ¿tienes un informe de pentest formal reciente, de los últimos 60 días, con el alcance claramente definido y PoC reproducible de las fallas?

Riesgo si lo ignoras: 🔴 Crítico. Los 11 puntos anteriores cubren lo “básico”. Un pentest formal cubre las fallas específicas de tu sistema: fallas de lógica de negocio, cadenas de explotación, supuestos equivocados de tus desarrolladores. Esas son las que terminan en las noticias, no las 11 anteriores.

Resumen ejecutivo: tabla de riesgo por punto

Cuánto cuesta hacer todo esto bien

Estimación realista para una empresa que lanza un MVP o un SaaS pequeño (valores de referencia del mercado brasileño):

• Puntos 1 a 11 (implementación técnica interna): 4 a 6 semanas de trabajo del equipo
• Punto 12 (pentest externo): R$ 3.000 a R$ 6.000; puede hacerse en paralelo con los puntos internos

Total típico: R$ 5.000 a R$ 15.000 + tiempo del equipo.

Compáralo con el costo promedio de un incidente en un SaaS recién lanzado: R$ 100.000 a R$ 800.000 (multas, demandas, churn, rehacer la arquitectura, pérdida de credibilidad para levantar la siguiente ronda).

Qué hacer ahora

Si estás a 4–8 semanas del lanzamiento y todavía tienes puntos en ❌, la mejor decisión es:

1. Blindar los puntos 7 y 4 de inmediato (catastróficos)
2. Resolver los puntos 1, 2, 3 y 6 en los próximos 14 días
3. Contratar el pentest externo en paralelo: tarda 2–4 semanas en completarse
4. El resto (puntos 5, 8, 9, 10 y 11) en las semanas siguientes

El pentest previo al lanzamiento de No Vuln para un SaaS pequeño (paquete Sprint, 25 h) cuesta de US$ 3.750 a US$ 6.250, tarda de 2 a 3 semanas y cubre exactamente los puntos técnicos de la lista de arriba + las fallas específicas que no puedes ver desde adentro.

Agenda una llamada y en 30 minutos evaluamos dónde está tu plataforma y qué falta resolver antes del lanzamiento.