Incident reporting for automated vehicle trials, pilots and passenger services

The first report depends on the permission and the event

A driverless shuttle collides with a bollard and stops. No passenger reports an injury. An operations analyst sees the first alert at 09:10. A safety engineer finds at 11:00 that the vehicle also failed to reach its planned minimal-risk position. The organisation may have a Vehicle Special Order for the vehicle, an automated passenger service permit for the service, insurer obligations and ordinary road-traffic duties. A single label called AV incident does not tell staff whom to notify or when a clock begins.

The current DfT self-driving pilot applicant guidance describes reporting for automated-driving occurrences, vehicle cyber incidents, operator cyber incidents and passenger-permit incidents. It also says reportable automated-driving occurrences are set out when a Vehicle Special Order is issued. The actual order and permit conditions can specify the events, recipients, format and schedule for a deployment. A public guide cannot substitute for those documents.

This page owns the notification decision and evidence trail after an incident has been made safe. A supervised-trial emergency-response guide owns immediate scene action, people, police contact and pause decisions. A passenger-support guide owns communication and assistance to people in a driverless service. A cyber-assurance guide owns prevention and technical containment. Here the question is what gets reported under which route, by whom, with what initial facts and what later updates.

Do not copy a 24-hour figure into every automated vehicle procedure. The figures in DfT guidance attach to defined pilot and permit streams, and the issued conditions still need examination. The full Automated Vehicles Act in-use regime is being implemented in stages. Its future information and investigation powers should not be presented as an existing universal pilot incident clock. A transport lawyer and the responsible authority should confirm a live operator's reporting matrix before service begins.

Separate three current operating routes

First identify what the vehicle was doing at the time. A supervised trial under the June 2026 automated vehicle trialling code has a safety driver ready, able and willing to resume control. The code points to ordinary legal incident duties, expects reportable incidents to be communicated to police and advises engagement with authorities. It does not grant a special no-driver pilot permission or apply all pilot guidance deadlines to every supervised trial.

A no-driver pilot uses a different legal and administrative route. The vehicle's Vehicle Special Order and related conditions matter, as do the DfT pilot guidance and any applicable vehicle listing. The order can specify which safety-relevant occurrences and cyber events the vehicle or operator must report. The people responsible for the pilot should hold the signed order and a controlled condition summary. A generic website table is not that summary.

An automated passenger service may add a permit layer. The permit holder has passenger-service reporting and record duties described in the applicant guidance and its issued permit. It may not be the same legal person as the Vehicle Special Order holder. One incident can therefore generate two regulatory streams as well as a police, insurer or other report. The contract between companies should allocate preparation and submission, but a private allocation does not remove an obligation imposed on a named holder.

Record the operating route at the start of every event entry. Include the vehicle, trip, software version, order number, permit number and legal entities. A control-room operator may know the fleet but not which permit applies to a changed route. Make that lookup possible before an incident, not during an argument about whether the event is reportable.

Build a condition-specific reporting matrix before launch

Create one matrix for each permission and statutory duty. Each row should identify the source, event definition, knowledge trigger, initial recipient, initial clock, follow-up report, evidence to retain, person responsible and escalation substitute. Attach or link the actual signed order and permit. A matrix is an internal working aid, not a legal instrument. Its owner must update it when conditions, routes or authorities change.

For the current no-driver pilot, the DfT guidance describes automated-driving safety-relevant occurrence notifications within 24 hours from knowledge, short-term reports within 30 days and periodic reports on a case-by-case schedule. It says the reportable occurrences will be set out when the Vehicle Special Order is issued. That is an applicant-guidance description of expected pilot conditions. The team's legal review should compare every row with the issued order before treating a guidance example as an actual obligation.

For vehicle and operator cyber incidents, the same guidance describes an initial notification without unreasonable delay and within 72 hours from knowledge, followed by a short-term report within 30 days. A suspected attack or vulnerability may need early notice even when the technical picture is incomplete. Separate the vehicle stream from the operator stream; they may have different accountable entities, evidence and affected systems. The cyber team should supply facts, but the condition holder needs a named owner for external communication.

For an automated passenger service permit, the guidance describes critical reportable incidents being notified as soon as reasonably practicable and no later than 24 hours after knowledge. Its examples include collisions, medically significant injury, safety-critical component failures, fires, dangerous occurrences, safety-defect allegations and safeguarding incidents. Non-critical incidents are described as notifiable without unreasonable delay. These categories need comparison with the actual permit, current guidance and facts. The label non-critical is not permission to ignore an event.

