Data Development and Utilization — Have You Done Your Classified Protection Right?

1. Classified Protection Is Not About "Just Passing an Assessment" — Three Things You Need to Get Right

Many enterprises read classified protection as "run an assessment, get a report." That falls far short of what is required. The core technical framework of MLPS 2.0 is "one center, triple protection  and when mapped onto the concrete work of developing and utilizing data, three things have to be done properly.

1.1 The First Thing: The Computing Environment Has to Be "Kept Under Control" 

A data processing system must deliver the following:

 • Identity authentication: Who can log in, who can operate, who can export — permissions must be managed by tier. You cannot use one account that "does it all."

 • Access control: Authorization follows the "minimum necessary" principle. Data processing staff may only access the minimum data set their work actually requires.

 • Data encryption: Storage must be encrypted, especially fields involving personal information and important data.

 • Backup and recovery: There must be a data backup mechanism and a disaster recovery plan, and both must be drilled on a regular basis. Having a backup is not the end of it — you have to be able to actually restore.

【Practical Tip】Many enterprises assume that installing encryption software counts as "data encryption." But if key management and the encryption algorithms themselves are non-compliant, you will still be marked down in an MLPS assessment. Our advice: check your technical measures item by item against the requirements for the corresponding MLPS 2.0 level, and verify that each one is actually effective.

1.2 The Second Thing: Network Boundaries Have to Be "Segmented Off"

Data development and utilization typically involves data flowing between multiple systems. Classified protection requires:

• Network segmentation: Data processing systems must be reasonably segmented from other systems. The network cannot be left "flat and wide open."
• Boundary isolation: Boundary protection devices — firewalls, intrusion detection systems and the like — must be deployed to prevent unauthorized cross-domain access.
• Transmission encryption: Data transmitted between systems must be encrypted. It cannot travel in plaintext.

【Practical Tip】A common problem with data development and utilization projects is this: for the sake of "convenient data flow," development teams tend to open up every network channel. From a classified protection standpoint, that is a high-risk item — you have to achieve "data connected, networks segmented," routing data through controlled channels such as API gateways and data exchange platforms, rather than opening up the networks directly.

1.3 The Third Thing: Security Responsibility Cannot Be "Passed Off"

This point needs to be emphasized in particular: the data processor is the entity that bears security responsibility.

Whether your data processing system was developed in-house or by a third party on commission; whether your security services are delivered by an in-house team or outsourced to a security firm — when something goes wrong, the responsible party is the data processor, not the third party. The classified protection regime sets out one clear principle: security responsibility cannot be outsourced through "outsourcing."

【Practical Tip】When you sign a data processing agreement with a third party, you must explicitly stipulate how security responsibility is divided, the response process for security incidents, and the clauses on compensation for breach. But contract terms cannot stand in for fulfilling your classified protection obligations — the data processor itself must still ensure that the system passes its MLPS assessment and continues to meet the requirements on an ongoing basis.

2. How Should MLPS Grading Be Done? — It Directly Shapes Your Data Development and Utilization Plan

MLPS grading is not a matter of "picking a level at random." It directly determines what security requirements your data development and utilization work has to satisfy.

2.1 The Two Dimensions of Grading

The classified protection regime determines a system's level by weighing two dimensions together:

Dimension	Core consideration
Business information security	The degree of harm caused by data leakage, tampering, or loss
System service security	The social impact caused by an interruption of the system

 2.2 Grading Essentials in Data Development and Utilization Scenarios

• Systems involving important data — graded at least Level 3.
• Systems involving core data — graded at least Level 4.

The higher the level, the stricter the security requirements and the greater the investment required. But by the same token, if the level is set too low, then once a data security incident occurs, the enterprise faces heavier legal liability.

【Practical Tip】For grading, we recommend following the principle of "err on the high side." This matters especially where data classification and grading do not line up with MLPS grading: better to set one level too high than one level too low. Setting the level too low means not only inadequate security investment, but also that if something goes wrong, the enterprise may be found to have "failed to fulfill its classified protection obligations" — exposing it to stricter administrative penalties and even criminal liability.

2.3 Common Misconceptions About Grading

Misconception	The right approach
"Our system isn't important, so Level 2 is enough."	Grading is based on the degree of harm caused by data leakage or tampering — not on whether you happen to think the system matters.
"Once we're at Level 3, we're set for good."	When the business scope expands, data volumes grow, or new types of data come into scope, the grading has to be reassessed.
"Passing the MLPS assessment is all that matters."	Classified protection is an ongoing compliance requirement, not a one-off exam. It calls for periodic reassessment and day-to-day operations and maintenance.

3. How Classified Protection Relates to the Data Security Law — Three Questions Enterprises Most Often Confuse

In practice, the question enterprises most often confuse is this: what exactly is the relationship between classified protection and the Data Security Law? Once you have passed classified protection, does that mean you no longer have to bother with the Data Security Law?

3.1 Question One: Is Classified Protection a "Precondition" or a "Reference Standard"?

The answer: a precondition.

1. A data processing system that has not passed its MLPS assessment may not carry out development and utilization activities involving important data or core data. Classified protection is an "admission ticket," not an "elective course."

