There's one hard rule about GB 44495-2024 document review. The auditor doesn't count how many files you submitted. They go clause by clause against the standard text, checking every single one. Each document needs to answer three things. Who's in charge. What standard it follows. What happens when something goes wrong. One gap in any of those answers and the materials get bounced.
Here's the document breakdown across the three submission stages, the six most common rejection reasons, and what you still need to maintain after certification.
Amendment No.1 (published January 28, 2026) scrapped the standalone CSMS system certification. Everything is now called "information security assurance requirements." But the document checklist didn't shrink. Policies, procedures, records — you still submit all of it.
1. Information security management policy documents. First thing the auditor checks. Management sign-off page and effective date. Missing either one, it's a fail.
2. Supply chain security management specifications. Every external supplier that touches vehicle communications or data processing needs to be pulled into the management framework. The core document is a written security responsibility allocation agreement with each TBOX supplier, communication module supplier, and software developer. If you only signed a procurement contract without a separate security agreement, the auditor writes a non-conformity on the spot. If a supplier genuinely doesn't have an independent security agreement yet, you can submit that component's cybersecurity compliance declaration plus a third-party security test report as supplementary evidence. The procurement contract alone won't hold up.
3. Risk assessment report. The standard doesn't mandate a specific methodology — TARA works. But the report must cover five scenarios. Full vehicle assets. Remote attack paths. V2X communication. OTA upgrades. Data breach. Miss one scenario and the whole report gets ruled invalid.
4. Emergency response plan. At least one hands-on drill per year, covering all specified scenarios. The auditor doesn't look at meeting minutes. They look at system log screenshots and incident closure records.
5. Software upgrade security management procedures. GB 44495 checks tamper resistance, injection prevention, and communication encryption during the upgrade process. GB 44496 checks functional safety impact assessment. The two can share a common framework, but the inspection criteria are different. You can't submit the same document for both standards and call it done.
Stage Two: VTA Vehicle Testing Documents
1. Complete vehicle technical parameter sheet. The ECU list needs to match the actual vehicle unit by unit — part number, software version number, no discrepancies. Complete vehicle network topology diagram, TBOX model, encryption chip model — all must be filled in completely.
2. Communication interface security plan. TBOX cellular, WiFi, Bluetooth, USB, OBD diagnostic port, V2X — each external channel needs its own access control plan and authentication mechanism description. The OBD port is the most common rejection point. Many OEMs classify it as a service tool interface in their documentation. The review body doesn't accept that classification.
3. Encryption scheme technical description. Vehicles sold domestically must use SM2, SM3, SM4 national cryptographic algorithms, covering three scenarios. External communication encryption. Firmware signing. Critical data storage encryption. Export-only vehicles are exempt from national algorithm requirements but need a written declaration stating so. Foreign-language files in technical drawings and encryption schemes need translations stamped by a certified translation agency. In-house translations won't be accepted by the review body.
4. Data security protection plan. The testing equipment reads storage directly. If driving trajectories or operation logs are sitting there in plaintext, the data security domain gets flagged as a fail on the spot.
5. Complete penetration testing archive files. Amendment No.1 explicitly requires penetration testing as mandatory. The following documents are non-negotiable. CMA-stamped penetration test plan. Full operation logs and vulnerability reproduction screenshots. Vulnerability classification list (critical/high/medium/low) with corresponding remediation technical plans. Post-remediation retest report and closure confirmation form. Vulnerability routine monitoring management procedures plus the last six months of scan records. Any unclosed vulnerability gets the entire submission rejected.
6. Test vehicle conformity declaration. ECU configuration, software version numbers, communication module parameters must match production-spec status. Any differences need to be explicitly stated.
Stage Three: CCC Certificate Application Documents
The outputs from the first two stages — assurance review report original, VTA test report original, technical parameter sheet — plus excerpts of the cybersecurity function chapter from the vehicle manual, and the Conformity of Production control plan.
The CoP control plan must include a dedicated vehicle cybersecurity management section covering component-level security change controls, annual vulnerability monitoring, and security incident reporting procedures. Missing this dedicated section means instant document rejection.
Homologation filing and CCC go through two independent approval channels. General foundational items can share test data. But core security parameters — vehicle network topology, TBOX model, encryption chip model, national algorithm implementation — must be identical across both filings. Any mismatch on any of these triggers a full rejection and re-review. This isn't just about software version numbers.
What Amendment No.1 Changed for Your Document Checklist
As mentioned, CSMS system certification terminology got deleted. There's another terminology change people keep missing. Every instance of the old term for "inspection" in the standard got replaced with a different Chinese term. Your existing documents using the old vocabulary will be flagged for deviation too. When you audit your documents, don't just look for the system name change.
Extra Documents for Overseas Platforms and Imported Vehicles
Imported complete vehicles or joint ventures using overseas technical platforms need UN R155 equivalence assessment application materials, plus full Chinese translations with a Chinese-foreign terminology cross-reference table. Translation isn't literal — the terminology has to align with domestic standard text conventions.
A note on parallel imports. The equivalence assessment pathway is primarily for batch new complete vehicle imports. Scattered single-unit parallel imports generally won't be accepted for equivalence assessment. They need to compile a full set of security assurance documents from scratch.
What Facelifts and Changes Require
Same-platform facelift models don't need to rebuild the policy documents from scratch. They only supplement change difference descriptions and partial retest reports for the modified elements — TBOX swap, gateway change, security chip change, encryption algorithm modification. These count as major changes and must go through formal change filing. You can't just update the technical plan without filing the paperwork.
Document Work That Doesn't Stop After Certification
CCC certificates are valid for five years. Renewal starts 90 days before expiry. Renewal isn't automatic — the certification body reviews five years of security operation records and all historical CoP surveillance results. Multiple major non-conformities in the record means a tougher renewal review.
All policy documents, drill records, vulnerability scan records, and upgrade records must be retained until ten years after the vehicle model is discontinued. Each year's CCC factory surveillance audit spot-checks the full archived documentation set.
CoP audits bundle the whole vehicle. Nobody runs a separate GB 44495 session. But the cybersecurity-specific documents need to be organized and ready for review every single year without fail.
Six Reasons Documents Get Rejected
After seeing enough submissions come back marked "resubmit," a few patterns stand out.
One. The risk assessment report skipped a scenario. Most commonly V2X communication or data breach. The auditor checks all five — full vehicle assets, remote attack paths, V2X, OTA, data breach. Miss one and the entire report is ruled invalid, not just that section.
Two. OBD port classified as a service tool interface in the communication security plan. The review body consistently rejects this framing. OBD is an external access point with diagnostic-level ECU access. Treat it accordingly in your documentation.
Three. Foreign-language technical documents submitted with in-house translations instead of certified translation agency stamps. This one catches import brands and joint ventures constantly. The translation stamp isn't optional.
Four. Penetration test archive missing even one required document. You need the CMA-stamped plan, the full operation logs with vulnerability reproduction screenshots, the classified vulnerability list with corresponding remediation plans, the retest report, and the closure confirmation form. Every single one. Missing one item gets the entire batch rejected — not just the penetration test section.
Five. CoP control plan missing the dedicated cybersecurity section. This gets flagged at the CCC application stage, not during factory audit. By the time the auditor shows up, it's already too late for that submission round.
Six. Homologation parameters and CCC parameters don't match. Not just software version numbers. Vehicle network topology, TBOX model, encryption chip model — if any of these differ between the two filings, everything gets bounced. Both channels get compared line by line.
Need a document preparation checklist tailored to your vehicle program? Contact BlueAsia Testing's certification consultants at +86 13632500972 (Benson).
相关新闻
