China's 2026 Data Security Risk Assessment Rules: From Compliance Checklists to Clear Risk Communication

China's new Network Data Security Risk Assessment Measures, effective August 2026, shift focus from static compliance to dynamic risk management, requiring organizations to identify data assets, map flows, define concrete risk scenarios, and provide remediation evidence across six key scenarios including AI training and third-party processing.

Frontline Investigation
Frontline Investigation
Frontline Investigation
China's 2026 Data Security Risk Assessment Rules: From Compliance Checklists to Clear Risk Communication

On June 18, 2026, the Cyberspace Administration of China (CAC), the Ministry of Industry and Information Technology (MIIT), and the Ministry of Public Security (MPS) jointly released the Network Data Security Risk Assessment Measures , effective August 20, 2026. The regulation marks a fundamental shift in data security governance: from verifying the existence of policies, systems, and ledgers to demanding explainable, auditable, and closed-loop risk assessment — answering where risks lie, how severe their impact is, whether evidence supports findings, and whether remediation is complete.

1. The Regulation Addresses "How to Assess"

Upper-level laws such as the Data Security Law and the Network Data Security Management Regulations already required important data processors to conduct regular risk assessments and submit reports. In practice, organizations struggled with three questions:

Which data and processing activities fall within the assessment scope?

Should assessment focus on system vulnerabilities or business processes?

How to turn assessment results into concrete remediation actions rather than archived documents?

The Measures institutionalize answers: important data processors must assess annually; when significant changes occur in data security status, timely assessment of affected parts is required; processors of general data are encouraged to assess at least every three years. Risk assessment becomes a continuous governance mechanism that evolves with data processing activities.

2. Data Security Risk Assessment ≠ MLPS (等保测评)

Many confuse data security risk assessment with another round of security evaluation. The article clarifies the distinction:

MLPS (Multi-Level Protection Scheme) focuses on conformity of information system security protection capabilities — system boundaries, technical controls, management systems, and whether security construction meets grade requirements.

Data Security Risk Assessment focuses on the data itself and processing activities: data origin, recipients, usage methods, necessity, authorization boundaries, traceability, and impact of leakage or misuse.

Comparison of key dimensions:

Assessment object: MLPS examines information systems, security controls, management systems; data risk assessment examines network data, processing activities, data flow chains.

Core question: MLPS asks whether system security capabilities meet grade requirements; data risk assessment asks whether processing activities carry identifiable, evaluable, and manageable risks.

Typical evidence: MLPS relies on policy documents, configuration screenshots, device inventories, evaluation records; data risk assessment uses data catalogs, classification results, interface call logs, authorization records, processing purpose statements, impact analyses.

Output value: MLPS proves the system possesses corresponding security protection capabilities; data risk assessment supports business decisions, regulatory inspections, risk remediation, and data development and utilization.

The two are complementary. Mature practice integrates MLPS, data classification, personal information protection, important data identification, log auditing, interface governance, outsourcing management, and emergency response into a single risk closed loop.

3. A Reusable "Four Lists" Assessment Framework

The most practical starting point for internal implementation is building four lists before writing reports.

3.1 Data Asset Inventory: Know What You Have

First step: clarify data objects. Must answer:

Which business systems, databases, file stores, interfaces, reports, and backups are involved?

Is data general, important, or does it contain personal or sensitive personal information?

Do copies, caches, exported files, training samples, test data, and offline analysis sets exist?

Is data used by third-party systems, outsourcing personnel, algorithm models, or automation tools?

Many incidents stem not from primary database breaches but from uncontrolled copies — temporary Excel exports, real data in test environments, historical logs in interface platforms, unstructured documents in knowledge bases.

3.2 Data Flow Inventory: Track Where Data Goes

Risks often appear where data moves. Assessment must map flow paths:

Is collection source legal, necessary, and transparent?

How is data exchanged between departments, systems, and platforms?

Do interface calls have identity authentication, access control, rate limiting, and log retention?

Is data used beyond its original purpose?

Are entrusted processing, joint processing, and external provision governed by clear boundaries and responsibilities?

A system may appear low-risk when only database permissions are considered; adding interfaces, reports, bulk exports, O&M channels, and third-party calls completely changes the risk profile.

3.3 Risk Scenario Inventory: Write Risks in Business Language

Vague statements like "unauthorized access risk" or "leakage risk" are insufficient. Effective scenarios are concrete:

Bulk query interface lacks business purpose validation, enabling internal accounts to query beyond scope.

Test environment reuses production data with incomplete desensitization rules, exposing sensitive fields.

Third-party service providers hold long-term high-privilege accounts; permissions not revoked promptly after departure.

Model training or knowledge base construction ingests documents containing personal information or internal sensitive content.

Data reports are forwarded through multiple levels, recipient scope exceeding original authorization boundaries.

Specific scenarios drive specific remediation; otherwise reports only yield generic "strengthen management, raise awareness, improve systems."

3.4 Remediation Evidence Inventory: Prove Risks Were Handled

Assessment does not end at discovery; evidence of remediation must be retained. Reusable evidence includes:

Data classification results and important data identification records.

Account permission change records, approval forms, least-privilege configuration screenshots.

Interface call logs, abnormal access handling records, audit reports.

