Cybersecurity Interface Agreements (CIA) Under ISO/SAE 21434 Clause 7: Template and Negotiation Guide

Most Clause 7 audit findings under ISO/SAE 21434 and UNECE R155 do not trace back to engineering work. They trace back to a Cybersecurity Interface Agreement that was negotiated late, copied from a Functional Safety template, and never refreshed after the first vehicle programme. The supplier knows what they think they owe; the customer knows what they think they own; and when an incident or an audit forces the gap into the open, the CIA is what the parties argue over. This post is a working guide to writing a CIA that survives both. It is not legal advice — it is process and engineering guidance from the Cybersecurity Manager seat.

What ISO/SAE 21434 Clause 7 Actually Says

Clause 7of ISO/SAE 21434:2021 covers “distributed cybersecurity activities” — any cybersecurity work shared between customer and supplier. Sub-clauses 7.4.1 (capability assessment), 7.4.2 (request for quotation cybersecurity content), 7.4.3 (alignment of cybersecurity responsibilities), and 7.4.4 (Cybersecurity Interface Agreement) form a single workflow. The CIA is the only Clause 7 work product and is registered in Annex E as WP-07-01. The clause is short — three pages of standard text — but the consequences are large because it sits at the boundary of every supplier interface in a programme.

CIA Scope Coverage

A defensible CIA covers seven activity domains. Threat Analysis and Risk Assessment scope and inputs (who supplies the item definition, who runs the TARA, how decisions are reviewed). Verification and Validation responsibility split (penetration testing, fuzzing, integration testing, vehicle level red-teaming). Vulnerability handling — coordinated vulnerability disclosure, triage timelines, patch decision-rights. Incident response — notification, containment, communications, root cause. Release decisions — who can release, under what cybersecurity gate, with what evidence package. Information sharing — channels, classification, retention, and disposal. Audit rights — scope, frequency, on-site versus document, third-party observers.

The Responsibility Allocation Matrix

The single most useful section of a CIA is a RASIC matrix that allocates every cybersecurity activity across OEM, Tier-1, and Tier-2 columns. The matrix below is illustrative only — it is a starter pattern, not a real customer mapping. Real allocations depend on the item definition, supplier capability, and programme phase. The legend uses the standard RASIC convention: R Responsible (does the work), A Accountable (owns the outcome, single name per row), S Supporting (contributes), I Informed (kept in the loop), C Consulted (must approve before action).

Supplier Capability Expectations (Clause 7.4.1)

