MLPS and PIPL IT Compliance Checklist for China Offices

The short answer: If your company operates in mainland China, two separate regimes generally apply to your IT environment at the same time: MLPS (等保, the classified cybersecurity protection system) governs how you must secure the network and information systems themselves, while PIPL (the Personal Information Protection Law) governs how you collect, use, and move personal information — especially transfers outside China. Foreign-invested offices most often fall short not on ignorance of the rules but on treating "our cloud provider is certified" as sufficient, and on underestimating how broadly "cross-border transfer" gets defined. This checklist sets out what MLPS 2.0 and PIPL practically require, where foreign offices most commonly have gaps, and how to build a readiness posture before an audit, client due-diligence request, or incident forces the question.

Every foreign-invested enterprise running IT infrastructure in mainland China eventually runs into the same pair of acronyms: MLPS and PIPL. They come from different parts of China's cybersecurity and data-protection framework, they are enforced by different mechanisms, and — critically — they are not interchangeable. MLPS (等级保护, commonly shortened to 等保) is about the security of your network and information systems: how they are classified, protected, and periodically assessed. PIPL is about personal information: what you may collect, on what legal basis, and under what conditions you may move it outside mainland China. A foreign company can be doing reasonably well on one and still have real exposure on the other. This guide is written for the compliance officer, IT lead, or ops manager at a foreign-invested enterprise who needs a practical, non-legalistic map of both regimes, where they intersect, and what a realistic readiness checklist looks like — not a substitute for qualified PRC legal counsel, but a starting point for the conversation you should be having with one.

MLPS 2.0: What China's Classified Cybersecurity Protection System Actually Requires

China's cybersecurity framework treats "MLPS" — 等级保护, the Multi-Level Protection Scheme, now commonly referred to as MLPS 2.0 after its 2019 update — as the foundational requirement for securing networks and information systems operating inside mainland China. The scheme applies broadly to "network operators," a term that in practice extends well past telecoms and government systems to ordinary corporate IT environments: your ERP system, your internal file servers, your customer-facing website, and your production network can all fall within scope depending on what they do and how much potential impact a security failure would have.

MLPS 2.0 organizes systems into five ascending classification levels, from Level I (minimal impact, largely self-managed) up to Level V (systems affecting national security, subject to the strictest oversight). Most ordinary foreign-invested enterprise systems land in Level II or Level III, depending on factors like whether the system touches critical business operations, handles sensitive data, or would cause significant harm to the company or third parties if compromised. The classification itself is not self-certifying in the way it sounds — determining the correct level typically involves a formal grading exercise, and the result is expected to be filed with the local public security bureau (公安机关) once a system reaches Level II or above.

For systems at Level III and above, the expectation generally extends further: a third-party security assessment (等保测评) conducted by a qualified assessment institution, followed by periodic reassessment as the system or its risk profile changes. The assessment looks at technical controls (network segmentation, access control, intrusion detection, log retention) and management controls (policies, incident response procedures, staff training) together — MLPS compliance is not purely a technology checkbox, it also expects documented processes.

A few misconceptions come up repeatedly with foreign-invested clients. The first is assuming MLPS only applies to state-owned or critical-infrastructure operators — in practice, a private, foreign-owned WFOE running a meaningful IT environment in China is very often a "network operator" for these purposes too, and the obligation to grade and, where applicable, file and assess a system does not depend on ownership structure. The second is assuming that hosting on a major Chinese cloud platform automatically satisfies MLPS for your systems — a cloud platform's own infrastructure can hold its own MLPS certification, but that generally covers the platform layer only; the applications, configurations, and data you run on top of it are typically your own systems for classification purposes, and remain your responsibility to grade, file, and where required, get assessed. The third is treating MLPS as a one-time project — a completed filing and passed assessment reflect a system as it existed at that point in time; meaningful changes to the system, or the passage of a renewal cycle, generally call for reassessment.

Getting MLPS right starts with an honest inventory: which systems exist, what they do, who could be harmed if they failed, and what classification level that points to. From there, managed IT security services and infrastructure partners can help design and operate the technical controls an assessment will look for, but the grading and filing itself is a determination made by (and formally the responsibility of) the operating entity in China.

PIPL and Cross-Border Data Transfer: What Changes When Personal Information Leaves China

Where MLPS is about protecting systems, the Personal Information Protection Law (PIPL), effective since November 2021, is about protecting the personal information those systems hold and process — names, contact details, HR records, customer data, device identifiers, and more. PIPL applies to processing personal information of individuals located in mainland China, and its reach is explicitly extraterritorial: a foreign parent company processing that data from outside China, for purposes like providing services to or analyzing the behavior of individuals in China, can fall within its scope even without a Chinese entity doing the processing directly.

