1. NCAP protocol landscape

New Car Assessment Programs (NCAPs) are consumer-facing safety rating schemes, not type-approval regulations. That distinction drives everything about how a vehicle program must treat them: a regulation defines a legal minimum that a vehicle must meet to be sold, while an NCAP defines a moving target that a vehicle must meet to be marketed as safe. When an NCAP protocol changes, no vehicle becomes illegal — but a vehicle's star rating, and therefore its commercial position, can change overnight. For a program manager, the practical question is never "are we compliant?" but "against which protocol version, in which market, at which assessment date, and with how much lead time before the change lands?"

This chapter establishes the reference frame for the rest of the course: who the major NCAPs are, how their protocols are structured and versioned, and how frequently and predictably they release changes. Everything downstream — impact scoring, test-plan rework, cost estimation, timing gates — depends on getting this landscape right.

The major programs and what each one governs

Five programs dominate global engineering effort, and a sixth set of regional schemes matters for specific markets. Each has a distinct scope, governance body, and release discipline.

Two structural facts follow from this table and shape all impact assessment work. First, protocols are modular: each program is a set of test procedures, each procedure has its own scoring and its own change history. A "protocol change" is rarely one event — it is a bundle of individual test-level amendments, some of which affect your vehicle and some of which do not. Second, programs borrow from each other. A new mobile progressive deformable barrier test introduced in Euro NCAP frequently propagates into ANCAP, Latin NCAP, and ASEAN NCAP within one to three cycles. This means a single technical change can create a multi-market impact wave, and a well-run program tracks the originator and the adopters together.

How protocols are versioned

Versioning conventions differ by program, and misreading them is a common source of planning error. Three patterns dominate:

• Calendar-year releases (Euro NCAP, JNCAP, most regional programs). The protocol is identified by the assessment year, e.g. "Euro NCAP 2026." A vehicle assessed in 2026 is rated against the 2026 protocol regardless of when it was designed. Releases are cumulative: the 2026 protocol contains all still-active tests from prior years plus the new amendments.
• Edition-based releases (C-NCAP). Identified by edition year with a defined validity window, e.g. C-NCAP 2024 Edition. Editions are larger, less frequent packages, and a vehicle type-approved under one edition may be assessed under the next if its assessment date falls after the transition.
• Rolling test-level updates (IIHS). Individual tests are revised independently and announced with their own effective dates. There is no single annual "protocol document" in the same sense; the effective test set is the union of current versions of each test.

For impact assessment, the version identifier must always be captured at the level of test procedure, not just program-year. A practical convention used in many OEMs is a compound key such as EURO-NCAP-2026 / AOP-2.1 / MPDB-FW, where the first field is the program-year, the second is the protocol document revision, and the third is the specific test. This makes it possible to answer "which of our running programs are exposed to the MPDB frontal update?" with a single query rather than a manual read of two protocol PDFs.

Release cadence and the planning window

Cadence is the single most important input to change-impact scheduling, because it determines how much time a program has between "change is known" and "vehicle must be ready." The figure below shows the typical information flow and the planning window that a vehicle program actually controls.

The cadence pattern to internalize is this: roadmaps are published years ahead, drafts appear roughly 6–12 months before the effective year, and final protocols land shortly before assessment begins. The planning window that a vehicle program controls sits between the draft and the final — and for many programs, design freeze has already passed by the time the draft is public. That is precisely why impact assessment cannot wait for the final protocol. The draft is the actionable document; the final usually confirms tolerances and scoring weights rather than reversing test content.

IIHS is the deliberate exception. Because it revises individual tests on its own schedule, sometimes with only a few months of notice, programs targeting the US market must maintain a standing watch on IIHS test updates rather than relying on an annual release event. A useful practice is to subscribe to the program's technical bulletins and log every update with its announcement date, effective date, and affected test — the same compound key described earlier.

What this means for the assessment workflow

Three working rules follow directly from the landscape and should be applied from the first chapter onward.

Anchor every assessment to a dated protocol snapshot. Before any impact analysis begins, record the program, the protocol version, the specific test procedures in scope, and the assessment date the vehicle is targeting. An impact assessment without this anchor is unfalsifiable — you cannot later tell whether a requirement was missed or simply changed after the analysis.

Separate "known" from "effective." A change published in a draft is known but not yet effective; a change in a final protocol is effective for the stated assessment year. Track both dates for every item. Programs that conflate them either over-invest in changes that get softened before final release, or under-invest in changes that were visible in the draft for a year and then confirmed unchanged.

Map the propagation path across markets. When a change originates in Euro NCAP, check the published roadmaps of ANCAP, Latin NCAP, and ASEAN NCAP for adoption timing. A single engineering countermeasure — a revised bumper beam, an updated AEB calibration, a new child-restraint fixture — can satisfy several markets if the adoption windows overlap. Conversely, staggered adoption can force two validation campaigns for the same technical change, which is a cost that is easy to miss if each market is assessed in isolation.

With this reference frame in place — the programs, their versioning conventions, and the cadence that governs when changes become actionable — the next step is to examine how a single protocol amendment is decomposed into test-level requirements, because that decomposition is what makes impact assessment quantitative rather than anecdotal.