Documents for Data Export Security Assessment: Four Statutory Categories and Eight Practical Files

The documents required for a data export security assessment comprise four categories in the statute, yet in practice eight files must be delivered that can each be read independently. The difference lies not in quantity but in whether the documents corroborate one another. The reviewer is not asking how complete any single document is, but whether the scenario description, the self-assessment report, the contract terms and the security measures speak with one voice — the same recipient, the same categories of data, the same basis for counting individuals, and measures that are actually running.

Where the accounts do not reconcile, a thicker file is returned faster.

First, confirm that the export falls within scope

Article 7 of the Provisions on Promoting and Regulating Cross-Border Data Flows reduces the triggering scenarios to three:

Three points are easily missed. First, the cumulative basis runs from 1 January of the current year, not a single transmission or the contract term. Second, sensitive personal information is counted separately, with 10,000 individuals triggering the threshold — far lower than for ordinary personal information. Third, important data is not volume-based: the test is the catalogue published by the region or department, not the company’s own confidentiality grading.

Exports outside the three categories follow standard contract filing or personal information protection certification. But ’no assessment application’ does not mean ’no assessment’: the obligation to conduct a risk self-assessment before export remains, save that the reviewing authority shifts from the national administration to the company itself and the provincial filing stage.

The four statutory categories

Article 6 of the Measures lists four items, with no fifth:

The fourth item is a catch-all and is where the real work lies. It is not a case of ‘submit if you have it’; it is the material by which the reviewer tests the first three. The first three state what the company says; the fourth shows why it should be believed.

The eight practical files

One, the application form. Complete it on the filing system template, focusing on the number of export scenarios, categories of data, individuals involved, and the recipient’s name and jurisdiction. The point of care is the granularity of scenario separation: one business action, one scenario. Do not merge ‘model invocation’ and ‘customer service outsourcing’ into a single ‘overseas processing’.

Two, the export scenario description. Use business process and data flow diagrams to show where the data comes from, which systems it passes through, how it reaches the overseas recipient, and how it is stored and further transferred there. The text need only answer four questions: why it leaves, what leaves, to whom, and for how long. The diagrams should mark the carrier and encryption at each hop, because the reviewer will compare them hop by hop against the contract annexes.

Three, the risk self-assessment report. This is the core document, addressed separately below.

Four, the legal document with the overseas recipient. This may be a data clause in the main contract, a standalone data processing agreement or another legally effective document. Article 9 requires at least six matters: the purpose, method and scope of export; the overseas storage location, duration and handling on expiry; constraints on onward transfer; security measures if control of the recipient or the rules of its jurisdiction change; remedies for breach and dispute resolution; and handling of security incidents together with channels for individual redress. A missing item among the six is likely to attract a request for correction at completeness review.

Five, the recipient’s security capability statement. This covers the recipient’s data security management system, technical measures, staffing, record of past incidents, and the data protection rules and cybersecurity environment of its jurisdiction. This is the document most often reduced to a self-declaration; what is needed is verifiable fact — ISO 27001 certification, an independent security team, the region in which data is stored.

Six, the security measures statement. Divide it into technical and organisational parts. Technical: encryption, pseudonymisation, access control, log retention, transmission links. Organisational: approval workflow, personnel permissions, supplier management, incident response. The key is operational records: policy texts are universal, while the reviewer looks at the last three months of access logs, approval tickets and drill records.

Seven, the statement on protection of personal information rights. Explain how notice and consent are implemented, where separate consent applies, the channels and time limits for access, copying, correction and deletion, and the complaints mechanism. Cross-border notice must appear as a separate section of the privacy policy, not a sentence buried in general terms.

Eight, entity qualification and authorisation documents. Business licence, identity document of the legal representative, and the authorisation of the handling officer. Apparently the simplest, yet returns commonly arise because the authorisation lacks the company seal or the business scope does not cover the actual activity.

The six chapters of the risk self-assessment report

Article 5 of the Measures lists six assessment matters; the report should follow them item by item rather than invent its own structure.

Chapter 6 is most often written as ’no other matters’. What it actually tests is capacity for continuing management: what happens if the recipient is acquired, if its jurisdiction amends its data law, if the model provider changes inference nodes. Writing ’none’ tells the reviewer that none of these questions has been considered.

Five frequent grounds of return

One, scenario and contract do not match. The scenario describes transfer to company A while the contracting party is company B, or the contract annex lists fewer data categories than the scenario. Inter-company collection, payment and contracting arrangements are especially prone to this.

Two, the counting basis is wrong. Cumulative volumes are counted per transmission, or pseudonymised data is excluded as if anonymised. Pseudonymised data remains personal information and must be counted.

Three, onward transfer is unconstrained. The overseas recipient passes data to sub-processors or cloud providers without the contract specifying the list, conditions and responsibility for onward transfer. Article 9(3) of the Measures expressly requires this.

Four, security measures consist of policy without records. Policy texts and architecture diagrams are submitted, but no access logs, approval records or drill records. The reviewer cannot conclude that the measures are running.

Five, the important data determination lacks a basis. The conclusion reads ’not important data’ without stating which catalogue was consulted, who determined it and on what fields. The reasoning matters more than the conclusion.

Process and timetable

Working backwards from this table gives the starting point: if the launch date is fixed, the process must begin at least six months beforehand, because the 45 working days cover the assessment alone, excluding document preparation, correction and possible extension.

How it differs from standard contract filing

The two routes are not a menu from which one chooses; they apply automatically by threshold. The common error is to prepare for the standard contract, discover halfway that volumes cross the line, and switch to assessment — at which point the negotiated clauses must be renegotiated against Article 9.

A twelve-week preparation table

The review period is not counted within the twelve weeks. Where a regulatory enquiry or rectification notice has already been received, time is compressed and document preparation and contract negotiation must run in parallel.

Related reading on this site: the three routes for data export and their budget, how to classify and grade data, personal information protection impact assessment, and the service pages for data compliance and cross-border and overseas matters.

This article is based on the Measures for Security Assessment of Data Export, the Provisions on Promoting and Regulating Cross-Border Data Flows and publicly available filing requirements. It is for reference only and does not constitute legal advice. Specific applications should follow the latest requirements of the competent provincial cyberspace administration.