Title: The Development Interface Agreement: Who Owns What in ISO 26262 | ISO 26262 Academy URL: https://iso26262.academy/blog/development-interface-agreement-iso-26262-who-owns-what Description: The ISO 26262 Development Interface Agreement explained: when you need one, what it contains and how it fails, on a battery management system example. --- [Technical](https://iso26262.academy/blog/category/technical) # The Development Interface Agreement: Who Owns What in ISO 26262 ![Three engineers share one laptop at a vehicle test rig with a steering wheel and wiring harnesses around them.](https://academy-videos.fra1.digitaloceanspaces.com/blog/images/2026/10/a02d6a4f-8021-4d00-9521-b69a33dea054-1920.webp) Nobody develops the whole item. Safety still has to hold across the vehicle maker, the supplier, the chip vendor and the software house. The Development Interface Agreement is how ISO 26262 makes that work: who does which safety activity, who is responsible, what is exchanged, and what happens when something goes wrong. New article, worked through on a battery management system: where an agreement is needed, where it is not, and the four questions it has to answer. ![ISO 26262 Academy](https://iso26262.academy/logo.png) ISO 26262 Academy 27 October 2026 4 min read Share Text size In most vehicle programs, nobody develops the whole item. The vehicle maker owns the function, a supplier builds the controller, a semiconductor company supplies the chip that carries the safety mechanisms, and somewhere in between a software house writes part of the code. Functional safety still has to hold across all of them. The document that keeps it together is the Development Interface Agreement, or DIA, defined in ISO 26262-8:2018, Clause 5. A DIA does one thing: it states who does which safety activity, who is responsible for what, and what crosses the interface between them. Each party keeps its own safety plan, and the DIA is what makes those plans fit together. ## Where a DIA is needed, and where it is not Take a battery management system for an electric vehicle. The vehicle maker defines the item and the safety goals. A tier 1 supplier develops the BMS. That supplier buys a cell-monitor chip off the shelf, and subcontracts part of the BMS software to a smaller company. ![The supply chain of a battery management system. The vehicle maker and the BMS supplier each keep a safety plan, joined by a Development Interface Agreement. The BMS supplier and a contract software house that writes part of the BMS software are joined by a second agreement. A cell-monitor chip bought off the shelf and developed as a Safety Element out of Context has no agreement; instead its safety manual and assumptions flow to the BMS supplier, who checks them against the real use.](https://academy-videos.fra1.digitaloceanspaces.com/blog/diagrams/2026/10/97214206-c98e-41d1-9424-3bf9f0f88b4f.svg) Figure 1. A DIA at every level where safety work is commissioned; an off-the-shelf SEooC brings a safety manual instead. The vehicle maker and the BMS supplier need a DIA. So do the BMS supplier and the software house, because the requirement applies at every level of the supply chain, and internal suppliers can be handled the same way. The cell-monitor chip is different. It is not built to order, and if it was developed as a safety element out of context, no DIA is required. A chip without that route only qualifies for the exemption if it is both qualified to an established component standard and evaluated as Part 8 describes. What replaces it is the chip's safety manual and its assumptions of use, which the BMS supplier has to check against the real application. A DIA is also not needed for a purchase that puts no safety responsibility on the supplier at all, such as a standard connector. Keep learning [Free course preview Development Interface Agreement](https://iso26262.academy/features/concepts/development-interface-agreement) [Or test yourself with the 7-question demo exam](https://iso26262.academy/demo-exam) ## It starts before the contract The interface begins with the request for quotation. The standard expects it to ask for compliance with ISO 26262, define the scope of supply, and pass on the safety goals or safety requirements with their ASIL. If the ASIL is not known yet, a conservative assumption is acceptable. Where they are already available, the hardware target values for failure rates and diagnostic coverage go in too. Supplier selection should also look at whether the supplier has delivered comparable complexity at a comparable ASIL before. A supplier who quotes against "ISO 26262 compliant, ASIL to be defined" is quoting against nothing. The cost of the safety work depends on the ASIL, and both sides know it. ## What goes into the agreement The clause lists the content item by item, and it is long. It is easier to hold in your head as four questions the agreement has to answer. ![Four questions every Development Interface Agreement has to answer, each with one example. Who is accountable on each side and who checks the supplier's work, for example the two safety managers. Which party performs which safety activity, for example who runs safety validation. What crosses the interface in both directions, for example hardware metric targets. Who hears about a problem, how fast and who acts, for example an anomaly at a subcontractor.](https://academy-videos.fra1.digitaloceanspaces.com/blog/diagrams/2026/10/00ebd7dc-5856-4278-bdfc-297b27497abb.svg) Figure 2. Every item the standard lists for a DIA answers one of four questions. **Who** is accountable on each side, and who checks the supplier's work? **What** does each party do? **What crosses** the interface, in both directions? And **what happens when something goes wrong**, from an anomaly at a subcontractor to a requirement the supplier cannot meet? One rule in there surprises people: if the supplier performs the hazard analysis, the customer still verifies and approves it. The safety goals stay the vehicle maker's responsibility. ## Signed is not the same as working Most DIAs that fail do not fail on content. They fail because the agreement was negotiated by purchasing as a contract annex, and the engineers who should work to it have never opened it. A responsibility matrix that marks both parties responsible for half the activities, or an anomaly rule that says nothing about timing, reads fine at signature and breaks the first time something goes wrong. The [Development Interface Agreement](https://iso26262.academy/features/concepts/development-interface-agreement) concept page covers each part of the agreement and what it means in practice, how to build a responsibility matrix that holds up, anomaly handling across tiers, the assessment and the handover to production, worked examples and a full creation checklist. ## Abbreviations & Key Definitions - **BMS** - Battery Management System. - **DIA** - Development Interface Agreement. - **RFQ** - Request for Quotation. - **SEooC** - Safety Element out of Context. Related on the Platform [Development Interface Agreement Concept](https://iso26262.academy/features/concepts/development-interface-agreement) Last updated: 27 October 2026 Tags [iso-26262](https://iso26262.academy/blog/tag/iso-26262) [iso-26262-part-8](https://iso26262.academy/blog/tag/iso-26262-part-8) [safety-management](https://iso26262.academy/blog/tag/safety-management) [seooc](https://iso26262.academy/blog/tag/seooc) [functional-safety](https://iso26262.academy/blog/tag/functional-safety) Share this article ## Read the full Development Interface Agreement concept From HARA to Safety Mechanisms - master every concept with clear, practical explanations and real-world examples. [Browse Concepts](https://iso26262.academy/features/concepts/development-interface-agreement) Keep learning ## Guides on this topic. The guide this article draws on, and where the topic leads next. [Browse all guides](https://iso26262.academy/features/concepts#library) - Foundations [Development Interface Agreement](https://iso26262.academy/features/concepts/development-interface-agreement) Learn how to define clear safety responsibilities and evidence exchange between OEM and supplier per ISO 26262-8. Covers DIA content structure, RASIC matrix, lifecycle from initiation to production, and assessment coordination. [Expert](https://iso26262.academy/pricing#plan-advanced) 14 chapters - Foundations [ISO 26262 vs Other Safety Standards](https://iso26262.academy/features/concepts/standards-comparison) Learn how ISO 26262 compares with IEC 61508, DO-178C, EN50128, ISO 13849, and SOTIF across key dimensions. Covers risk classification differences, lifecycle approaches, V&V strategies, and multi-standard compliance. [Pro](https://iso26262.academy/pricing#plan-basic) [Expert](https://iso26262.academy/pricing#plan-advanced) - Foundations [The Automotive Safety Standards Map](https://iso26262.academy/features/concepts/automotive-safety-standards-map) ISO 26262 covers hazards caused by an E/E system doing the wrong thing. Sensor limits, attackers and learned models each needed a document of their own. This is the map of how all of them fit together. [Expert](https://iso26262.academy/pricing#plan-advanced) 16 chapters ## Comments ## Related Articles [![A line of commit dots labelled as the mainline runs off the right edge. One dot is ringed in red, and a dashed line drops from it into a card holding five chips: source revision, patch list, configuration, toolchain, build recipe.](https://academy-videos.fra1.digitaloceanspaces.com/blog/images/2026/09/7be422cc-1d9b-46fa-9ced-89ad2d5d6281-1920.webp) Technical ### Qualifying Linux for ISO 26262: Pinning the Open-Source Element 9 min Sep 2](https://iso26262.academy/blog/qualifying-linux-for-iso-26262-pinning-the-open-source-element) [![Confidence in Software Tools: A Guide to ISO 26262 Qualification](https://iso26262.academy/_next/image?url=https%3A%2F%2Facademy-videos.fra1.digitaloceanspaces.com%2Fblog%2Fimages%2F2026%2F03%2Fea8e5401-aad7-4bc7-a33d-ddbfce45f263.jpg&w=1920&q=75) ### Confidence in Software Tools: A Guide to ISO 26262 Qualification 8 min Mar 5](https://iso26262.academy/blog/confidence-in-software-tools-a-guide-to-iso-26262-qualification) [![A friendly white robot works at a laptop; two glowing paths lead from it, one to a car driving on a road at dusk and one to a second laptop showing source code](https://academy-videos.fra1.digitaloceanspaces.com/blog/images/2026/10/415f35e3-f612-447b-bb1a-ce388d946926-1672.webp) Technical ### AI Coding Agents and ISO 26262: Classify the Use, Not the Tool 7 min Oct 22](https://iso26262.academy/blog/ai-coding-agents-iso-26262-classify-the-use-not-the-tool)