Desensitization rules, encryption policies, key management records.

Entrusted processing agreements, third-party security assessment materials, departure permission revocation records.

Emergency drill records, incident retrospective reports, remediation acceptance forms.

These materials serve beyond "passing inspections." When business seeks to expand data sharing, build data platforms, introduce intelligent agents, integrate large models, or open data interfaces, management can base decisions on evidence: which data can be used, which scenarios need restrictions, which capabilities must be built first.

4. Six Key Scenarios to Prioritize

Organizations need not start with complex models. Covering six high-frequency scenarios uncovers most real risks:

Data Collection: Over-collection, unclear purpose, insufficient authorization. Check: field necessity, informed consent or legal basis adequacy.

Data Storage: Scattered copies, uncontrolled backups, undesenitized test data. Check: unified governance of production, test, backup, and offline files.

Data Usage: Internal privilege escalation, bulk queries, purpose drift. Check: least-privilege accounts, business justification and audit for queries.

Data Sharing: Interface abuse, unclear recipient responsibility, insufficient logs. Check: interface authentication, call frequency, recipient boundaries, traceability.

Entrusted Processing: Excessive outsourcing permissions, incomplete data retrieval. Check: contract boundaries, account lifecycle, deliverables, data destruction proof.

New Technology Application: AI training contamination, knowledge base leakage, automated mis-invocation. Check: training data sources, sensitive content filtering, tool invocation permissions, output auditing.

The core message: data security is not solely the security department's responsibility. Business, legal, compliance, R&D, operations, procurement, and outsourcing management all sit on the same chain.

5. Implications for Industry Software and Digital Construction

The Measures signal that future data security capabilities will increasingly embed into product design and project delivery. Traditional approach — build system first, then retrofit policies, permissions, logs, evaluations — will become unsustainable.

Effective capabilities are process closed loops, not point functions. Industry software must deliver five product capabilities:

Automated data asset discovery: Identify sensitive data clues in tables, fields, interfaces, files, logs, reports to support classification and important data identification.

Data flow visualization: Track, display, and audit paths from collection, storage, processing, sharing to destruction.

Permission-purpose binding: Access decisions should link business roles, processing purposes, approval bases, and usage scopes — not just account permissions.

Risk rules and assessment templates: Support industry-specific risk check items, converting policy requirements into executable, reusable check templates.

Remediation closed-loop and evidence management: Risk discovery, responsibility assignment, remediation measures, re-verification results, and evidence materials form a closed loop, preventing reports from being archived without follow-up.

This is the key step moving data security governance from "manual form-filling" to "platform-based operations."

6. Simplified Implementation Path: Small Closed Loop First, Then Platform

For most organizations, the realistic path is not immediately building a massive data security platform but running a small closed loop first. Five-step progression:

Select a high-value business domain (e.g., user data, transaction data, law-enforcement collaboration data, public service data, core operational data).

Build data asset and flow inventories covering key systems, interfaces, reports, and third parties.

Identify risks across the six scenarios: collection, storage, usage, sharing, entrusted processing, new technology application.

For each high-risk item, define remediation action, owner, deadline, and acceptance evidence.

Convert this assessment into a template and replicate to other business domains.

Benefit: organization first produces a verifiable pilot rather than sinking into a large, comprehensive ledger project.

Conclusion

The value of data security risk assessment lies not in generating another report but in enabling the organization to truly see: which data is important, which flows are dangerous, which permissions are excessive, which external collaborations lack boundaries, which new technology applications lack safety guardrails.

The ultimate question is not "has an assessment been done?" but "can evidence demonstrate that risks have been identified, evaluated, and disposed of?"

As data element circulation, AI applications, industry large models, intelligent agents, and automated processes deepen in business, data security governance must shift from static compliance to dynamic risk management. Organizations that turn risk assessment into a daily operational capability will find a more stable balance between security and development.

Sources and References

CAC: CAC and two other departments jointly release Network Data Security Risk Assessment Measures , 2026-06-18. https://www.cac.gov.cn/2026-06/18/c_1783525609778371.htm

CAC: Q&A on Network Data Security Risk Assessment Measures , 2026-06-18. https://www.cac.gov.cn/2026-06/18/c_1783525609948038.htm

CAC: Expert interpretation Establishing and Improving Data Security Risk Assessment System, Building a Solid National Data Security Barrier , 2026-06-18. https://www.cac.gov.cn/2026-06/18/c_1783525613011453.htm

CAC: Notice on issuing Financial Information Service Data Classification and Grading Guidelines , 2026-06-13. https://www.cac.gov.cn/2026-06/13/c_1782919789934988.htm

CAC: Notice on issuing Catalog of Products Implementing Cybersecurity Labeling (First Batch) and related implementation rules, 2026-06-18. https://www.cac.gov.cn/2026-06/18/c_1783525604615337.htm

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

data governancerisk assessmentdata securityAI securityregulatory compliancethird-party riskChina regulationsMLPS
Frontline Investigation
Written by

Frontline Investigation

Daily curates a variety of tech resources, tools, tips, and news (5G, big data, cloud computing, AI), aiming to become a go-to popular science encyclopedia for everyone.

0 followers
Reader feedback

How this landed with the community

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.