The Development Interface Agreement playbook: writing a DIA that survives audit

Key takeaways

• A Development Interface Agreement (DIA) is the document European OEM auditors read second, right after the safety case, and where multi-supplier programs most often lose ASPICE capability points and ISO 26262 audit evidence.
• ASPICE 4.0 and ISO 26262 Part 8 Clause 5 both name the DIA explicitly. The two standards converge on the DIA as the joint accountability artifact between OEM, Tier-1, and Tier-2.
• The four most common DIA failure modes at audit are unowned confirmation measures, silent tooling and data handoffs, no item-level scoping, and a missing or broken update mechanism.
• A defensible DIA contains nine specific elements, including ASIL-scoped confirmation measures, named tooling and exchange format, and a documented change-control procedure.
• LHP's approach treats the DIA as a joint engineering, safety, and quality deliverable, not a procurement attachment, and audits it on a focused timeline of weeks rather than months.

A Development Interface Agreement (DIA) is the document European auditors open second, right after the safety case. It is also the document where most multi-supplier programs lose ASPICE capability points and ISO 26262 audit evidence. When a Tier-1 supplier's DIA is vague on confirmation measures or silent on configuration baselines, every downstream artifact inherits that vagueness. The DIA is not paperwork. It is the contract that decides whether your evidence survives an on-site assessment.

Why the DIA is on the audit critical path right now

ASPICE 4.0 (the current Automotive Software Process Improvement and Capability Determination model, published by VDA QMC in December 2023) increased assessor scrutiny on supplier interfaces. SUP.1 (Quality Assurance), MAN.3 (Project Management), and the ENG process group all expect documented, mutually-agreed interfaces between development levels and between OEM and supplier. In parallel, ISO 26262:2018 Part 8 Clause 5 requires a DIA wherever a safety-related item is developed in distributed development. The two standards converge on the DIA as the joint accountability artifact.

European OEMs, particularly the German manufacturers, no longer treat ASPICE as optional guidance. They use it to screen and rank suppliers. With an RFQ comes a quality professional, a laundry list of deliverables, and a hands-on review of your process against the maturity model. As an LHP functional safety expert framed it in a recent piece on the ASPICE and functional safety intersection, ASPICE has become the language of supplier maturity. When that review reaches your DIA, you want the auditor to find a defensible document, not a placeholder.

What is a Development Interface Agreement, and what is it not?

A Development Interface Agreement is a documented and mutually approved agreement between two or more parties involved in the development of a safety-related item or element. It defines how the parties share responsibilities, information, and deliverables across the development lifecycle to ensure that functional safety, quality, and process compliance objectives are met.

What a DIA is not:

• A purchase order with a safety clause appended.
• A boilerplate ISO 26262 attachment copied across programs.
• A statement of work that names "safety" without naming work products.

The distinction matters because auditors do not score intent. They score evidence. A DIA that lists responsibilities without naming the specific work products, milestones, and confirmation measures attached to each responsibility cannot serve as audit evidence.

Where do DIAs most often fail at audit?

Many DIAs are written by procurement and reviewed by engineering only after the contract is signed. The result is a document that satisfies legal but not assessors. Four failure modes account for most of the lost capability points LHP observes in current ASPICE and ISO 26262 engagements.

1. Unowned confirmation measures. ISO 26262 requires confirmation reviews, functional safety audits, and a functional safety assessment for ASIL C and ASIL D items. A common failure is naming the measures without naming who performs them. The DIA must specify whether confirmation is performed by the OEM, the Tier-1, an independent party, or some combination, and how the required organizational independence is preserved.
2. Silent on tooling and data handoffs. ASPICE base practices in the ENG process group expect bidirectional traceability across system, software, and hardware artifacts. If the DIA does not commit each party to a specific tool, exchange format, and frequency, traceability becomes hand-built spreadsheets that auditors will not accept as evidence.
3. No item-level scoping. A DIA written at program level cannot answer "which item, which ASIL, which work products" without secondary documentation that is rarely produced. The defensible pattern scopes each safety-related item explicitly and maps it to its ASIL, the parties involved, and the relevant clauses of ISO 26262 Part 4 through Part 7.
4. Update mechanism is missing or broken. Programs change. Suppliers change. Re-baselining the DIA after a change request is a process discipline most DIAs omit entirely. Without a documented change procedure, the version assessors find at audit may not match the version engineering has been working from.

How ASPICE and ISO 26262 each interrogate the DIA

When an ASPICE 4.0 assessor opens your DIA, four base practices structure the questions:

• SUP.1 Quality Assurance. Are roles, responsibilities, and interfaces between the project and other parties defined and agreed upon? Does the DIA cover your role as a supplier for all aspects of the project?
• MAN.3 Project Management. Are project responsibilities, deliverables, and schedules between all participating parties documented and agreed?
• ENG.1 through ENG.3 (System and Software Development). Is the interface and information exchange between development levels (system to software, OEM to supplier) defined, including the work products exchanged and their acceptance criteria?

When an ISO 26262 assessor opens the DIA, the lens shifts to Part 8 Clause 5 (Distributed development) and Part 2 Clause 6 (Safety management). The DIA must demonstrate that safety responsibilities can be traced to a single accountable party for every work product, that the confirmation measures are scoped to the ASIL of the item, and that independence requirements (for example, for ASIL D confirmation reviews) are satisfied by the organizational arrangement the DIA describes.

The DIA is the bridge document. ASPICE assessors read it as a process artifact. ISO 26262 assessors read it as a safety management artifact. Both readings must succeed on the same document.

