Information Security 35 min read

Understanding the PBOC’s New Data Security Management Measures (Effective 2025)

The People's Bank of China has issued a comprehensive Data Security Management Measures, effective June 30, 2025, outlining classification, protection, risk monitoring, incident response, and legal responsibilities for all data processors handling business‑domain data.

Data Thinking Notes
Data Thinking Notes
Data Thinking Notes
Understanding the PBOC’s New Data Security Management Measures (Effective 2025)

Chapter 1 General Provisions

Article 1 To standardize the security management of business‑domain data of the People’s Bank of China (PBOC) and promote its development and utilization, this Measures is formulated in accordance with the Cybersecurity Law, Data Security Law, Personal Information Protection Law, PBOC Law, and other relevant regulations.

Article 2 This Measures applies to processing activities and security supervision of business‑domain data conducted within the People’s Republic of China. If other competent authorities have regulations, they shall also be complied with.

Article 3 The term "business‑domain data" refers to network data generated and collected within the PBOC’s business domain that does not involve state secrets. "Data processor" refers to financial institutions and other entities approved or recognized by the PBOC.

Article 4 Business‑domain data security work follows the principle that whoever manages the business, manages its data, and manages its security. The PBOC holds supervisory responsibility; data processors must fulfill protection obligations and prevent tampering, destruction, leakage, illegal acquisition or use, thereby safeguarding national security, public interest, and legitimate rights.

Article 5 Under the national data‑security coordination mechanism, the PBOC and its branches shall supervise data security, strengthen cooperation with other authorities, and communicate information.

Article 6 Financial industry associations shall strengthen self‑discipline, formulate data‑security standards, and guide members in protecting business data.

Article 7 Data processors are encouraged to innovate in data security applications, promote efficient data flow and utilization, and share successful innovations within the industry.

Chapter 2 Business Data Classification, Grading and Overall Requirements

Article 8 The PBOC shall develop standards for data classification and grading, guide the work, and compile a dynamic catalogue of important data.

Article 9 Data processors must establish a classification‑grading system and operating procedures, and follow internal approval processes for classification results.

Article 10 Processors shall create a data resource catalogue, identifying personal information, external collection, system lists, and business categories for each data item.

Article 11 Sensitivity grading is based on potential harm to individuals, organizations, or public interest if data is leaked or misused. High‑sensitivity items include personal data, commercial‑secret information, and other strictly controlled business information.

Article 12 Availability grading is based on the impact of data tampering or loss on business operations, defining recovery‑point objectives for information systems.

Article 13 Business data are divided into general, important, and core data. Important data are those whose compromise could endanger national security, economic stability, or public health. Core data have higher coverage or precision and, if misused, could affect political security.

Article 14 The PBOC will compile an important‑data catalogue, and data processors must identify and report whether their data belong to important or core categories.

Article 15 Processors must update the data resource catalogue at least annually, accurately recording system‑stored data items and identifiers.

Article 16 Processors shall assign dedicated data‑security departments, staff with appropriate expertise, and establish reward‑penalty rules for data‑security responsibilities.

Article 17 Processors must provide convenient complaint and reporting channels for data‑security issues.

Article 18 Important‑data processors must designate a security responsible person and management institution, ensuring they meet legal qualifications and can report directly to the PBOC.

Article 19 Processors shall establish full‑process data‑security management systems, aligning protection measures with classification and grading, and define operation and approval procedures.

Article 20 When different sensitivity items are processed together and differentiated protection is difficult, the higher‑sensitivity measures shall be applied.

Article 21 Annual training plans for data‑security must be developed, covering standards, risk prevention, responsibilities, protection measures, and emergency response.

Chapter 3 Full‑Process Business Data Security Management Requirements

Article 22 Processors must strictly manage privileged accounts, enforce pre‑approval and post‑audit for any creation, deletion, or modification of data, and verify correctness before automated operations.

Article 23 Strong authentication is required for privileged accounts, including multi‑factor authentication, timeout logout, and re‑verification for address changes.

Article 24 Logs of data‑processing activities must be recorded to support risk tracing and incident handling; high‑sensitivity items in logs should be masked unless unmasked handling is justified and uniformly managed.

Article 25 Logs must be retained for at least six months (general), one year (important data systems), and three years (core data systems). Logs related to personal information or important data shared with other processors must be kept for at least three years.

Article 26 Data collection should prioritize direct entry or system‑to‑system interaction, with identity verification for entry personnel or data providers.

Article 27 Cross‑verification techniques should be used to ensure data accuracy.

Article 28 Automated tools for data collection must respect the source’s control rules and must not disrupt network services.

