MLPS 2.0 (China's Cybersecurity Multi-Level Protection Scheme) Self-Check: GB/T 22239, Layer by Layer

What MLPS 2.0 is, and who must comply

The core standard of China's Multi-Level Protection Scheme 2.0 is GB/T 22239-2019 (effective 2019-12-01), grading information systems into five levels. Level 1 is self-protective; level 2 and above require formal evaluation (level 2 roughly every two years, level 3 annually). The scope is broad — effectively any operated information system — with enforcement concentrated on government, healthcare, education, finance, e-commerce, and SaaS holding user data.

The full workflow: classification → filing with public security → remediation → evaluation → ongoing supervision. Most teams stall at step three — closing gaps against the baseline requirements. That is exactly where a self-check pays for itself.

How it relates to miping: parallel, not alternative

Teams running the miping self-check often ask how the two relate: MLPS covers comprehensive security (physical/network/host/application/data/management); miping is the cryptography-specific assessment (algorithm/product/key compliance). Systems at MLPS level 3+ generally require miping under the Cryptography Law, and several artifacts (like the cryptography application plan) can be reused across both. Run the two checklists side by side instead of preparing twice.

The framework: 5 technical + 5 management layers

1. Physical and environmental security

• Physical access control (door access, CCTV)
• Power, cooling, fire/water/theft protection

Common gap: on cloud, this layer is the provider's responsibility — cite the provider's own MLPS filing evidence (Alibaba Cloud, Huawei Cloud etc. publish it) in your materials.

2. Communication network security

• Network segmentation into security zones (internet / application / data isolation)
• Encryption in transit for important data (HTTPS / Chinese-crypto TLS — overlaps with miping)
• Trusted verification (level-3 requirement)

3. Area boundary security

• Firewall policy minimization
• Role-based access control
• Intrusion prevention (IDS/IPS or cloud firewall)
• Boundary traffic logs retained ≥6 months (a hard statutory requirement)

Common gap: the 6-month log retention is the easiest quantitative item to lose — verify the actual retention setting, not the intention.

4. Computing environment security

• Two-factor authentication (mandatory at level 3: password + biometric/certificate/UKey)
• Account hygiene (rename defaults, disable guest, least privilege)
• Centralized audit logs + 6-month retention
• Minimal installation, unnecessary ports/services closed
• Data integrity and confidentiality in transit and at rest (database TDE / disk encryption, see hashing vs. encryption)
• Local + off-site backup (off-site mandatory at level 3)
• Personal-information protections (ties into PIPL, see the PIA self-check)

Common gap: a bastion host is practically mandatory at level 3 — it carries both the operations-channel audit and two-factor requirements.

5. Security management center

• Separation of system admin / audit admin / security admin accounts
• Centralized policy, log, and patch management (level 3)

The five management layers

• Policy document hierarchy (master policy + procedures)
• Security organization (appointment documents for the security lead)
• Personnel (background checks, training records with sign-ins)
• Build management (secure development and procurement processes)
• Operations management (change/backup/incident drills with execution traces)

Common gap: evaluators check execution evidence, not documents — the last three months of records are what gets sampled.

Level 2 vs. level 3, the decisive differences

Remediation order (by points per effort)

1. 6-month log retention — configuration-level, same-day fix
2. Two-factor — certificate/OTP on the bastion or VPN, one to two days
3. Off-site backup — cross-region replication on cloud counts
4. Management records — backfill the last quarter of training/drills/changes
5. Network segmentation evidence — a well-structured cloud security-group setup usually just needs a topology diagram

Implementer's note

One honest observation for operators: roughly 70% of the checklist on a cloud architecture is "configure + produce evidence", not "procure and build" — security groups are a minimal boundary control, and a cloud log service with adequate retention is the bulk of the audit item. The lesson echoes what building this site's privacy architecture taught me: most compliance cost lies in proving you did it, not in doing it. Run the self-check first, front-load the evidence work, and the evaluation cycle shrinks by half.

Related reading

• Miping self-check: GB/T 39786 layer by layer
• PIPL PIA self-check
• Chinese-crypto HTTPS deployment