La SBS le dio a la banca peruana una base legal para usar la nube: migrar bien depende de otra cosa

Antes del Reglamento de Ciberseguridad y Gestión de Seguridad de la Información de la Superintendencia de Banca, Seguros y AFP (SBS), las empresas del sistema financiero peruano que querían usar cómputo en la nube para procesar datos no tenían una base regulatoria clara para hacerlo. No es que estuviera prohibido — es que no había un marco que definiera bajo qué condiciones era aceptable. Ese vacío es el que el reglamento vino a cerrar.

El efecto práctico es que hoy una entidad financiera en Perú tiene el camino habilitado para migrar cargas de trabajo a la nube. Pero el reglamento no se limita a habilitar: pone condiciones concretas sobre cómo tiene que hacerse esa migración, y ahí es donde la mayoría de los proyectos se juegan si van a cumplir de verdad o solo en el papel.

Qué exige el reglamento, específicamente

El marco de la SBS establece que, antes de contratar un proveedor externo de cómputo en la nube, la entidad tiene que identificarlo y evaluarlo. No alcanza con elegir un proveedor grande y asumir que su reputación reemplaza la evaluación. La norma pide un proceso explícito de identificación y evaluación previo a la contratación.

Después de contratado, la exigencia no termina. El reglamento requiere que la entidad monitoree en el proveedor las mismas buenas prácticas de protección de activos de información que aplica internamente. Es decir, la responsabilidad de seguridad de la información no se transfiere al tercerizar — se extiende, y la entidad tiene que poder demostrar que ese monitoreo ocurre de forma continua, no una sola vez al firmar el contrato.

Como evidencia de ese proceso, se exige un informe de proveedor que demuestre cumplimiento de los lineamientos de seguridad de la información. Y el objetivo declarado detrás de todo esto es concreto: prevenir brechas de seguridad evaluando la vulnerabilidad del proveedor de antemano, en lugar de descubrirla después de un incidente.

Dónde se traba un proyecto de migración bajo este marco

La parte fácil de este reglamento es la lectura legal: confirma que cómputo en la nube es una opción viable para el sistema financiero peruano. La parte difícil es operativa. Producir un informe de proveedor sólido, sostener un proceso de evaluación de vulnerabilidad que no sea un formulario una vez al año, y mantener visibilidad real sobre las prácticas de seguridad de un proveedor que opera fuera del perímetro directo de la entidad son capacidades que hay que construir — no vienen incluidas por el solo hecho de migrar a un proveedor cloud reconocido.

El error más frecuente que vemos en proyectos de este tipo en la región es tratar la evaluación de proveedor como un paso de compliance que se resuelve antes de la migración y no se vuelve a tocar. El reglamento de la SBS es explícito en que el monitoreo es continuo. Eso tiene una consecuencia de arquitectura directa: hay que diseñar desde el inicio cómo se va a producir esa evidencia de forma recurrente — qué se audita, con qué frecuencia, quién en el equipo interno tiene la capacidad técnica de interpretar lo que el proveedor reporta.

Como en otros reguladores de la región, la norma le da a la entidad la base legal para avanzar, pero deja en manos de la entidad la responsabilidad de demostrar, de forma sostenida, que la migración se hizo con el nivel de rigor que la norma exige. Esa segunda parte es la que decide si el proyecto cumple en la práctica o solo en la carpeta de compliance.

Si tu organización está evaluando cómo estructurar una migración a cómputo en la nube bajo el marco de la SBS, en Renaiss ofrecemos consultoría cloud para entidades financieras de la región con foco en arquitectura y evaluación continua de proveedores. Escribimos también sobre este mismo problema desde la regulación argentina en Comunicación A 8398 y arquitectura cloud fintech.

‍