China Cybersecurity Law compliance: what most organizations get dangerously wrong
Amara OkaforApril 29, 2026
TL;DR
The dominant compliance effort goes into data localization. Vulnox assessment data from 2024 shows CAC enforcement actions cluster instead around log usability failures and incorrect MLPS 2.0 level assignments — not where data sits.
48% of internet-facing systems inside CII-designated organizations run outdated OpenSSL versions, directly breaking the integrity of the logs Article 21 requires them to keep. The retention box is ticked; the logs are unusable.
MLPS 2.0 level under-scoping is the most common finding we see. Organizations self-classify systems at Level 2 when the regulatory criteria clearly mandate Level 3, cutting their required control set roughly in half and leaving them exposed to enforcement.
Cross-border transfer approvals are treated as a legal formality. Regulators increasingly conduct technical verification against the submitted risk assessment — and the two rarely match.
A structurally inevitable compliance failure is building in mid-market SaaS companies serving Chinese enterprise customers: they will face simultaneous CAC enforcement and EU GDPR conflict over the same data set, with no legal mechanism to satisfy both.
The counterintuitive finding: organizations with the largest dedicated compliance teams show worse actual control implementation than lean teams using continuous automated validation. Process overhead crowds out technical remediation.
The breach that compliance was supposed to prevent
A European industrial automation company, around 800 employees, had been operating in China for eleven years. They had a local data center, a designated cybersecurity representative, a signed-off MLPS 2.0 assessment at Level 2, and an annual third-party audit. By every internal metric, they were compliant. When the CAC initiated a post-incident review following a supplier network compromise, investigators asked for six months of DNS query logs from the internal resolver. The security team went to pull them. The logs existed — technically. They were stored in an unindexed flat-file format on a server that had not been patched since 2021. Extracting a 72-hour window took four days. The CAC found this unacceptable under Article 21 and initiated a formal penalty process, not for lacking logs, but for maintaining logs that were operationally useless.
The company had built its entire compliance posture around the assumption that China Cybersecurity Law compliance was fundamentally about where data lives. It is not. The CAC cares deeply about whether you can demonstrate control — and control means being able to produce, query, and act on your own security data within a timeframe that matters. That company spent 14 months and significant legal fees learning a lesson that should have been obvious from reading Article 21 carefully.
The myth: CSL compliance is a data localization problem
The myth
The reality
What the numbers actually show
48%
Percentage of internet-facing systems inside CII-designated organizations running outdated OpenSSL versions, based on Vulnox assessment data, 2024. These systems generate the logs Article 21 requires. An outdated OpenSSL version means the integrity of those logs cannot be cryptographically verified — which is exactly what a CAC forensic review will attempt to do.
22%
Percentage of assessed organizations storing sensitive Chinese customer data in unencrypted format on MLPS 2.0-covered systems, Vulnox assessment data, 2024. The organizations involved had documented encryption policies. The policies and the actual configuration were disconnected.
3 of 4
Ratio of organizations that self-assigned an MLPS 2.0 Level 2 classification to systems that Vulnox independently assessed as meeting Level 3 criteria. Under-scoping is not random — it consistently goes in one direction, Vulnox assessment data, 2024.
Larger compliance teams produce worse technical outcomes
Common belief
The intuitive assumption is that organizations with dedicated compliance functions — a CISO, a compliance manager, local legal counsel, external auditors — will have stronger actual security posture than lean teams treating compliance as a part-time function.
What we found
In Vulnox engagements where we conducted blind technical validation after a formal third-party audit, we found that 61% of findings marked as remediated in the audit report were not remediated in the actual environment, Vulnox assessment data, 2024. Lean teams using automated continuous validation showed a remediation confirmation rate above 80%. The mechanism is straightforward: continuous tooling closes the feedback loop that human audit cycles leave open for 11 months.
What we found runs the other way. Organizations with large compliance teams tend to concentrate effort on documentation, policy maintenance, and audit preparation. The compliance function becomes a full-time job producing artifacts — gap analyses, risk registers, evidence packages — while the technical remediation work is delegated to an IT team that is already overloaded and receives a list of findings with no prioritized implementation sequence. The compliance team considers a finding closed when the policy is updated. The IT team considers it closed when they get through the queue. These are different timelines, and no one is accountable for the gap between them.
What we actually find when we look closely
Assessment base: Vulnox assessment data, 2024, covering organizations operating under China Cybersecurity Law and MLPS 2.0 obligations across manufacturing, financial services, and technology sectors.
MLPS level under-scoping is systematic, not accidental
In our 2024 assessments of organizations with established MLPS 2.0 compliance programs, three out of four had at least one system classified at Level 2 that met the regulatory criteria for Level 3 designation. The criteria are not ambiguous — Level 3 applies to systems where a breach would harm social order or public interest. When we walked clients through the classification logic, the response was consistently that their previous assessors had told them Level 2 was sufficient. The under-scoping reduces the required control set by roughly half, which means these organizations are running Level 2 controls on systems that require Level 3 protections. CAC enforcement is catching up to this pattern.
Log retention and log usability are treated as the same requirement — they are not
Article 21 of the CSL specifies a six-month minimum log retention period. Organizations read this as a storage requirement and implement it as one. What we find in practice is that the logs are retained but not indexed, not structured for query, and in several cases stored on systems that themselves fall outside the scope of security monitoring. In one assessment of a 1,200-person manufacturing company, we were able to retrieve DNS query logs covering the required period but could not execute a simple host lookup across those logs without writing custom extraction scripts. A CAC investigator asking for evidence of specific activity during an incident would receive the same experience. This is the failure mode that triggers enforcement — not missing logs, but inoperable ones.
Cross-border transfer risk assessments do not match actual data flows
The Measures on Security Assessment for Outbound Data Transfers require organizations to submit a risk assessment documenting what data crosses the border, under what conditions, and what safeguards apply. What we find when we map actual outbound data flows against the submitted assessments is a significant gap — on average, around 30-40% of actual cross-border data flows involve data categories or recipient systems not covered in the filed assessment, Vulnox assessment data, 2024. This happens because the assessment is prepared once by legal and compliance staff, and the technical architecture continues evolving. No one owns the reconciliation between the filed document and current reality.
How CAC enforcement actually works
Most organizations model CAC enforcement as a scheduled audit event — something that happens annually, involves documentation review, and produces a pass or fail. This model is increasingly wrong. CAC enforcement in practice triggers from three sources: post-incident reviews initiated by the CAC itself after a reported breach, complaint-driven investigations initiated by third parties, and data-flow monitoring conducted by authorized technical agencies. The last category is the one organizations systematically underestimate. CAC-authorized technical agencies conduct passive monitoring of outbound data flows from Chinese networks. Organizations that believe their cross-border transfer approval covers all outbound activity are working from a static picture of a dynamic system.
Example
In a post-incident review we supported for a technology company following a credential compromise, the CAC investigator arrived with a list of outbound connection events to non-Chinese IP ranges that the company had not documented in its cross-border transfer assessment. The company had approved transfers of customer data to its EU data center for processing. What the investigator had evidence of was telemetry data — system performance metrics — flowing to a US-based SaaS monitoring tool. That tool had been adopted by the engineering team without going through the transfer assessment process. The company's legal position was that telemetry data did not constitute personal information under the PIPL and therefore did not require assessment. The CAC's position was that the data flow had not been disclosed and therefore could not be evaluated. The disagreement took 18 months to resolve.
The technical mechanism underlying this enforcement pattern is that Chinese network infrastructure — at the carrier and IXP level — provides monitoring capability to authorized agencies that is independent of what organizations self-report. Organizations that assume their compliance exposure is limited to what they disclose are operating on a false premise.
What clients tell us before we look at the environment
'We passed our MLPS 2.0 assessment last year. We have the certificate. Why do we need to do anything else?'
Root cause:MLPS 2.0 certification is a point-in-time assessment of a specific scope, conducted against criteria that the assessor and the organization define together. Certificates are issued for three-year periods. In practice, the technical environment changes continuously — new systems are deployed, existing systems are modified, third-party integrations are added. The certificate does not update. Organizations treat the certificate as a compliance state when it is actually a compliance snapshot. The snapshot degrades from the moment it is taken, and the CAC does not care about the date on the certificate during an enforcement action.
'Our data never leaves China. We use a local cloud region. We should not have cross-border transfer obligations.'
Root cause:The data residency assumption breaks down at the application layer. Local cloud storage does not mean local data processing. In most enterprise environments, monitoring tools, identity providers, ticketing systems, and development platforms are global SaaS products with data processing infrastructure outside China. Logs, authentication events, incident tickets, and code repositories frequently contain personal information of Chinese users or employees — and those data categories flow to non-Chinese systems as part of normal operations. The 'data never leaves China' claim is almost never technically accurate once you trace actual application data flows rather than storage locations.
'We have encryption. Our data is protected.'
Root cause:In 22% of assessed organizations, Vulnox found sensitive customer data stored in unencrypted format on MLPS 2.0-covered systems despite documented encryption policies, Vulnox assessment data, 2024. The encryption policy existed. The encryption was not implemented consistently. This gap between documented control and actual implementation is the most common single finding across our China-focused assessments. Encryption at rest requires not just a policy and a tool but a deployment verification process that runs continuously, not at audit time.
Where compliance programs consistently stop looking
Engineering toolchain data flows
CI/CD pipelines, code repositories, issue trackers, and monitoring platforms are almost never included in cross-border transfer assessments. These systems routinely process data from Chinese user accounts, contain employee personal information, and route telemetry through non-Chinese infrastructure. Because they are engineering tools rather than customer-facing systems, the compliance team typically does not own them and the engineering team does not think of them as a compliance matter. This is structurally where the unassessed outbound flows live.
Backup and disaster recovery infrastructure
Backup systems are scoped out of MLPS 2.0 assessments more often than any other infrastructure category. The reasoning is that backup systems do not process data — they store it. This reasoning is incorrect. Backup infrastructure that stores personal information of Chinese citizens is subject to the same data localization and security requirements as primary systems. Organizations that maintain cross-border backup replication for business continuity are frequently running undisclosed cross-border data transfers on an automated, continuous basis.
Supplier and partner network access
CII operators have obligations that extend to their supply chains, but in practice, supplier cybersecurity requirements are documented in contracts and not verified technically. We consistently find active VPN credentials belonging to suppliers who no longer work with the organization, supplier accounts with access to systems well beyond what their engagement scope requires, and no monitoring of supplier network activity against a baseline. A compromise originating through a supplier — which is increasingly the dominant breach pattern globally — would trigger Article 31 review of the CII operator, not the supplier.
CSL versus GDPR and PIPL: where they conflict and what to do
GDPR grants data subjects rights including erasure and portability that require data controllers to respond to requests, often by accessing, modifying, or deleting data that may be stored in China. CSL and PIPL impose data localization requirements that restrict moving that data to execute on erasure or portability requests. The conflict is not theoretical — a Chinese resident who is also an EU citizen, or whose data is held by an EU-regulated entity, can generate a GDPR request that the organization literally cannot fulfill without potentially violating Chinese law. There is no published resolution mechanism for this conflict.
Organizations operating under both regimes need a legal assessment of which regulatory obligation takes precedence in their specific fact pattern before a request arrives, not after. The answer depends on the nationality of the data subject, the location of processing, and the corporate structure of the controller. Waiting for the first conflict to develop an approach means resolving it under enforcement pressure from at least one regulator.
ISO 27001 is a management system standard — it certifies that an organization has a documented, implemented, and audited information security management process. MLPS 2.0 is a technical baseline standard — it specifies mandatory controls at each protection level. ISO 27001 certification does not satisfy MLPS 2.0 requirements and is not recognized as equivalent by Chinese regulators. Organizations that have invested heavily in ISO 27001 certification often assume significant control overlap. The overlap is real but partial — MLPS 2.0 includes mandatory requirements around network architecture, access control specifics, and incident reporting timelines that ISO 27001 does not mandate.
ISO 27001 is useful evidence of process maturity during a CAC engagement but is not a substitute for MLPS 2.0 certification. Organizations should maintain both independently and should not use ISO 27001 scope to define their MLPS 2.0 scope, as the system classification criteria are different.
NIST SP 800-92 provides detailed guidance on log management including collection, normalization, storage, and analysis. CSL Article 21 specifies retention period (six months minimum) and general categories of events but does not specify technical implementation. The gap means organizations applying NIST guidance to satisfy Article 21 are likely technically over-compliant on log management process but may miss the specific event categories Chinese regulators expect — particularly around network perimeter events, user authentication, and administrative actions on CII systems.
Map Article 21 required event categories explicitly against your log collection scope. Do not assume that a NIST-compliant log management program covers the specific evidence categories a CAC investigator will request. The two have different emphases.
A remediation sequence that actually holds
Step 3 — the network-first data flow mapping — is the one organizations consistently skip because it requires coordination between legal, compliance, and engineering teams, and none of those functions naturally owns the full exercise. The result is a cross-border transfer assessment that legal considers complete and engineering considers irrelevant, with no one responsible for the gap between them.
- 1Security architecture team
Map every system against MLPS 2.0 Level 3 criteria before assuming Level 2. The question is not 'what level did we assign' but 'does this system, if compromised, affect social order, public interest, or national security in any plausible scenario.' Document the reasoning, not just the conclusion. This documentation is what a CAC reviewer will evaluate.
Expected outcomeAccurate scope definition for MLPS 2.0 controls. Most organizations will find at least one system requires reclassification upward. Finding this before an assessment is orders of magnitude cheaper than finding it during one.
- 2Security operations team
Validate log usability, not just log retention. For every log source within MLPS 2.0 scope, run a test query: given a specific host and a 30-minute window from 90 days ago, how long does it take to produce a complete activity record? If the answer is more than four hours, you have a usability problem regardless of your retention policy.
Expected outcomeIdentification of logging infrastructure gaps before an enforcement-driven review creates them. This exercise also frequently surfaces log sources that exist in policy but are not actually being ingested — a finding that has concrete enforcement implications.
- 3Legal and technical team jointly
Conduct a data flow mapping exercise that starts from the network, not from the application inventory. Use passive network monitoring to identify actual outbound connections over a 30-day period. Map those connections against the filed cross-border transfer assessment. Every connection not covered by the assessment is a potential undisclosed transfer.
Expected outcomeA reconciled cross-border transfer assessment that reflects actual technical architecture. This is the exercise that surfaces engineering toolchain data flows, SaaS monitoring tools, and backup replication — the three categories most consistently absent from filed assessments.
- 4IT and security operations
Implement continuous configuration validation for encryption at rest across all MLPS 2.0-scoped systems. This means automated daily checks against expected configuration state, not policy attestation. When a system is provisioned or modified, encryption configuration should be verified automatically and any deviation should trigger a remediation ticket with a defined SLA.
Expected outcomeClosure of the gap between documented encryption policy and actual implementation state. Based on Vulnox assessment data, this single control closes the most common finding we see in China-focused assessments.
Where this is going
CAC will begin conducting technical verification of cross-border transfer assessments as a routine pre-approval step, not just during post-incident reviews. Organizations that submit static legal documents describing dynamic technical architectures will face assessment rejections at filing rather than enforcement actions after breach.
CAC enforcement capacity has been building since 2022. The pattern we see in post-incident reviews — where investigators arrive with independent network monitoring evidence — suggests this capability exists and is being applied reactively. The logical next step is applying it proactively during the approval process. Several recent CAC guidance documents signal closer technical scrutiny of transfer assessment submissions.
Confidence: highFirst publicly reported case of a CAC cross-border transfer assessment rejection citing a discrepancy between the submitted data flow description and technical monitoring evidence. This would confirm the capability is being applied proactively.Within three years, a mid-market SaaS company serving Chinese enterprise customers will face simultaneous enforcement from CAC and a European data protection authority over the same data set, with no legally available path to satisfy both. This will be the case that forces a regulatory dialogue between the EU and China that neither side currently wants to initiate.
The structural conditions exist now. A SaaS company with EU headquarters and Chinese enterprise customers holds data subject to GDPR (EU data subjects or EU-regulated controller) and PIPL/CSL (Chinese user data, Chinese network infrastructure) simultaneously. A GDPR erasure request for data stored in China, combined with a CAC requirement to retain that data for six months post-incident, produces a legal deadlock. The only reason this has not yet produced a high-profile enforcement case is that data protection authorities on both sides have not yet focused investigation resources on the same target simultaneously.
Confidence: mediumA published enforcement decision from either the CAC or a European DPA that explicitly references the conflict with the other jurisdiction's requirements. Even a preliminary finding would confirm the collision is being taken seriously by at least one enforcement body.
My actual view on where the compliance industry fails here
Opinion: the China Cybersecurity Law compliance market is producing a generation of organizations that are more confident about their compliance posture than the evidence supports, and the certification infrastructure is part of the reason why. MLPS 2.0 certification is sold as a compliance solution. It is a diagnostic at a moment in time. The organizations spending significant budget on annual third-party audits and arriving at clean reports are, in a meaningful number of cases, the same organizations we find with 48% of their CII systems running outdated cryptographic libraries. The audit found what the audit was designed to find. The ongoing technical reality was not something the audit was designed to track. I think the compliance-as-certification model is structurally wrong for a regulatory regime that imposes continuous obligations. You cannot satisfy Article 21 once a year. You satisfy it continuously or you do not satisfy it.
Where to start
The most valuable single action most organizations can take right now is the log usability test described in step 2 of the prevention sequence. Pick a specific host, pick a 30-minute window from 90 days ago, time how long it takes to produce a complete activity record from your logging infrastructure. That number tells you more about your actual China Cybersecurity Law compliance posture than any audit report sitting in your compliance folder. If the answer is hours rather than minutes, you have found the gap that enforcement finds first — and you have found it before enforcement does.
Further Reading
Gap Analysis
framework gap analysisDigital Footprint
digital footprint analysisNVD Vulnerabilities Database
National Vulnerability DatabaseNIST Cybersecurity Framework 2.0
NIST Cybersecurity FrameworkOWASP Methodology Security Testing
OWASP security testing methodology
Frequently Asked Questions
What does CAC actually look for during a post-incident review under the China Cybersecurity Law?
Based on Vulnox-supported post-incident reviews, CAC investigators focus on three things: whether you can produce queryable logs covering the incident window, whether your MLPS 2.0 classification reflects the actual sensitivity of the affected systems, and whether any outbound data flows during the incident period were covered by a filed cross-border transfer assessment. They arrive with independent network monitoring evidence and compare it against your documentation. The gap between what you filed and what the network shows is where enforcement action originates.
How do I know if my systems are classified at the right MLPS 2.0 level?
Apply the Level 3 criteria first, not last. Level 3 applies where a system breach could harm social order, public interest, or national security. Vulnox assessment data from 2024 shows three out of four organizations with established MLPS 2.0 programs had at least one system classified at Level 2 that met Level 3 criteria. The test is not what your previous assessor concluded — it is whether a reasonable reading of the criteria produces a different answer. Document your reasoning for each system classification, because that documentation is what a CAC reviewer evaluates.
We use a Chinese cloud region. Does that mean we have no cross-border transfer obligations?
Almost certainly not. Data residency covers storage location, not processing location. In practice, most enterprise environments route monitoring telemetry, authentication events, development platform activity, and support tickets through global SaaS tools with infrastructure outside China. These flows frequently contain personal information of Chinese users or employees. Vulnox data flow mapping exercises consistently find that 30-40% of actual outbound data flows involve categories not covered in the organization's filed cross-border transfer assessment, Vulnox assessment data, 2024.
Does ISO 27001 certification satisfy MLPS 2.0 requirements?
No, and Chinese regulators do not treat it as equivalent. ISO 27001 certifies a management system process. MLPS 2.0 mandates specific technical controls at each protection level — network architecture requirements, access control specifics, and incident reporting timelines that ISO 27001 does not prescribe. ISO 27001 is useful evidence of process maturity during a CAC engagement, but organizations should maintain MLPS 2.0 certification independently and should not use their ISO 27001 scope to define their MLPS 2.0 scope.
What is the most common finding in Vulnox China Cybersecurity Law assessments?
The gap between documented encryption policy and actual encryption implementation. In 22% of assessed organizations, Vulnox found sensitive Chinese customer data stored in unencrypted format on MLPS 2.0-covered systems despite documented encryption policies, Vulnox assessment data, 2024. The policy existed. The technical control did not. Closing this requires continuous automated configuration validation, not policy maintenance.
How does China Cybersecurity Law interact with GDPR for companies operating in both jurisdictions?
There is a structural conflict with no published resolution mechanism. GDPR erasure and portability rights may require accessing or moving data stored in China, which CSL and PIPL restrict. A Chinese resident who is also an EU data subject, or whose data is held by an EU-regulated controller, can generate a GDPR request that the organization cannot fulfill without potentially violating Chinese law. Organizations operating under both regimes need a legal assessment of precedence before a conflict arrives — resolving it under enforcement pressure from one regulator while the other is watching is significantly more expensive.
How often do we need to update our cross-border data transfer assessment under the CSL?
The Measures on Security Assessment for Outbound Data Transfers do not specify a fixed update interval, but the practical answer is: every time your technical architecture changes in a way that adds new outbound data flows or new data categories. Given that engineering teams continuously adopt new SaaS tools, monitoring platforms, and third-party integrations, the assessment requires active ownership — not one-time filing. Vulnox recommends a quarterly reconciliation of actual outbound network flows against the filed assessment scope, using passive network monitoring rather than application inventory review.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.