The matrix must also cover ordinary law. The Road Traffic Act 1988 section 170 deals with a driver's duties after specified accidents, including stopping and giving particulars or reporting in the cases the section defines. The supervised-trial code highlights it. Whether section 170 is triggered depends on the incident, driver and territory. A public service vehicle can have additional reporting under Public Passenger Vehicles Act 1981 section 20, also flagged in the trialling code. A lawyer should decide how those provisions apply to the exact vehicle and service. The operator should avoid assuming that a pilot notification to DfT satisfies a police or DVSA duty.

The table is a triage aid. It is deliberately not a set of universal deadlines. If one event fits several rows, open separate actions and designate an overall incident lead so submissions remain consistent.

Work out when the organisation knew

Several guidance clocks run from knowledge of the occurrence or incident. That phrase makes the discovery trail important. Record when the first alert reached the organisation, who received it, what it appeared to mean, when further facts emerged and when a person classified it. Do not reset the first timestamp because a senior manager read the file later. Equally, do not pretend an automated alert necessarily disclosed every material feature of a complex event. A legal reviewer should examine ambiguous cases.

The opening shuttle example shows why. At 09:10 the control room knows about a collision. At 11:00 engineering finds a separate fallback failure. The collision may have triggered an initial report before the full system analysis exists. The second finding may require an update or a separate classification. The team should submit known facts in good faith, identify uncertainties and commit to follow-up, rather than wait for perfect reconstruction while a time-sensitive initial notice expires.

Use a shared incident identifier across all notifications. Preserve the source alert, call logs and report version. If information is corrected later, show what changed and why. A regulator should not receive inconsistent accounts from the permit holder and Vehicle Special Order holder merely because their teams used different spreadsheets. The internal record should distinguish an observed fact from a preliminary hypothesis, especially about causation or whether the vehicle was in automated mode.

Build a fallback for absence and weekends. The condition holder should know who can submit when the nominated reporting officer is away, how to reach the recipient outside normal hours and who can authorise a first notice that contains uncertainty. Practice the submission method. A matrix with a correct deadline but an untested email address or no substitute owner is not operationally ready.

Capture enough evidence without blocking urgent care

Safety comes first. Protect people, arrange emergency response and secure the scene as appropriate before attempting to complete a data form. Once it is safe, preserve the information needed to understand the event. The DfT passenger-permit guidance expects incident data to be captured as soon as reasonably practicable and securely stored under permit conditions. It refers to onboard systems, automated-driving logs, sensors and internal vehicle technologies. The pilot guidance also describes technical data expectations for automated-driving occurrences.

Define a minimum evidence bundle before launch. It can include vehicle identity, journey and route, precise time basis, automated or manual mode, speed and position, software and map version, alerts, interventions, remote-assistance activity, camera or sensor references, weather, road condition, witness details and passenger-support records. Each field should be justified. A system may lack some data, and a human account may be uncertain. Record the gap rather than inventing a value.

Protect integrity. Copy logs in a controlled way, retain original files where possible, document the person and tool used to extract them and record every later transfer. A workshop repair, software update or vehicle recovery could overwrite relevant data. Establish a hold on affected vehicles or logs until the incident lead and technical owner decide what can safely change. This is an evidence-preservation control, not a direction to leave an unsafe vehicle in traffic.

Data protection matters. Video, location and passenger-support records can identify people. Access should be limited, storage protected and retention linked to the applicable legal, permit and investigation needs. The ICO guidance on data protection impact assessments helps assess high-risk processing, but the exact notice and sharing basis need privacy review. A reporting obligation does not turn every raw recording into public information.

The first external notice should identify the incident, affected vehicle and service, known harms, immediate protective action, current status and contact for updates. The actual condition may require other fields or a prescribed channel. Avoid asserting a final cause before the engineering evidence supports it. If the report is incomplete, say what remains under investigation and when a follow-up can be expected. Store the submitted version and proof of receipt.

Make the passenger permit stream explicit

Passenger-service incidents can occur without a driving-system defect. A person may need medical help during a journey, be stranded after an access failure or raise a safeguarding concern. The permit guidance lists safeguarding among critical reportable examples. The permit holder should therefore connect its passenger-support team to the incident classifier. A control-room alert that only records vehicle faults will miss events known first to a call centre.