For everyday operations, PIPL requires a valid legal basis for collecting and using personal information — consent is the most commonly relied-on basis for general business use, but PIPL sets a higher bar than a simple accept-all-cookies banner: consent needs to be informed and freely given, and separate, specific consent is generally expected for particularly sensitive processing activities, including most cross-border transfers of personal information. Sensitive personal information — categories like biometric data, health records, financial account details, and precise location data — carries additional obligations around necessity and impact assessment before it is processed at all.

Cross-border transfer is where PIPL creates the most friction for foreign-invested enterprises, because "transfer" is defined more broadly than most companies initially assume. It is not limited to formally exporting a database overseas — it can include an overseas parent company or shared-services team remotely accessing systems that hold personal information located in China, using an overseas-hosted SaaS tool (HR systems, CRM platforms, ticketing systems) that stores or processes China-collected personal information on servers outside mainland China, or routing IT support and monitoring through an offshore team that can view that data. PIPL sets out several recognized mechanisms for lawfully making a qualifying cross-border transfer — a security assessment led by the Cyberspace Administration of China (CAC) for higher-volume or higher-sensitivity transfers, a standard contract (a CAC-published template, filed with the provincial-level CAC office) for many ordinary business transfers, or certification by a recognized professional body — with the specific threshold that determines which mechanism applies depending on factors like data volume, data sensitivity, and the nature of the transferring entity. These thresholds and the accompanying rules have been adjusted more than once since PIPL took effect, including measures aimed at easing compliance burden for lower-risk, smaller-volume transfers, so treat any specific numeric threshold as something to reconfirm against current guidance rather than something fixed.

Before relying on any cross-border mechanism, PIPL generally expects a personal information protection impact assessment (PIPIA) — a documented risk assessment covering what data is being transferred, why, what safeguards are in place at the receiving end, and what the risk to the individuals is — along with a written record retained for a set period. For a foreign-invested enterprise, the practical starting point is mapping exactly which systems, tools, and support arrangements actually move personal information outside mainland China, because that map is very often larger, and less deliberate, than assumed.

Where Foreign Companies Fall Short

In our experience supporting foreign-invested enterprises' IT operations in China, the gaps that create the most exposure are rarely a flat refusal to comply — they are gaps created by assumption, inheritance, or scale.

• Assuming vendor certification equals your own compliance. A cloud provider's MLPS certification, an ISO 27001 badge, or a SOC 2 report from a SaaS vendor are useful signals about the vendor's own security posture, but none of them classify, file, or assess your specific systems and data flows for you — that determination sits with the operating entity using the platform, not the platform provider.
• Never formally classifying internal systems. Many foreign-invested offices run a functioning IT environment for years without ever completing a formal MLPS grading exercise, often because no one owned the question of "what level is our ERP system" in the first place. Without a completed grading, there is no basis to know whether a filing or assessment obligation even applies.
• Treating global HR and CRM tools as compliant by default. A multinational's standard HR platform, CRM, or ticketing system, if hosted outside mainland China, can create an ongoing cross-border transfer of employee and customer personal information every time the China office uses it — a fact that is easy to miss when the tool was selected by global IT, not the local China team, and no one ever asked whether it triggers PIPL's cross-border rules.
• Overlooking IT support and monitoring as a transfer channel. Offshore help-desk or NOC teams that remotely access systems containing China-sourced personal data are, in practice, part of the cross-border data flow — a detail that gets missed when the arrangement is framed purely as "support," not "data transfer."
• No documented PIPIA, even where transfers are happening. Even where a company has quietly relied on the standard-contract mechanism or assumed it qualifies for a lighter-touch exemption, the absence of a written impact assessment is itself a gap if a regulator, auditor, or client due-diligence questionnaire asks for one.
• Assuming a small headcount means no obligation. Office size is not, by itself, the determining factor for either MLPS classification or PIPL's cross-border thresholds — a ten-person representative office running the wrong combination of systems and data flows can still trigger obligations that a much larger, better-segmented operation avoids.
• English-only policies that were never localized. A well-written global data protection policy, if it was never adapted to reference PRC-specific obligations, consent language, and named local responsibilities, generally does not stand in for the PIPL-specific documentation Chinese regulators and counterparties expect to see.

The common thread across all of these is that they are invisible until someone actively looks — an audit, a client's vendor-security questionnaire, a data-breach investigation, or a new contract clause referencing MLPS or PIPL compliance. Foreign companies that get ahead of this treat classification, mapping, and documentation as a standing operational responsibility, not a one-time legal exercise handled once and forgotten.

MLPS (等保) vs PIPL vs Cross-Border Transfer Rules: Where Each One Actually Applies

