Kazakhstan Bank Information Security Requirements: What They Mean for AppSec

Information security requirements for Kazakhstan banks are set by the Agency of the Republic of Kazakhstan for Regulation and Development of the Financial Market (ARDFM). Since 2026, ARDFM has replaced the former requirements of the National Bank of Kazakhstan (NBK) with its own acts: Resolution No. 53 dated 3 April 2026 and Resolution No. 81 dated 20 April 2026. For AppSec, this means you must be able to test your applications in a verifiable way, manage vulnerabilities, and answer for the results at the level of the top executive. Below are the acts we confirmed against official and reference sources, and what follows from them for secure development.

Which acts regulate bank information security in Kazakhstan

It helps to separate three levels: industry requirements of the regulator, general ICT requirements, and top-level codes.

• ARDFM Management Board Resolution No. 53 dated 3 April 2026, "On Approval of the Requirements for Ensuring Information Security of Banks, Branches of Non-Resident Banks of the Republic of Kazakhstan and Organizations Carrying Out Certain Types of Banking Operations". According to the reference system, it has been in force since 18 April 2026. It is adopted on the basis of Article 55 of the Law "On Banks and Banking Activities". Structure: general provisions, IS management system, classification of information assets, access to assets, security of the information infrastructure.
• ARDFM Management Board Resolution No. 81 dated 20 April 2026, "On Approval of Minimum Information Security Requirements in the Financial Market". In force since 12 July 2026. According to a law firm's commentary, it covers banks, insurers, securities market participants, microfinance organizations and other financial institutions.
• NBK Management Board Resolution No. 48 dated 27 March 2018 (reg. No. 16772), the former bank IS requirements and incident notification rules. Repealed upon adoption of ARDFM Resolution No. 53.
• Digital Code of the Republic of Kazakhstan dated 9 January 2026 No. 255-VIII, in force since July 2026. It sets the cybersecurity framework, with details delegated to subordinate acts.
• Law "On Informatization" dated 24 November 2015 No. 418-V, referenced by the Unified Requirements in the Field of ICT and Information Security.

An important caveat on the "Unified Requirements": these are Government Resolution No. 832 dated 20 December 2016, not an ARDFM act. They are binding on state bodies, the quasi-state sector, owners of critical ICT objects and owners of non-state information systems integrated with state systems. The document itself excludes cases where its application would contradict banking legislation. For a bank, therefore, the main document is the ARDFM requirements. The Unified Requirements become relevant where your systems are integrated with state services.

What the former rules required for secure development

Resolution No. 48 in its earlier wording contained specific rules for software of remote banking services (per the text published in the reference system before it was repealed):

• source code is stored in repository management systems inside the security perimeter, with backups;
• development and test environments are separated from production, and developers do not make changes in production;
• default security settings are changed and test accounts are removed before launch;
• mandatory security testing, including at minimum static code analysis and analysis of components and third-party libraries (in effect, SAST and SCA);
• critical vulnerabilities are fixed before commissioning; responsibility for code developed by a contractor remains with the bank;
• information assets are scanned at least once every six months, and infrastructure is penetration-tested by independent external specialists.

We did not find an open full text of Resolution No. 53, so we do not assert which of these rules were carried over into it word for word. The practical rule: assume the previous level of requirements will be maintained or raised, and verify exact wording against the text on adilet.zan.kz.

What is confirmed in the new acts

According to the commentary on Resolution No. 81 (the source is a law firm, not the text of the act):

• the head of a financial organization bears personal responsibility for information security;
• incidents (exploitation of software vulnerabilities, unauthorized access, DDoS, server infection, unauthorized transfers, outages longer than one hour) must be reported without delay through the automated incident management system (ASOI);
• external access requires at least two independent authentication factors;
• audit logs are stored with integrity protection (three months online and one year in archive, or one year online);
• when external servers and storage services are used, the organization must prevent third-party access to data that the law prohibits from disclosure, including personal data.

These provisions directly affect development. Incidents involving exploitation of software vulnerabilities are a separate reporting category, which means managing application vulnerabilities becomes a matter of reporting to the regulator.

What this means for AppSec practice

1. Static analysis and SCA in the process, not once a year. If the regulator expects evidence of code and third-party component analysis, you need reports for every build. Start with choosing the right tool classes and embed them in CI/CD.
2. Software bill of materials (SBOM). To find out within hours whether you are affected by a new vulnerability, you need an up-to-date list of dependencies. See what an SBOM is.
3. Independent testing. External penetration testing and security assessment of critical systems remain standard practice for banks. Learn more on the security assessment page.
4. Source code inside the perimeter. Repositories, CI and scanners running inside the bank's perimeter are easier to protect than external services. This is one argument for on-premise solutions.
5. Secrets and keys. Authentication and access control requirements also apply to service accounts and tokens. See secrets management.
6. Contractors. The bank is responsible for code written by a contractor. Contracts need secure development requirements, and supplied builds need to be checked.

A DevSecOps implementation helps build the whole process. It turns regulatory requirements into checks at every pipeline stage and into ready-made reporting.

Where to start a compliance review

• Obtain the current texts of Resolutions No. 53 and No. 81 and build a matrix of "requirement, control, evidence".
• Classify applications by criticality. This determines the depth of testing and the frequency of checks.
• Identify where evidence is missing: SAST/SCA reports, penetration test results, a log of vulnerability remediation.
• Agree with the IS team on a procedure for reporting incidents related to application vulnerabilities.

Unified Requirements: what matters for developers

If some of the bank's systems are integrated with state systems (for example, with the e-government platform), the Unified Requirements (Resolution No. 832) apply. According to the text in the reference system, they were last amended by Government Resolution No. 119 dated 25 February 2026. Their IS-related content includes:

• event logs are kept for at least three years, with at least two months available for operational analysis; e-government objects of classes 1 and 2 are connected to the IS monitoring system;
• multi-factor authentication is required for objects of classes 1 and 2;
• among the mandatory documents is a report on the vulnerability assessment of network resources, and a procedure for incident notification and response;
• e-government objects are put into production from executable code built from source code transferred to the State Technical Service, following the rules of the unified repository.

We did not find requirements for the SDLC or penetration testing in the part of the text available to us. However, the document is long, and testing of e-government objects and critical ICT objects is governed by separate methodologies approved on the basis of the Law "On Informatization". If you integrate with state systems, find out the class of the object and the requirements that come with it.

How to build a compliance matrix

1. List the requirements of No. 53 and No. 81 in a table: clause, wording, owner, control, evidence.
2. For each application, record its criticality category and the type of data it processes.
3. Link the requirements to specific pipeline steps: SAST and SCA on every pull request, DAST before release, manual penetration testing at an interval set by your policy.
4. Set up automatic collection of reports: it is easier for an auditor to review an export from the system than to collect screenshots.
5. Assign owners for fixing vulnerabilities and deadlines by severity.

This matrix is also useful when checking contractors: the same requirements can be included in the development contract.

Frequently asked questions

This article is for information purposes only and does not constitute legal advice.

Sources

• ARDFM Resolution No. 53 dated 3 April 2026 (prg.kz)
• NBK Management Board Resolution No. 48 dated 27 March 2018 (repealed)
• Minimum IS requirements for the financial market, Resolution No. 81 (commentary by SOLIS Partners, prg.kz)
• Government Resolution No. 832 dated 20 December 2016 (Unified Requirements)
• Digital Code: what changes for citizens and business (zakon.kz)