Prepare categories for critical and non-critical reports from the guidance, then reconcile them against the issued permit. For a critical event, the guidance's outer 24-hour limit does not mean the team should wait 24 hours. It says as soon as reasonably practicable and no later than that point after knowledge. For a non-critical event, the guidance uses without unreasonable delay. The organisation should set internal escalation targets shorter than any external outer limit where practical. Label those internal targets as company rules, not statutes.

The guidance also says the applicant should keep records of safety-related incidents and action taken for at least three years. An actual permit can shape retention and access. Coordinate this with privacy requirements, insurer needs and investigation holds. A blanket deletion at three years may be wrong where another duty or live claim applies. Equally, indefinite retention without purpose can be wrong. A data specialist should define the schedule for each record class.

Where the Vehicle Special Order holder and APS permit holder differ, specify who obtains the technical logs, who talks to passengers, who submits each regulatory notice and who owns corrections. Set contractual cooperation terms before a service starts. Test the handoff with a scenario in which a collision and passenger injury occur outside office hours. If each entity assumes the other has submitted, the system has failed even when both maintain incident software.

Avoid importing the future full Act regime into a 2026 pilot

The Automated Vehicles Act 2024 establishes a fuller authorisation, operator and investigation framework. Its information-sharing and investigation provisions are being brought into operation in stages. They may create future duties for authorised self-driving entities, licensed no-user-in-charge operators, police and others through commenced provisions and regulations. That developing framework should be monitored, but it must not be substituted for the present order, permit and road-law reporting position of a 2026 pilot.

Assign a regulation owner to watch commencement, new reporting regulations, revised DfT guidance and changes to issued conditions. When a new duty becomes applicable, update the matrix and train people who classify and submit events. Record the version effective on the day of each occurrence. A later rule may improve a process, but it should not be cited retrospectively as the source of an earlier deadline.

Do not assume that every company in the vehicle chain is the same regulated body. The future authorised entity, pilot Vehicle Special Order holder, passenger permit holder, insurer, manufacturer and remote-support contractor may be different people. Each may have information, but the obligation to report depends on the actual legal source and role. A responsibility map should show who provides facts and who signs the submission.

Test the process with difficult events

Run a tabletop exercise using three examples. First, a supervised trial with a safety driver strikes an unattended parked vehicle. Ask who stops, what particulars are exchanged, whether police reporting is required and whether the trial can continue. Second, a no-driver pilot vehicle brakes unexpectedly and a cyclist falls without direct contact. Ask whether the issued order treats it as a safety-relevant occurrence, what evidence is preserved and when the pilot holder became aware. Third, an APS passenger reports an assault in a stopped vehicle while the operator also sees a cyber alarm. Test passenger safeguarding, permit notification, operator cyber classification and vehicle safety action as separate but coordinated decisions.

At the end of each exercise, compare the actual clock with the matrix. Was the first recipient correct? Could a substitute officer submit? Did the team use the right order and permit versions? Did the first notice contain known facts without speculation? Did the operational team pause affected vehicles where needed? Would a later engineering result reach every recipient who received the initial report? Fix the process and repeat the exercise.

Maintain an incident log with one event identifier and multiple duty rows. The log should show source, classification, knowledge time, submission deadline as confirmed for that permission, named sender, actual send time, receipt, follow-up date, evidence hold and closure decision. A no-report decision should also record its reasoning and reviewer. A regulator or insurer may later ask why an apparently serious event was not notified.

Where Complys could help an operator

A vehicle operator may wish to track incident records, responsible people, tasks, evidence links and reporting reminders. Complys can be assessed for those administrative tasks in a product demonstration. This page does not claim that the product reads Vehicle Special Orders, decides reportability, sends mandatory reports to DVSA, preserves raw vehicle telemetry or calculates legal clocks automatically. The product owner must verify any exact feature before publication.

For a demonstration, bring two permissions with different holders and a sample collision. Ask whether the product can keep separate obligation rows, show the source condition, retain the initial and corrected reports, assign a substitute owner and export an evidence trail. If vehicle logs remain in another system, show the link and access control. The AV software overview covers broader procurement questions. The AV checker is a nonbinding regime pointer, not an incident-reportability decision tool.

The practical next step is to put the issued Vehicle Special Order, APS permit and current guidance side by side. Build the reporting matrix, name every sender and test a collision, cyber event and passenger incident. Specialist review must resolve the precise legal classifications and conditions. Once that is done, reporting can begin with an accurate early notice and develop into a supported account as evidence arrives.