MLPS, PIPL, and the cross-border transfer rules sitting inside PIPL are frequently discussed as a single topic — "China data compliance" — but they answer different questions, are triggered by different facts, and are enforced through different mechanisms.

MLPS (等保) vs PIPL vs Cross-Border Transfer Rules

• MLPS (等保) — governs the security of network and information systems themselves, regardless of whether personal information is involved; triggered by operating a qualifying system in mainland China; compliance runs through classification/grading, filing with local public security authorities for Level II+ systems, and third-party assessment for Level III+ systems; enforcement generally sits with public security authorities.
• PIPL — governs the processing of personal information generally, whether or not that information ever leaves China; triggered by collecting, using, storing, or otherwise processing personal information of individuals in mainland China; compliance runs through a valid legal basis (typically consent), transparency obligations, data subject rights, and heightened requirements for sensitive personal information; enforcement generally sits with the Cyberspace Administration of China and other competent departments.
• Cross-border transfer rules (within PIPL) — a specific subset of PIPL that governs moving personal information collected or generated in China to recipients outside mainland China, including remote access by an overseas team; triggered by the transfer itself, evaluated against volume and sensitivity thresholds; compliance runs through one of the recognized mechanisms — CAC security assessment, standard contract filing, or certification — plus a documented PIPIA.

MLPS + PIPL Readiness Checklist: What to Confirm Before the Next Audit

• Inventory every system and classify it. List every network and information system running in your China office or China entity, and complete a formal MLPS grading exercise for each rather than assuming a level.
• File and assess where the grading requires it. For systems graded Level II and above, confirm the filing has actually been lodged with the local public security bureau; for Level III and above, confirm a qualified third-party assessment has been completed and is current.
• Map every place personal information physically or logically leaves China. Include SaaS tools hosted overseas, offshore support and monitoring arrangements, group-wide reporting, and any remote access by non-China staff — not just formal data exports.
• Confirm which cross-border mechanism each transfer relies on. Match each mapped transfer to a security assessment, standard contract, or certification, and check whether current volume/sensitivity thresholds still put it in the category you assumed.
• Document a PIPIA for each meaningful transfer and high-risk processing activity. Keep it on file and refresh it when the transfer's scope, volume, or recipient changes.
• Localize consent language and privacy notices. Confirm data subjects in China are given PIPL-compliant notice and, where required, separate consent — not just a translated version of a global privacy policy.
• Name an accountable owner inside the China entity. PIPL expects certain organizations to designate a person responsible for personal information protection matters; even where a formal appointment threshold isn't clearly met, having a named internal owner makes every other item on this list actually executable.
• Review vendor and MSP contracts for MLPS and PIPL-relevant clauses. Confirm your IT vendor's contract addresses data-handling standards, subcontractor disclosure, and support for classification and assessment work, not just uptime and response times.
• Revisit the whole picture on a set cadence. Treat classification, filing status, and cross-border mapping as living information that needs review at renewal, whenever a system or vendor changes, and at least annually regardless.
• Get current pricing and scope for compliance-capable IT support in writing. Compare it against a cheaper alternative that may be silent on MLPS assessment support or cross-border data handling — see current published rates for a like-for-like baseline.

Who Should Own This: In-House IT, Your MSP, or Both

MLPS and PIPL readiness is not purely a legal question, and it is not purely a technical one either — which is exactly why ownership tends to fall through the cracks between departments. A workable model splits responsibility along three lines.

Legal and compliance ownership sits with the China entity itself. Only the operating entity can formally lodge an MLPS filing, hold the relationship with the local public security bureau, or bear ultimate PIPL accountability as the entity determining why and how personal information is processed. No IT vendor, however capable, can stand in for the entity on questions that are inherently legal and organizational — appointing a responsible person, approving a privacy notice, deciding whether a transfer is necessary in the first place.

Technical execution is where a capable MSP earns its place. Classifying systems correctly requires someone who actually understands the network architecture, data flows, and access model — often better documented by the team running day-to-day infrastructure than by an internal generalist administrator juggling other priorities. The same is true of implementing the access control, encryption, logging, and monitoring an MLPS assessment will actually test, and of building the kind of IT infrastructure deployment and managed IT and cloud services foundations that make classification and cross-border mapping tractable rather than a multi-month forensic exercise.

Coordination is the piece most foreign-invested offices underinvest in. Legal counsel can advise on obligations; IT can implement controls — but someone needs to sit between the two, translating "PIPIA needed for this transfer" into an actual system inventory, and translating "this system needs network segmentation" into a change that legal and the business understand the purpose of. In smaller offices, this coordinating role often falls to whoever is closest to both — frequently the IT lead or an ops manager — supported by an MSP that is used to operating inside this specific regulatory context rather than a generic global support desk unfamiliar with MLPS or PIPL by name.