Article 29 Storage protection measures include isolating test and production environments, meeting tier‑3 (important data) or tier‑4 (core data) network security protection levels, encrypting high‑sensitivity items, and following commercial‑cipher requirements where applicable.

Article 30 Backup capacity must be evaluated, redundant backups performed, and their availability regularly verified.

Article 31 Processors must define de‑identification strategies for high‑sensitivity items to reduce re‑identification risk.

Article 32 Terminal device security policies must be established, with technical measures to mark the account and time when data is displayed or printed.

Article 33 Data used in development or testing must undergo internal approval and be de‑identified unless the environments are identical in security controls.

Article 34 Algorithm risk assessment and control strategies must be defined for data‑processing algorithms, including explainability, vulnerability mitigation, and fallback plans for automated decisions.

Article 35 Transmission protection measures include using dedicated lines or VPNs, strengthening access control, encrypting high‑sensitivity items, and evaluating transmission capacity.

Article 36 Gateways and APIs must be listed, tested for security before deployment, and any discovered risks must be remedied promptly.

Article 37 When providing data to external parties, contracts must specify security obligations, purposes, scope, storage periods, and supervision mechanisms.

Article 38 Risk assessments for outsourced processing must be performed, with due‑diligence on core‑data handlers.

Article 39 Publicly disclosed data must have rules preventing automated collection and must be protected against tampering.

Article 40 Data destruction strategies for storage media must be defined and supervised.

Chapter 4 Business Data Security Risk and Incident Management

Article 41 Processors must monitor risks, identify illegal information, malware, weak passwords, protection failures of high‑sensitivity items, abnormal processing activities, and insufficient transmission or storage capacity, and take immediate remedial actions.

Article 42 Monitoring of data leakage, illegal sale, impersonation, and negative public opinion must be conducted, with prompt verification and handling of identified risks.

Article 43 When the PBOC reports security defects or vulnerabilities, processors must verify and respond promptly, providing accurate feedback as required.

Article 44 Important‑data processors must conduct an annual risk assessment and submit the report by January 15 each year, covering personnel training, system protection, responsibilities, network security assessments, monitoring, incident handling, and any other required content.

Article 45 Incident grading must consider recovery‑point objectives, service downtime, affected transactions, number of affected individuals or organizations, and the scale of compromised data items.

Article 46 Processors must promptly take remedial measures, notify users, and report incidents to the PBOC as required.

Article 47 Important‑data processors must conduct at least one emergency drill per year; other processors must drill at least once every three years.

Article 48 Compliance audits on data‑security measures must be performed at least every three years (annually for important data), focusing on catalogue updates, account management, contract completeness, protection effectiveness, outsourcing supervision, gateway security, risk monitoring, cross‑border data handling, and complaint handling.

Article 49 Auditors and risk‑assessment personnel must have their data‑access rights managed and ensure data security during the assessment process.

Article 50 Reports containing high‑sensitivity items must be de‑identified.

Article 51 When third‑party assessments are outsourced, contracts must specify security obligations, and the institution’s personnel must participate throughout.

Chapter 5 Legal Liability

Article 52 The PBOC may interview or require corrective measures from processors with significant security risks, and may request national‑security reviews for activities that could affect national security.

Article 53 The PBOC and its branches may conduct enforcement inspections on data‑security obligations, jointly with other authorities if needed.

Article 54 Failure to conduct outbound‑data security assessments or certifications will result in case transfer to the relevant cyber‑security department.

Article 55 Violations such as not establishing full‑process security management systems, not providing security training, not taking technical protection measures, not designating responsible persons, failing to monitor risks, not taking immediate remedial actions, not reporting incidents, or not conducting annual risk assessments will be punished according to the Data Security Law.

Article 56 Processors that restrict competition, infringe lawful rights, or engage in illegal activities will be dealt with according to relevant laws, and cases may be transferred to other competent authorities.

Article 57 If data‑processing activities constitute criminal behavior, case information will be transferred to public security or national‑security organs.

Article 58 Processors that can prove they took required security measures and immediate remedial actions may receive reduced administrative penalties.

Article 59 Processors that voluntarily provide security‑risk intelligence and assist in discovering major risks may also receive leniency.

Article 60 PBOC staff who neglect duties, abuse authority, or commit fraud in supervision will be disciplined according to law.

Chapter 6 Supplementary Provisions

Article 61 Definitions: data item, structured data item, unstructured data item, terminal device, export method, verification method, unified normative management.

Article 62 The PBOC is responsible for interpreting this Measures.

Article 63 This Measures shall take effect on June 30, 2025.

risk managementinformation securityData SecurityregulationPBOC
Data Thinking Notes
Written by

Data Thinking Notes

Sharing insights on data architecture, governance, and middle platforms, exploring AI in data, and linking data with business scenarios.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.