【Recommended Action】Before starting a data development and utilization project, first confirm whether the system has already passed MLPS assessment at the applicable level. If it has not, complete the MLPS assessment first, and only then begin the data development and utilization activities.

3.2 Question Two: Once You Have Passed Classified Protection, Do You Still Need a Data Security Assessment?

Yes.

Classified protection addresses security issues at the level of network infrastructure and systems. The Data Security Law and its supporting regulations focus on security protection obligations across the entire data lifecycle. The two differ in what they protect and what they focus on:

Dimension Classified protection regime Data security regime
Object of protection Networks and information systems The data itself
Core requirement System security protection capability Data classification and grading; full lifecycle management
Assessment requirement MLPS assessment (Level 2: periodic self-inspection; Level 3 and above: annual assessment) Data security risk assessment (at least once a year for processors of important data)
Typical measures Identity authentication, access control, intrusion detection Data classification and grading, security assessment, emergency response

【Recommended Action】MLPS assessment and data security assessment are two independent compliance actions, and neither can substitute for the other. Enterprises should pursue both at the same time, rather than treating it as an "either/or" choice.

3.3 Question Three: If the Same Conduct Violates Both Classified Protection and the Data Security Regime, How Is It Punished?

Current law does not say explicitly.

Both laws provide for penalties such as warnings, fines, orders to suspend business, suspension of business for rectification, and revocation of licenses. But where the same conduct violates both regimes at once, whether to "punish under one only," "stack the penalties," or "apply the heavier one" — there is currently no clear legal guidance.

【Recommended Action】Do not count on being punished "only once." The safest approach is to satisfy the dual compliance requirements of the classified protection regime and the data security regime at the same time, rather than hunting for a "gap" between the two.

4. Classified Protection Challenges in New Scenarios — What Enterprises Doing AI-Based Data Development and Utilization Need to Watch

If your data development and utilization involves generative AI (large-model training, AI application development, and so on), there is one issue that deserves particular attention: current classified protection standards have not yet systematically brought AI-specific security requirements into their technical indicator system.

### 4.1 Where Exactly Do the Challenges Lie?

The data processing involved in generative AI has its own particularities:

• Security of training data: The source compliance, content safety, and labeling quality of pre-training data and optimization training data have no dedicated assessment items in the traditional classified protection framework.
• Uncontrollable model outputs: AI models may generate content that contains sensitive information, and this form of "data leakage" is entirely different from leakage caused by a traditional system being breached by hackers.
• Compound risks that are hard to assess: The consequences of a security incident in an AI system may generate new types of risk beyond the two dimensions of "business information security + system service security."

### 4.2 What Should Enterprises Do?

Although no dedicated standard has been issued yet, that does not mean "wait and see" is good enough. Enterprises involved in AI-based data development and utilization are advised to:

• Benchmark proactively against existing standards: Follow the Cybersecurity technology — Security specification for generative artificial intelligence pre-training and optimization training data (GB/T 45652-2025) to manage training data security properly.
• Cover as much as possible within the existing classified protection framework: Bring the training data of AI systems into the scope of existing MLPS assessment items such as data encryption, access control, and security audit.
• Track standards developments: Revision of the MLPS 2.0 standards system is already under way, and extended system security requirements for emerging technologies are expected to be incorporated progressively. Ongoing tracking is recommended.

5. Where Things Are Heading: Three Directions for Enterprise Compliance

5.1 Direction One: "Joint Review" of Classified Protection and Data Security Assessment

At present, enterprises may face multiple compliance requirements at once — MLPS assessment, data security risk assessment, commercial cryptography application security assessment, and more — which is no light burden. At the institutional level, a "joint review" mechanism built on "one assessment, mutual recognition of results, and information sharing" is being promoted, to be conducted jointly by data security and cybersecurity regulators.

【What Enterprises Should Do】You can start now by mapping out your own multiple compliance assessment needs and identifying the steps that can be consolidated, so that you are ready for joint review down the road.

5.2 Direction Two: Iteration of Classified Protection Technical Standards

Revision of the MLPS 2.0 standards system is under way and is expected to add extended system security requirements for emerging technologies, designing specific assessment items and bottom-line trigger conditions for fields such as AI and quantum computing.

【What Enterprises Should Do】Keep track of developments in the revision of classified protection standards, assess in advance whether your own business will be affected by the new standards, and set aside a budget for technical upgrades where necessary.

5.3 Direction Three: "Erring on the High Side" Becomes the Norm

Where the MLPS level and the data classification and grading protection level do not match, the direction of the regime is to apply the "err on the high side" principle.

【What Enterprises Should Do】Re-examine whether the MLPS grading of your existing systems matches your data classification and grading. For systems involving important data or core data, make sure the MLPS level is not lower than the data protection requirement.

 Conclusion

The classified protection regime draws a security red line for data development and utilization. That red line is not a "stumbling block" holding development back — it is a "guardrail" that lets data development and utilization move steadily and go the distance.

For enterprises, holding the bottom line is the precondition for talking about growth. Rather than reacting passively once problems surface, it is better to get classified protection compliance on solid footing right now.