Take the protection department’s identification notice as the operative fact, and report changes that may affect it
Severity High第八条至第十一条、第二十一条
Do not decide for yourself whether you are CII, and do not treat “no notice received” as a settled answer. Three things: keep a register recording whether a CII identification notice has ever been received from a protection department, which network facilities and information systems it covers, and the date and reference of the notice; write the trigger for a “material change” into change management — major system rebuilds, a change in the business carried, architecture or hosting changes, moving to or off cloud, and large data migrations should all trigger an assessment and a prompt report to the protection department, which completes a re-identification and notifies the operator within three months of receiving the report; and report any merger, division or dissolution promptly and handle the CII as the protection department requires. As a supplier, the same register should run the other way: which customers are CII operators and which part of their systems you carry, because the customer’s identification status determines which duties land in your contract.
- Applies when
- Companies that have received or may receive a CII identification notice, and AI suppliers carrying critical core business systems for customers in important sectors.
- Deadline: Report promptly after a material change; the protection department completes re-identification within three months of receiving the report
- Evidence to retain
- · Original CII identification notice and the register: systems covered, identification date, notice reference
- · Procedure document establishing the “material change that may affect identification” gate in change management
- · Assessment records for material changes and the acknowledgement of the report to the protection department
- · Re-identification result notice and the corresponding register update
- · Reporting records and the CII handling plan for a merger, division or dissolution
- · Customer-side CII status register: which customers are operators and what scope you carry for them
Estimated first-time effort: 5–15 person-days (estimate, not a commitment)
Establish the dedicated security management body, complete background vetting, and discharge its eight statutory duties
Severity Critical第十二条至第十六条
Consolidate into one funded, staffed, decision-empowered entity what is usually scattered across departments. First, the body and its people: set up the dedicated security management body, put its head and key-post personnel through security background vetting (with the public security and state security organs assisting), and fund and staff it; the principal bears overall responsibility for CII security protection and leads the handling of major incidents. Second, its duties: the body must discharge the eight duties in Art. 15 — establish cybersecurity management and appraisal systems and draft the security protection plan; drive protective capability building and run monitoring, testing and risk assessment; produce the organisation’s emergency plan against national and sector plans, run drills regularly and handle incidents; identify key cybersecurity posts, run appraisals and propose rewards and penalties; organise education and training; carry the responsibility for personal information and data security and build the corresponding systems; apply security management to design, construction, operation and maintenance services; and report incidents and significant matters as required. Third, decision participation: personnel of the body must take part in cybersecurity and informatisation decisions — the easiest duty to disprove in an audit, so meeting minutes need to record their attendance and views. Separately, security measures must be planned, built and brought into use simultaneously with the CII (Art. 12), so a new system’s project approval papers must show the security design moving in the same batch as the main works.
- Applies when
- Companies identified as CII operators; suppliers running operations under contract to a CII operator are typically required to align with the same management requirements.
- Evidence to retain
- · Establishment document for the dedicated security management body, with its headcount and budget approvals
- · Security background vetting records for the body’s head and key-post personnel
- · Cybersecurity protection system and accountability documents signed off by the principal
- · Cybersecurity management and appraisal systems, and the CII security protection plan
- · Execution records for monitoring, testing and risk assessment
- · The organisation’s cybersecurity incident emergency plan and records of regular drills
- · List of key cybersecurity posts, appraisal records and reward/penalty proposals
- · Security education and training plan with training and assessment records
- · Personal information and data security protection system documents
- · Systems and inspection records for applying security management to design, construction, operation and maintenance services
- · Minutes of cybersecurity and informatisation decision meetings recording the body’s attendance and views
- · Project approval and acceptance documents showing security measures planned, built and used simultaneously with the main works
Estimated first-time effort: 30–90 person-days (estimate, not a commitment)
Run at least one security test and risk assessment a year, and report major incidents and major threats as required
Severity Critical第十七条、第十八条、第二十八条
Two things that must leave timestamps. Testing and assessment (Art. 17): the operator must, itself or through a cybersecurity service provider, conduct at least one cybersecurity test and risk assessment of the CII each year, remediate the problems found promptly, and report as the protection department requires — all three steps are mandatory, and testing without remediation, or remediation without reporting, both fall inside the Art. 39(8) penalty. Incident reporting (Art. 18): on a major cybersecurity incident or a major threat, the operator reports to the protection department and the public security organs under the applicable rules; the Regulations separately enumerate the especially serious cases — the CII ceasing to operate as a whole or its main functions failing, leakage of national basic information or other important data, a relatively large-scale personal information leak, significant economic loss, or wide dissemination of unlawful information — which the protection department escalates to the CAC and the MPS after receiving the report. For the company this means that once any of those five appear the reporting chain escalates to ministry level immediately, so internal severity criteria have to be able to recognise them. Cooperate as well with inspections conducted by the protection department and by the public security, state security, secrecy and cryptography authorities (Art. 28).
- Applies when
- CII operators; cybersecurity service providers engaged to run the tests and assessments; and AI suppliers providing the systems and operations, since remediation and reporting usually need supplier-produced materials.
- Deadline: At least one test and risk assessment per year; report major incidents and major threats promptly under the applicable rules
- Evidence to retain
- · Annual cybersecurity test and risk assessment report, produced in-house or by an engaged provider
- · Contract with the cybersecurity service provider and its qualification materials
- · Remediation register: issue, owner, deadline, verification result
- · Records and acknowledgements of reports on testing, assessment and remediation made as the protection department requires
- · Incident severity criteria and classification records, including how the five especially serious scenarios are recognised
- · Reports of major incidents and major threats to the protection department and the public security organs, with timestamps
- · Cooperation records for authority inspections and the closed-loop remediation materials
Estimated first-time effort: 15–45 person-days (estimate, not a commitment)
As a CII supplier: sign the security and confidentiality agreement, support cybersecurity review, and meet the secure-and-trustworthy standard
Severity Critical第十九条、第二十条、第十五条第（七）项
This is where most AI companies actually meet these Regulations: the duty does not land on them directly but comes down through the customer’s procurement contract. Prepare three things in parallel. (1) The security and confidentiality agreement (Art. 20): when a CII operator procures network products and services it must sign such an agreement with the provider under the applicable national rules, specifying the provider’s technical support and security-confidentiality obligations and liabilities, and must supervise performance. The supplier should decide in advance what it can commit to: the term and response times for technical support, notification and fix windows for vulnerabilities, personnel confidentiality and vetting requirements, the boundaries of data processing and retention, limits on subcontracting and onward delegation, liability for breach, and cooperation with audits. (2) Cybersecurity review (Art. 19): operators give priority to secure and trustworthy network products and services, and procurement that may affect national security must pass cybersecurity review under national rules. The supplier needs to be able to produce, quickly, an account of its supply chain, the provenance of key components and open-source dependencies, where development and operations staff sit, data flows and storage locations, and remote-access and update mechanisms. (3) Security management of the service itself (Art. 15(7)): the operator applies security management to design, construction, operation and maintenance services, so the supplier’s implementation and operations personnel, accounts, remote access and change operations fall under the customer’s controls and appraisal — the supplier therefore needs account and operation audit capability it can hand over.
- Applies when
- Chinese AI companies selling foundation-model platforms, AI applications, data platforms or operations tooling to customers in power, transport, finance, telecommunications, public services and government, and the teams delivering implementation and operations for them.
- Evidence to retain
- · Executed security and confidentiality agreements with CII operators and the signing records
- · Technical support commitments: support term, response times, vulnerability notification and fix windows
- · Cybersecurity review pack: supply chain composition, provenance list for key components and open-source dependencies, locations of development and operations staff, data flows and storage locations, remote-access and update mechanisms
- · Personnel confidentiality undertakings and records of the vetting requirements applied
- · Approval records for subcontracting and onward delegation, with the terms binding the subcontractor
- · Register of implementation and operations accounts, remote-access approvals and operation audit logs
- · Self-inspection of performance under the security and confidentiality agreement and records of cooperation with the customer’s supervision
Estimated first-time effort: 15–45 person-days (estimate, not a commitment)
No vulnerability probing or penetration testing of CII without approval or authorisation
Severity Critical第三十一条、第四十三条
Art. 31 binds every individual and organisation regardless of operator status: without approval from the CAC or the MPS, or authorisation from the protection department or the operator, no one may carry out vulnerability probing, penetration testing or other activities that could affect or endanger the security of critical information infrastructure; such activities against basic telecommunications networks must be reported to the telecommunications authority in advance. For teams building security testing, red-teaming, attack-surface mapping, automated vulnerability scanning, or AI agents capable of network probing, this constrains product design directly: default scan scope needs a hard allowlist and a do-not-scan list; the authorisation document from the operator or protection department should be a precondition checked before a scan starts rather than paperwork produced afterwards; demo and load-test environments must not point at real CII; and probing initiated by third-party users of the product has to be constrained in the service agreement and in the product at the same time. Individuals given a public-security penalty for a breach are barred for five years from cybersecurity management and key network-operation posts, and for life if criminally punished (Art. 43 §3).
- Applies when
- All Chinese AI companies, and especially providers of security testing, red-team exercise, asset mapping and vulnerability scanning products, and providers of AI agents able to reach and probe networks autonomously.
- Evidence to retain
- · Scanning and testing authorisation policy: where authorisation comes from, how it is verified, retention requirements
- · Written authorisation or approval from the operator or the protection department
- · Configuration evidence for the product’s target allowlist and do-not-scan list
- · Design note and sample logs for the pre-scan authorisation check
- · Proof that demo and load-test environments are isolated from real targets
- · Service-agreement clauses restricting unauthorised probing by users, with the technical controls that enforce them
- · Records of advance reports for such activities against basic telecommunications networks, where applicable
Estimated first-time effort: 5–20 person-days (estimate, not a commitment)