Clause 7.4.1 requires that the customer assess each cybersecurity-relevant supplier's capability before award. The assessment covers Cybersecurity Management System maturity, evidence of past TARA work, the supplier's own incident response and vulnerability management processes, and the auditable trail of past releases. The capability assessment outcome — pass, pass-with-compensating-controls, fail — is what justifies the RASIC split and the audit-rights scope in the CIA. Where a supplier is capability-light (a typical Tier-1 in a new domain, or an Indian two-wheeler OEM's first connected programme), compensating controls usually take the form of expanded joint review meetings, embedded resident engineers, or a dual-sign-off requirement on Risk Treatment decisions.

RFQ Cybersecurity Content (Clause 7.4.2)

The RFQ stage is where the CIA's negotiating position is actually set. Clause 7.4.2 requires that cybersecurity expectations — the scope of work, the deliverables expected from the supplier, and the cybersecurity-relevant evidence that the customer will rely on — be communicated in the RFQ. CIAs negotiated post-award almost always end up in a weaker position for the customer because the supplier has already booked the programme on its bid pricing and pushes back on additional process commitments. A useful internal gate is “no PO without an executable CIA template attached to the RFQ.”

Alignment of Responsibilities (Clause 7.4.3)

Sub-clause 7.4.3 calls for explicit alignment of responsibilities — the bridge between the capability assessment and the executable CIA. In practice this is a joint workshop between the OEM Cybersecurity Manager and the supplier Cybersecurity Manager, walking the RASIC row by row, surfacing items that one side assumed the other would do, and signing off on the data-handling annex. Programmes that skip this workshop typically discover the gaps during the first vehicle-level TARA review or, worse, during a coordinated vulnerability disclosure event.

Template CIA Structure

The numbered checklist below is the section structure Agnile uses internally as a starting template. Items shown with [required] status are non-negotiable for any auditable CIA; [recommended] items are programme-dependent; [optional] items appear in larger or higher-risk programmes.

Information-Sharing Protocol

The information-sharing annex specifies four parameters for every category of cybersecurity-relevant artefact: channel, classification, retention, and disposal. Channel defines the transport — a shared secure portal, encrypted email with PGP keys, an ALM-integrated workflow, a hardened SFTP drop. The recurring failure here is informal channels: ad-hoc Teams chats and personal email accounts that defeat audit and data-classification controls. Classification labels each artefact (public, internal, confidential, OEM-restricted, supplier IP, regulated personal data) and binds the handling rules. Retention defines how long each class is kept; under R155, post-production evidence retention is at least 10 years, and the CIA must align with that. Disposal specifies cryptographic erasure, physical destruction, or certified deletion procedures at the end of retention. Programmes that punt the disposal question typically discover during the first end-of-cybersecurity-support transition that nobody is contractually responsible for destroying historical TARA evidence — which is itself a data-protection finding.

Audit Rights in Practice

Audit rights look identical on paper across most CIAs; they diverge sharply in practice. The clauses that matter are scope (what activities are auditable — TARA evidence, supplier CSMS, sub-tier flow-down), frequency (annual, triggered by incident, or both), notice (working-days advance notice for non-incident audits), location (on-site versus remote document review), and observer rights (can the OEM bring the type-approval authority's technical service to a supplier audit?). Programmes that exercise audit rights at least once a year — even on a sample basis — keep them credible and surface integration gaps before regulators do. Programmes that retain unexercised audit rights find them collapse the first time they are tested.

Common Failure Modes

Six failure modes recur often enough to be worth pre-empting. Vague risk ownership— “supplier shall ensure cybersecurity” — fails the Clause 7.4.3 alignment test on its face. Missing incident-response SLAs— the most cited Clause 7 audit finding — surfaces only during the first incident, when the answer to “how fast must you acknowledge?” is “the contract is silent.” Paper audit rights — audit clauses that are technically present but practically unexercised — fail surveillance audits because there is no track record of exercise. Classification gaps in the data-handling annex collide with GDPR and India DPDP Act obligations. RASIC holes — activities not listed at all, or listed with no Accountable column — create the gaps that incidents flow into. No Tier-2 cascade — where the Tier-1's upstream contracts do not flow the OEM's obligations through — collapses under R155 supply-chain expectations.

Negotiation Dynamics

Negotiating power on a CIA is not symmetric. OEMs negotiating with German Tier-1 suppliers typically face a counterparty with mature CSMS and strong opinions on data handling; the negotiation is line-by-line on incident SLAs, audit rights, and liability caps. OEMs negotiating with a capability-light supplier face the opposite: the supplier accepts most CSMS expectations but cannot meet them without compensating controls. Liability caps vary widely by region and by programme volume; the recurring rule is that uncapped liability for cybersecurity is rarely accepted by either side, but cap multiples on the affected programme value — typical ranges run from 1x to 3x — are negotiable. Insurance coverage for cybersecurity-triggered recall and product liability is increasingly demanded as a CIA condition.

Three negotiation patterns recur. First, the incident-SLA argument — suppliers push for longer acknowledgement and triage windows; OEMs push for tighter ones bound by the regulatory notification deadlines that apply to them. Aligning the SLA with the binding regulatory clock (and the contractual penalty for missing it) is the cleanest way out. Second, the audit-rights argument — suppliers push for paper rights with restrictive notice; OEMs push for surprise rights with broad scope. The workable compromise is a documented annual audit plus incident-triggered audit with shorter notice. Third, the IP-handling argument — suppliers fear that broad evidence sharing exposes their proprietary algorithms and HSM integration code; OEMs need enough evidence to satisfy type-approval. The compromise is graded evidence packaging: full design evidence held at the supplier site under audit, summary evidence held by the OEM.

Downstream Cascade

The CIA cascades upstream. A Tier-1's CIA with the OEM imposes obligations that the Tier-1 must flow through to its Tier-2 silicon vendors and software suppliers. The cascade typically covers data-handling, incident notification, vulnerability disclosure, and audit rights — but it can also include flow-down of TARA inputs and specific Annex 5 mitigations from UNECE R155. Cascade fails most often when the Tier-1 negotiates each Tier-2 contract bilaterally without a master template. Standardising the cascade clauses inside the Tier-1 is the single highest-impact fix.

Living-Document Discipline

The CIA is not a procurement artefact. It must be reviewed annually at minimum and revised on any material change — new ECU, new connectivity channel, new supplier site, new regional regulation. A common operational pattern is a joint annual review meeting between the OEM and Tier-1 Cybersecurity Managers, scheduled to coincide with R155 surveillance audit preparation. Maintenance of the RASIC matrix is the most-skipped activity; programmes that treat the matrix as part of the change-management process keep it accurate, programmes that treat it as a contract annex do not.

Jurisdictional Variations

The data-handling annex is the section that varies most by jurisdiction. EU GDPR Article 28 imposes specific processor obligations; India's DPDP Act 2023 §8 imposes data-fiduciary obligations; Japan's APPI and California's CCPA each have their own consent and data-residency rules. Multi-region OEMs typically attach jurisdictional addenda rather than re-writing the main body. The operational point is that data residency and incident-notification timelines flowing from these laws are tighter than R155's own requirements, and they bind the CIA's incident-response SLAs.

Where Agnile Fits

Agnile's cybersecurity managers draft, review, and negotiate Cybersecurity Interface Agreements for global OEMs and Tier-1 suppliers. The deliverable typically includes the CIA itself, the supporting RASIC matrix, the data-handling annex per jurisdiction, and the Tier-2 cascade template. For technical context, see the ISO/SAE 21434 pillar guide and the ISO/SAE 21434 lifecycle work products checklist. For the up-to-date manual-versus-automated TARA cycle-time context that drives the V&V split in the RASIC, see the manual versus automated TARA comparison.