The mistake we see most often is one department assuming the other has it covered: legal assuming IT has already classified every system, IT assuming legal has already confirmed which cross-border mechanism applies, and both assuming the global compliance team back at headquarters has it handled for the China entity specifically. It generally has not, because MLPS and PIPL obligations attach to the China entity and its systems specifically, not to the parent company's global compliance program. If you are not sure who currently owns this inside your organization, that uncertainty is itself the first finding to fix — and a good place to start is a straightforward conversation about your current environment; get in touch if you would like to map your systems and data flows against this checklist.

Frequently Asked Questions

Does MLPS apply to small representative offices, or only large operations?

Office size alone is not the determining factor. MLPS applies based on the systems a network operator runs and the potential impact if those systems were compromised, not on headcount — a small office running customer-facing infrastructure or handling sensitive data can still reach a classification level that carries filing or assessment obligations, while a larger office running only low-impact internal tools might land at a lower level. The only reliable way to know is to complete a formal grading exercise for the systems you actually run, rather than assuming size settles the question.

What actually counts as a "cross-border transfer" of personal information under PIPL?

More than most companies initially expect. Beyond an obvious data export, it generally includes an overseas parent company or shared-services team remotely accessing systems holding China-collected personal information, storing or processing that data through an overseas-hosted SaaS tool, and routing IT support, monitoring, or ticketing through an offshore team that can view the data. If personal information collected or generated in China becomes accessible to a person or system outside mainland China, treat that as a transfer worth evaluating against PIPL's cross-border mechanisms, rather than assuming "we didn't export a file" settles the question.

What happens if a company doesn't comply with MLPS?

Consequences can range from warnings and orders to rectify within a set timeframe, through fines, to more severe measures such as suspension of the relevant systems or business activities in serious or repeated cases — the specific consequence depends on the classification level involved, the nature of the shortfall, and how enforcement is applied in practice. Because the applicable penalty framework and how it is applied can change, treat any specific figure you encounter as something to confirm against current guidance and, for anything material, with PRC legal counsel, rather than relying on a number from an older source.

Can our MSP handle the MLPS filing on our behalf?

An MSP can do a substantial amount of the supporting work — helping classify systems, implementing the technical and management controls an assessment will test, and preparing documentation — but the formal filing is generally lodged by the operating entity itself with the local public security bureau, since it is the entity, not the vendor, that is the registered "network operator." Think of a capable MSP as the team that gets you ready to file and be assessed successfully, not as a substitute for the entity's own filing responsibility.

How often does an MLPS assessment need to be renewed?

Expectations vary by classification level and by local enforcement practice, but systems at Level III and above are commonly expected to undergo assessment on a recurring basis, with lower-level systems reviewed less frequently. Beyond any fixed cadence, a meaningful change to a system — a new architecture, a significant new data flow, a security incident — is generally a trigger to reassess regardless of where you are in the renewal cycle. Confirm the specific expected cadence for your systems' classification level with your assessment institution or legal counsel, since local practice can vary.

If we host on Alibaba Cloud or Tencent Cloud, does that automatically satisfy MLPS for us?

No, not on its own. A major Chinese cloud platform can hold its own MLPS certification for its infrastructure layer, and that is a genuinely useful foundation — but the applications, configurations, access controls, and data you run on top of that infrastructure are generally your own systems for classification purposes, and remain your responsibility to grade, file where required, and get independently assessed. Hosting on a certified platform reduces some of the underlying risk; it does not substitute for your own classification and filing.

Getting MLPS and PIPL Compliance Right, Not Just Documented

None of this is about achieving a perfect, static state of compliance — MLPS classifications, PIPL's cross-border mechanisms, and the thresholds attached to both have changed more than once since these frameworks took effect, and will likely change again. What holds up over time is a habit: knowing what systems you run, knowing where personal information actually goes, keeping the paperwork current, and having a named owner who can answer both questions without a scramble. Whether you are setting up IT for a new China office or reviewing an environment that has run for years without a formal MLPS grading exercise, walk through the checklist above system by system rather than treating it as a one-time compliance sprint. Pair that discipline with infrastructure built to support it — managed IT security services, properly deployed IT infrastructure, and a support partner who understands MLPS and PIPL by name rather than as generic "China compliance" — and you are working from a materially stronger position than documentation alone would suggest. If you would like to map your current systems and data flows against this checklist, get in touch and we can work through your specific environment.

This guide provides general, practical compliance information and is not legal advice. MLPS and PIPL obligations, including classification thresholds, cross-border transfer mechanisms, and applicable penalties, depend on your organization's specific systems, data flows, and risk profile, and are subject to change; confirm anything material with qualified PRC legal counsel before relying on it.