SBS Resolution No. 504-2021: what it means for your cybersecurity program

SBS Resolution No. 504-2021 approved Peru’s Regulation for Information Security and Cybersecurity Management, issued by the Superintendency of Banking, Insurance and Private Pension Funds (SBS). It took effect on July 1, 2021 and replaced Circular G-140-2009, which for more than a decade had been the information security reference for Peru’s financial system.

The underlying shift is clear: the regulation moves away from “controls in place” and requires a management system that periodically shows those controls are effective against real threats. For banks, finance companies, municipal and rural savings banks, insurers, pension fund managers and e-money issuers, that has concrete consequences for budget, governance and operations.

Who it applies to

The regulation distinguishes three regimes (Article 4):

Regime	Entities	What it involves
General	Banks, finance companies, municipal and rural savings banks, pension fund managers, card and e-money issuers, cash-in-transit companies, Banco de la Nación and insurers with average assets of PEN 450 million or more	Full SGSI-C, cybersecurity program, authentication and third-party rules
Simplified	Investment banks, EDPYMEs, money transfer companies, COFIDE, Fondo MIVIVIENDA, Banco Agropecuario, surety companies, benefit funds and smaller insurers	Minimum activities, performed at least annually
Reinforced	Companies subject to an additional capital requirement for market concentration	All of the above, plus a designated board member and an independent assessment of the SGSI-C

A general-regime company facing material limitations can ask the SBS to apply the simplified regime, supported by its size and complexity.

What it requires, in five blocks

1. Governance and responsibilities

The board approves the SGSI-C policies, resources and organization (Article 5). The risk committee —or a specialized information security and cybersecurity committee— approves the strategic plan and the training plan (Article 7). The company must have an information security and cybersecurity function and a multidisciplinary incident handling team with representatives from legal, technical and organizational areas (Article 8).

2. Minimum security measures

Article 12 lists the minimum measures: personnel security, physical and logical access control based on least privilege, operations security (including preventing the exploitation of vulnerabilities), communications security and network segregation, secure development with security testing before go-live, incident management, physical security, cryptography and information asset management.

For incident management, it explicitly requires a security operations service with detection and response capabilities, plus access to threat intelligence and knowledge bases on attacker techniques and tactics.

3. Cybersecurity program

Every company with a presence in cyberspace must maintain a permanent cybersecurity program (Article 14), with an assessment and an improvement plan based on an international reference framework that covers, at a minimum, identification, protection, detection, response and recovery. In practice, many entities choose the NIST Cybersecurity Framework, whose functions match that structure, complemented by ISO/IEC 27001 for the management system.

4. Incidents and authentication

• Cybersecurity incidents with a significant adverse impact —information loss, fraud, reputational damage or service disruption— must be reported to the SBS as soon as they are identified, and the company must carry out a forensic analysis whose report remains available to the supervisor (Article 15).
• Digital channel transactions involving payments, transfers to third parties or beneficiary registration require strong authentication, with independent factors and a cryptographically generated authentication code (Article 19).

5. Third parties, cloud and APIs

Outsourcing IT, security or data processing services requires assessing the provider’s threats and vulnerabilities and setting its responsibilities by contract (Article 22). Cloud services require specific policies, and certifications such as ISO/IEC 27001, 27017 and 27018 or a SOC 2 Type 2 report are taken as references (Articles 23 and 24). APIs that expose services to third parties must include, among other measures, secure development, code review and vulnerability assessments and penetration testing (Article 21).

Where technical testing fits

The regulation is not a one-time checklist. Article 13 requires the SGSI-C to undergo periodic assessments, reviews and tests to determine its effectiveness, through internal and external services, according to its level of complexity and the threats it faces. In practical terms:

Requirement	Technical evidence that supports it
Prevent exploitation of vulnerabilities (Art. 12)	Vulnerability management and periodic penetration testing with retesting
Security testing before go-live (Art. 12)	Application pentesting and source code review
Detection and response by the security operations service (Art. 12)	Red Team or Purple Team exercises that measure detection times
Security of third-party-facing APIs (Art. 21)	API pentesting and review of secure coding practices
Third-party risk (Art. 22)	Technical assessments of services provided by third parties
Independent assessment under the reinforced regime (Art. 27)	Assessment by an independent team with experience and international certifications

The supervisor’s question is not whether the company has a firewall or a SOC, but how it knows they work. Documented technical testing is that answer.

Common mistakes in achieving compliance

• Treating the regulation as a documentation project rather than a system that is tested and improved.
• Choosing an international framework on paper without the initial assessment required by Article 14.
• Hiring pentests with minimal scopes that leave out digital channels, APIs and critical providers.
• Not defining in advance what counts as a “significant incident” and how it is reported to the SBS.
• Leaving fixed vulnerabilities without retesting: without verification, a fix is not evidence.

How we can help

At Kamaya Secure we combine regulatory assessment with technical testing: gap analysis against the regulation, cybersecurity program design, pentesting of applications, APIs and digital channels, and Red Team exercises that produce evidence useful to the risk committee and the supervisor. Learn more about our Compliance & Risk Management service and how we work with Banking & Fintech.