China DJCP incident reporting: what the CAC actually checks
Julian ThorneApril 29, 2026
Key takeaways
DJCP incident reporting requires CAC notification within 1 hour for Grade 4-5 critical infrastructure incidents — not the 2-hour window commonly cited in English-language summaries.
CAC investigators during post-incident audits consistently request evidence of the detection-to-notification chain, not just the final report. Organizations that cannot reconstruct this timeline face secondary penalties.
In Vulnox assessments of foreign-operated entities in China, over 60% had incident classification matrices that did not map to DJCP severity definitions — meaning they would misfile a reportable incident as internal-only.
The DJCP framework requires simultaneous notification to CAC, MIIT, and in some cases MPS. Most incident response playbooks only document the CAC pathway.
A DJCP-compliant incident report must include a root cause determination, not just an impact statement. Submissions that omit root cause are routinely rejected and trigger re-investigation timelines.
Shadow IT assets and unregistered subdomains are the most common source of first-contact breach vectors in China-assessed environments — and the hardest to include in post-incident reporting because they were never in the asset inventory.
TL;DR
China DJCP incident reporting is not a filing exercise. CAC investigators treat the post-incident audit as a second assessment — and they are specifically looking for gaps between what the notification claimed and what the evidence chain shows. Foreign-operated companies consistently fail this because they document the incident response they ran, not the one the regulation requires. The fix is architectural, not administrative.
The notification that passed review and then triggered an investigation
A 200-person SaaS company operating in Shanghai filed a DJCP incident report within the required window after detecting unauthorized access to a customer data segment. The notification was on time. The format was correct. The Chinese was clean. Six weeks later, CAC investigators requested the full detection-to-containment timeline, the asset inventory as it existed on the date of the incident, and evidence that the affected systems had been registered under the correct MLPS protection level. The company could produce the first. It could not produce the second or third. The incident had originated from a subdomain that had been provisioned 14 months earlier and never entered into the asset register. The formal report had described the breach accurately but had mapped it to the wrong system classification — which meant the notification timeline the company had hit was not, in fact, the applicable one.
The company had treated DJCP incident reporting as a communications process. CAC treated it as an evidentiary process. Those are not the same thing, and the gap between them is where most foreign-operated entities get into trouble.
How DJCP incident classification actually works — and where the definitions diverge from what most teams assume
DJCP incident classification runs along two axes that most English-language summaries collapse into one. The first axis is system classification: the MLPS protection level of the affected system, which ranges from Grade 1 to Grade 5. The second axis is incident severity: general, significant, or major, defined by impact scope, data volume affected, and whether critical infrastructure availability was impaired. The notification timeline is determined by the intersection of both axes, not by severity alone. A major incident on a Grade 2 system has a different notification requirement than a significant incident on a Grade 4 system. Most foreign-operated companies build their incident response playbooks around severity level only. That produces correct timelines in roughly half the scenarios and wrong ones in the other half.
Example
The 1-hour CAC notification requirement applies to incidents classified as major on systems at Grade 4 or Grade 5 — these are typically critical information infrastructure operators. The 2-hour window that appears in most summaries applies to significant incidents on lower-classified systems. The distinction matters because an organization that has classified its systems incorrectly under MLPS will also calculate the wrong notification window. Vulnox assessment data from 2024 shows that among foreign-operated entities assessed in China, system classification records were outdated or missing for an average of 31% of in-scope assets.
The underlying regulation is the Measures for Cybersecurity Incident Reporting, effective December 2023, which operationalizes incident reporting obligations under both the Cybersecurity Law and the Data Security Law. The measures introduced mandatory simultaneous reporting to sector-specific regulators in addition to CAC — a requirement that was not clearly articulated in earlier guidance and that most pre-2024 incident response playbooks do not reflect.
What the data shows from assessed environments
Assessment base: Vulnox gap analysis and vulnerability assessment engagements, 2023-2024, covering foreign-operated entities subject to DJCP across financial services, SaaS, and manufacturing sectors.
Incident classification matrices disconnected from DJCP definitions
In gap analysis engagements covering foreign-operated entities subject to DJCP, Vulnox found that the majority had incident classification tiers built around internal severity definitions — typically low, medium, high, critical — that did not map to the DJCP tripartite structure of general, significant, and major. Teams were triaging correctly by their own standards and misfiling by regulatory standards. In several cases, incidents that would have triggered mandatory CAC notification under DJCP were handled as internal events.
The client assumption in every case was that their IR team was DJCP-aware. The actual finding was that awareness of the framework did not translate to operational alignment. Knowing what the framework says and having a runbook that produces a DJCP-compliant response are different things.
Asset inventory gaps that invalidate post-incident reporting
Post-incident reports filed with CAC are required to identify the affected system and its MLPS classification level. In assessed environments, an average of 31% of externally accessible assets had not been entered into the formal asset register — primarily subdomains, third-party integrations, and systems provisioned by business units outside the IT function. When an incident originates from or affects one of these unregistered assets, the post-incident report either omits it or misclassifies it.
CAC investigators cross-reference post-incident reports against the organization's previously filed MLPS registration records. A breach that involves an unregistered system does not just create a reporting problem — it creates a separate compliance failure around system registration that investigators will pursue independently.
Multi-agency notification workflows that exist on paper only
The December 2023 Measures require notification to sector regulators in parallel with CAC, with MIIT and MPS involvement for specific incident categories. In assessed environments, incident response runbooks documented the CAC notification path in detail and treated MIIT and MPS notification as a secondary step to be handled after the primary report. Regulators do not share that sequencing. Both agencies expect contemporaneous notification for qualifying incidents.
Organizations that file with CAC on time and MIIT a day later have not met the requirement. The gap is not a minor procedural issue — parallel notification failures are specifically flagged in post-incident audit findings.
Root cause documentation missing from initial notifications
DJCP-compliant incident notifications for significant and major incidents must include a preliminary root cause determination, even in the initial filing. The final report can supplement or correct this, but the initial notification cannot be silent on cause. Assessed environments consistently produced initial notifications that described impact and containment actions without a cause statement, because their IR templates had been built around Western breach notification models where cause determination follows after investigation.
CAC returns notifications that lack cause statements as incomplete, which resets the compliance clock. The organization is then simultaneously managing an active incident, a re-notification deadline, and a gap in the investigation that now has regulatory visibility.
The incident that does not look reportable is often the one that creates the most regulatory exposure
Common belief
Most DJCP-focused teams allocate their preparation effort toward major incidents — large data breaches, infrastructure outages, ransomware. The assumption is that general incidents are low-stakes from a regulatory perspective, and that building the capability to handle major incidents covers everything below it.
What we found
In Vulnox assessments, the incidents that created the largest compliance gap were not the ones organizations had war-gamed. They were mid-severity events handled entirely within the SOC, documented in internal ticketing systems, and never reviewed against DJCP classification criteria.
This produces the wrong risk prioritization. General incidents are not low-stakes — they are high-frequency. And they are the category where classification errors are most likely, because the severity is ambiguous and the decision happens at the analyst level rather than being escalated to the IR lead. A general incident that is actually a significant one under DJCP definitions — because it involves personal data of more than 100,000 individuals, for example — will be handled without CAC notification, without documentation to regulatory standards, and without the parallel agency coordination the framework requires. When CAC investigators review the post-incident record during an audit, a misclassified significant incident looks like a concealed one.
What organizations say before the assessment and what the root cause actually is
'We have a DJCP-compliant incident response plan. Our legal team reviewed it.'
Root cause:Legal review confirms that the plan references the correct regulations. It does not confirm that the operational steps produce DJCP-compliant outputs under realistic incident conditions. The two things that consistently fail under actual incident conditions are the multi-agency notification workflow and the root cause documentation requirement — both of which look fine in a document and break down when the IR team is managing an active event at 2am with partial information.
'Our MLPS filing is current. We had it certified last year.'
Root cause:MLPS certification covers the systems that were in scope at the time of filing. Organizations in growth mode provision new systems, onboard new third-party integrations, and expand their cloud footprint continuously. Certification does not update automatically. The average gap between an organization's current external attack surface and its MLPS registration record grows at roughly the same rate as the organization's infrastructure — and the assets that fall outside the registration are disproportionately likely to be the entry points in a breach, because they are the ones that received the least security attention.
'We report to our sector regulator. That covers the DJCP obligation.'
Root cause:Sector regulator notification satisfies the sector requirement. It does not satisfy the CAC notification requirement, which is a parallel obligation under the Cybersecurity Law. The December 2023 Measures made this explicit, but organizations that built their IR programs before that guidance are running on an outdated model. The sector-only approach was arguably sufficient under pre-2023 guidance. It is not sufficient now.
Structural gaps that most DJCP incident response programs do not address
Detection-to-notification evidence chain
CAC post-incident audits do not just review the notification document. Investigators reconstruct the timeline from detection through containment and ask for log evidence at each stage. Organizations that cannot produce contemporaneous evidence of when an incident was detected, when it was classified, and when notification decisions were made have a documentation failure that is independent of whether the notification itself was correct. Building DJCP-compliant incident response means instrumenting the response process, not just the report.
Cross-border data flow implications
When an incident involves data that has been transferred cross-border under a Security Assessment approval or Standard Contract, the incident report must address the cross-border flow dimension separately. CAC will evaluate whether the breach affected data covered by an approved transfer mechanism and whether the transfer mechanism itself contributed to the exposure. Organizations handling cross-border transfers often treat DJCP incident reporting and cross-border data governance as separate compliance streams. They are not separate when an incident occurs.
Third-party and supply chain incident attribution
If an incident originates at a third-party supplier or SaaS provider and affects the organization's systems or data, the organization retains the notification obligation. The third party's own notification to its regulator does not satisfy the operator's obligation. In practice, organizations with mature vendor risk programs still have incident response playbooks that are written entirely around first-party breaches. Supply-chain-originated incidents fall into a procedural gap where the IR team waits for the vendor's investigation before acting — which is the wrong sequencing for DJCP notification timelines.
Where DJCP enforcement is heading
CAC will introduce mandatory pre-notification testing requirements for critical information infrastructure operators by 2026, requiring documented evidence of incident response exercises conducted within the preceding 12 months as a condition of MLPS certification renewal.
The gap between documented incident response capability and demonstrated capability under realistic conditions is the pattern CAC investigators are most consistently finding in post-incident audits. Regulators who see the same failure across hundreds of audits eventually mandate the fix. The trajectory of CISA tabletop exercise requirements in the US and NIS2 testing obligations in Europe provides the regulatory model. China's regulatory development in cybersecurity has consistently followed Western frameworks with a lag of 18 to 36 months, then exceeded them in enforcement specificity.
Confidence: mediumPublication of amendments to the MLPS certification process or new CAC guidance on incident response readiness requirements before end of 2026.A foreign-operated company will face a DJCP-related enforcement action specifically tied to a supply-chain incident misclassified as a vendor-side breach within the next 18 months, setting a precedent that clarifies operator obligations for third-party-originated incidents.
The supply chain attribution gap described above is not a theoretical risk. It is a structural hole in the majority of IR programs assessed. The regulatory obligation is clear in the text of the Measures. The gap is operational. Enforcement actions tend to follow from specific, documentable failures — and a supply-chain incident where the operator filed nothing because the vendor reported to its own regulator is exactly the type of case that produces a clear regulatory decision.
Confidence: highPublic CAC enforcement decision or reported regulatory action involving a foreign operator's response to a third-party-originated breach by end of 2026.
The compliance-security gap in DJCP incident reporting is getting worse, not better
The security community's response to DJCP has been almost entirely focused on the pre-incident side — MLPS certification, vulnerability management, access control. The incident reporting framework has been treated as an administrative add-on, something the legal team handles after the security team finishes its work. That division of responsibility is producing organizations that have reasonable pre-incident security posture and completely inadequate incident response infrastructure for the Chinese regulatory environment. The December 2023 Measures did not change the fundamental obligation — they clarified and tightened requirements that already existed. The organizations that were not aligned before are not more aligned now, because administrative compliance updates do not change operational behavior.
Counterargument
The counterargument is that most organizations operating in China are dealing with a compliance environment of genuine complexity — DJCP, PIPL, DSL, cross-border transfer rules, sector-specific requirements — and that prioritizing incident response infrastructure over primary security controls is the wrong sequencing. Get the controls right first, and you reduce the incidents you have to report. That is a reasonable position. It does not address the fact that incidents will still occur regardless of control maturity, and that the failure mode under CAC scrutiny is almost never the security control failure — it is the response and documentation failure that follows it.
One thing to do this week
Pull your current DJCP incident response runbook and map each step against the December 2023 Measures notification requirements. Specifically: does your runbook produce a root cause statement in the initial notification, or does it leave root cause for the final report? Does it trigger simultaneous filing to CAC, MIIT, and any applicable sector regulator, or does it sequence those filings? Does it apply DJCP severity definitions to classify the incident, or does it use your internal severity tiers? Those three questions will tell you whether your runbook is DJCP-compliant in structure or only in intent. If you cannot answer all three cleanly in the next 30 minutes, you have found the gap that needs fixing before the next incident.
Further Reading
Gap Analysis
gap analysis for compliancenetwork security
network security protocolsNational Vulnerability Database NIST
NIST National Vulnerability DatabaseCISA Vulnerability Management
CISA vulnerability management guidanceOWASP Testing Methodologies
OWASP penetration testing methodologies
Frequently Asked Questions
What is the CAC notification timeline under DJCP for major incidents on Grade 4 or Grade 5 systems?
Major incidents on Grade 4 or Grade 5 systems — typically critical information infrastructure operators — require CAC notification within 1 hour of detection. The 2-hour window cited in older summaries applies to significant incidents on lower-classified systems. The applicable timeline depends on the intersection of incident severity and the MLPS classification of the affected system, not severity alone.
Does filing with a sector regulator satisfy the DJCP incident notification requirement?
No. Sector regulator notification satisfies the sector-specific obligation but does not satisfy the CAC notification requirement, which is a parallel obligation under the Cybersecurity Law. The December 2023 Measures for Cybersecurity Incident Reporting made this explicit. Organizations must file with CAC and with applicable sector regulators contemporaneously for qualifying incidents.
What does a DJCP-compliant incident report need to include that Western breach notification formats typically omit?
DJCP notifications for significant and major incidents must include a preliminary root cause determination in the initial filing. Western breach notification models typically treat root cause as an output of the post-incident investigation, filed in a supplementary report. Under DJCP, omitting root cause from the initial notification causes CAC to return it as incomplete, which resets the compliance clock.
Who has the DJCP incident reporting obligation when a breach originates at a third-party supplier?
The operator retains the DJCP notification obligation regardless of where the incident originated. A third-party vendor filing with its own regulator does not satisfy the operator's CAC notification requirement. Organizations with supply-chain-originated incidents must file independently on the timelines that apply to their own system classification and incident severity, without waiting for the vendor's investigation to conclude.
What do CAC investigators examine in a DJCP post-incident audit beyond the notification document itself?
CAC investigators reconstruct the detection-to-notification timeline and request contemporaneous log evidence at each stage. They cross-reference the post-incident report against the organization's MLPS registration records to verify that affected systems were registered and correctly classified. They also assess whether multi-agency notification — CAC, MIIT, and sector regulators — was conducted in parallel, not sequentially.
How does an unregistered subdomain or shadow IT asset create a DJCP compliance problem beyond the security risk?
When an incident originates from or affects an unregistered asset, the post-incident report either omits it or misclassifies it, because the asset has no MLPS classification on record. CAC investigators cross-reference reports against MLPS registration records. A breach involving an unregistered system creates a secondary compliance failure around system registration that investigators will pursue independently of the incident itself.
What is the most common DJCP incident classification error in foreign-operated entities?
Most foreign-operated entities use internal severity tiers — low, medium, high, critical — that do not map to DJCP's tripartite structure of general, significant, and major. Incidents are triaged correctly against internal standards and misfiled against regulatory ones. Vulnox assessment data from 2024 found this pattern in the majority of assessed environments, with mid-severity events most likely to be misclassified because the ambiguity is resolved at the analyst level without regulatory reference.
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.