The nine items a defensible DIA contains

Use this checklist when reviewing a DIA before audit:

1. Parties named, with the specific organizational unit (not just the legal entity).
2. Each safety-related item enumerated, with its ASIL and the relevant ISO 26262 parts.
3. For each item: the work products assigned to each party, with acceptance criteria and exchange format.
4. Confirmation measures (confirmation reviews, functional safety audits, functional safety assessment) scoped to each ASIL, with the party performing each measure and the independence basis.
5. Tooling and exchange format named (Polarion, IBM DOORS, Codebeamer, Jama, or equivalent, plus the data format for inter-party exchange).
6. Milestone and review gates with dates and the parties accountable at each gate.
7. Change-control procedure: how a change request that touches the DIA is logged, agreed, and re-baselined.
8. Communication and escalation paths for safety-related issues, including the safety manager on each side.
9. Reference to the ASPICE base practices the DIA satisfies, by base-practice identifier (SUP.1, MAN.3, ENG.1 through ENG.3 at minimum).

A DIA that hits these nine items reads as a process artifact and as a safety artifact. A DIA that misses three or more typically requires significant rework during the audit, often costing weeks to months of program time.

How LHP approaches the DIA

LHP develops DIAs as joint deliverables, not procurement attachments. The work begins with a process gap assessment against ASPICE capability levels and ISO 26262 requirements, then maps each safety-related item to a party, a set of work products, and a confirmation regime. The agreement is reviewed by an Intacs-certified ASPICE assessor and a functional safety manager before signature, then becomes an audit-evidence artifact that holds up under an on-site assessment.

For programs already in flight, the DIA is rarely the first thing rewritten. LHP runs a focused DIA audit, identifies the gaps that pose audit-stop risk, and closes them in parallel with the rest of the safety case. This typically takes weeks, not months, on programs that already have most of their safety artifacts in place. The same discipline is built into the LHP Functional Safety Certifiable Framework, which carries DIA-grade traceability into the development methodology from the start.

Related reading: ASPICE and functional safety: 8 common questions answered. Related capability: LHP ASPICE consulting.

What this means for your next program

If your next program is with a European, Korean, or major Asian OEM, treat the DIA as a procurement-gate artifact, not a contract attachment. Schedule the DIA review with engineering, safety, and quality, jointly, before signature. Build a DIA template for the organization that hits the nine items above and reuse it across programs with item-level customization. Re-audit the DIA every time the program changes scope, not just once a year.

Programs are won and lost on what auditors can find. The DIA is not the only document that decides the outcome. It is the document that ties every other piece of evidence together.

Frequently asked questions

When is a DIA required under ISO 26262?

A DIA is required wherever a safety-related item or element is developed under distributed development, as specified in ISO 26262:2018 Part 8 Clause 5. In practice this means any program where the OEM and Tier-1, or Tier-1 and Tier-2, share responsibility for any work product within the safety lifecycle of an ASIL-rated item. The standard does not exempt informal sub-supplier relationships. If work crosses an organizational boundary inside the safety lifecycle, a DIA is the artifact that documents the shared responsibility.

How does ASPICE 4.0 change DIA expectations compared to earlier ASPICE versions?

ASPICE 4.0 sharpened the expectations around supplier interfaces in SUP.1, MAN.3, and the ENG process group, with assessors expecting explicit, work-product-level interface definitions rather than program-level statements. The practical effect is that DIAs which passed under earlier interpretations now require item-level scoping, named tools, and documented confirmation responsibilities to score the same capability level.

Who should own the DIA inside our organization?

Joint ownership is the defensible pattern. Engineering owns the work-product definitions and exchange formats. Functional safety owns the confirmation measures and independence basis. Quality owns the configuration management and change-control procedure. Procurement owns the contractual envelope. A DIA owned by one function alone typically fails one of the four common audit modes within the first program cycle.

How long does it take to remediate a weak DIA on a program already in flight?

On programs with most safety artifacts in place, a focused DIA remediation typically runs as a weeks-scaled audit rather than a multi-month rewrite. The accelerator is treating the DIA as a focused audit, fixing only the gaps that pose audit-stop risk, and pulling them in parallel with other safety-case work rather than serially.

About LHP Engineering Solutions

Since 2001, LHP Engineering Solutions has helped companies deliver technology that must perform as intended, every time. Our clients operate in safety-critical, operation-critical, and mission-critical environments such as on-highway, off-highway, aerospace, defense, and oil & gas, where failure is not an option, and delays cost market share.

LHP helps organizations design, architect, validate, and monitor complex systems. Our global team of engineers supports the development of advanced technologies, including high-voltage power electronics, hybrid and electric powertrain controls, connectivity, and ADAS platforms, enabling OEMs and Tier-1 suppliers to bring next-generation products to market quickly and with confidence.

In compliance-driven industries, LHP uses our model-based systems engineering (MBSE) approach, enhanced through AI, to help companies move quickly while meeting rigorous standards, including functional safety, ASPICE, and cybersecurity. Our teams have helped global technology companies achieve functional safety certification and ASPICE compliance in months rather than years, and established enterprise-grade safety and cybersecurity management systems for leading OEMs.

When organizations must make major technology leaps, such as launching next-generation platforms, future-proofing vehicle architectures, or proving new concepts to secure market-defining programs, LHP delivers the engineering disciplines, solutions, and on-time execution required to succeed.

Because in industries where technology must perform as intended, precision engineering matters.