First, clarify a common confusion: GB44496 and GB44495 are different standards.

·GB44495‑2024 – Technical Requirements for Vehicle Cybersecurity – covers whole‑vehicle cybersecurity plus on‑board data security – personal‑data lists, data classification/grading, anonymisation, storage, and access control – all under this standard.

·GB44496‑2024 – Technical Requirements for Vehicle Software Upgrades – covers only the OTA/software‑upgrade line – OTA link security, upgrade‑package protection, rollback mechanisms, SUMS management system.

Industry practice is to submit both standards together for public‑announcement type‑approval. The checklist below assumes this combined submission. Each section is tagged with its standard – do not file items under the wrong standard number.

1. Data Security Package – GB44495

GB44495 has full on‑board data control requirements – four major blocks. Most public‑announcement returns I have seen are due to an incomplete checklist, not test failures.

·Personal‑data inventory
List every type of personal data collected via vehicle sensors, cameras, microphones, GPS – face images, voiceprints, location histories, driving behaviour, biometrics. For each, state the source and purpose. Incomplete inventories are the #1 reason for rejection – do not leave this to the day before submission.

·Important‑data catalogue
Vehicle operational data, high‑precision map data, external‑environment perception data – these are classed as important data under GB44495. The catalogue must match the vehicle’s data‑architecture document – a paper classification with no actual isolation in the data flow will fail.

·Data‑anonymisation scheme
Describe which data are anonymised, pseudonymised, or left in clear text – plus the algorithm and degree of irreversibility. Vague descriptions are treated as missing.

  2. Data Storage and Transmission Security – GB44495

·Storage location and localisation
For each data type – stored locally, in the cloud (domestic or overseas) – must be stated. Data‑localisation requirements come from China’s Cybersecurity Law, Data Security Law, and Automotive Data Security Regulations – not GB44495 itself. Include server hosting contracts, data‑centre location certificates, and technical measures preventing outbound data flow.

·Transmission encryption
For each route – vehicle‑to‑cloud, vehicle‑to‑phone‑app, vehicle‑to‑third‑party – specify: encryption algorithm version, key‑management mechanism, certificate chain. “Encrypted transmission” alone is not enough – list the cipher suite, TLS version, and key‑rotation interval.

·Access‑control policy
For each role – driver, passenger, OEM maintenance, third‑party service providers, regulators – list access rights line‑by‑line. Default deny is the baseline – if not explicitly authorised, no one can access.

  3. User Rights and Incident Response – Compliance Support (Not Standard Clauses)

Users have the right to check what data has been collected, delete it, and withdraw consent – response timelines come from the Personal Information Protection Law and other upper‑level laws – not from GB44495/44496 themselves.
Process documents must cover: submission channels, internal approval flow, technical deletion operations, and confirmation feedback – don’t miss any.

Incident‑response plan: cover data leaks, unauthorised access, and data loss – reporting timelines come from the Network Data Security Management Regulations – not from the two vehicle standards. Include: incident grading, reporting paths, technical response steps, and user‑notification templates.

Security audits – companies may conduct internal audits; there is no mandatory requirement for third‑party audits. Third‑party audits are preferred for regulatory inspections/risk assessments – but not a precondition for public‑announcement type‑approval. Some agencies claim it is mandatory – that is false.

  4. GB44496 – Software Upgrade Special Package

This entire section is GB44496 – the previous sections were all GB44495.

·SUMS (Software Upgrade Management System) documents – the core: upgrade strategy, package integrity verification, digital‑signature validation, upgrade monitoring, rollback on failure, user notification.
Package integrity and digital‑signature verification are GB44496’s technical baseline.

·Offline controller flashing – whether it falls under GB44496 depends on the current implementing rules from the testing authority – do not assume “all offline flashing is included” or “all is exempt”. Dealership‑level local flashing is still under clarification – this remains a debated area.

·Overlap with GB44495 – the vehicle data‑architecture document and vehicle‑level cybersecurity scheme are shared – one document can satisfy both standards by cross‑referencing the corresponding clauses – no need to create two separate sets.

  5. Implementation Dates and Transition

Both standards originally had a 1 January 2026 effective date. MIIT’s implementation notice aligned new‑model public‑announcement submissions to 1 July 2026 – there is no “only GB44495 postponed” situation.

For existing production models, the transition period – watch MIIT’s public‑announcement implementation notices – there is no single fixed national deadline.
Start document preparation at least six months ahead – public‑announcement review during stable periods is 1–3 weeks; rushing at the end leads to delays.

For GB44495/44496 public‑announcement submissions, contact BlueAsia at 13534225140 (King) or king.guo@cblueasia.com.