Recognition for Software Developers & Digital Tools A corporate quality and trust framework for automotive software developers, digital tool suppliers, integrators and service operators.
Programme status: prepared for IAF adoption The document set supports consultation and readiness planning. Effective operation requires recorded adoption, validated pilots and an operational verification route. Corporate recognition is separate from release approval and does not certify every version, AI output, integration or vehicle.
25 Common sections
10 Digital profiles
8 Risk domains
204 Identified requirements
Software and service profile map
Recognition follows real lifecycle responsibility DEV applies to every applicant. Additional profiles and risk domains are selected from the software, tool, data, deployment and live-service responsibilities actually controlled by each holder and delivering hub.
DEV Development & integration Mandatory profile for development, integration, operation or distribution lifecycle responsibilities.
EMB Embedded & vehicle software Firmware, controllers, middleware, operating platforms and vehicle functions.
ENG Engineering & simulation tools Design tools, digital twins, modelling, configuration and engineering decision support.
TST Test & diagnostic tools Bench automation, vehicle diagnostics, inspection software and result processing.
CLD Cloud & hosted services Hosted automotive applications, infrastructure services and connected back ends.
FLE Fleet & mobility applications Fleet management, telematics, charging applications, mobility services and user interfaces.
OTA Update & deployment systems Vehicle updates, package distribution, campaign control and remote deployment.
AIM AI & intelligent tools Perception, prediction, optimisation, generative assistants and autonomous agents.
CYB Security software & tools Security monitoring, testing, identity, detection and automotive cyber defence.
DAT Data products & platforms Datasets, data exchanges, marketplaces, digital distribution and integration services.
Requirement architecture
A 204-requirement digital assurance map A repository, dashboard or high test count is not proof of effective control. Every applicable requirement must link to authentic source, build, release, deployment, operation and support evidence.
Framework layer Structure Purpose
Corporate baseline 100 requirements in 25 sections Accountability, rights, requirements, architecture, source, supply chain, build, testing, release, security, data, AI and support. Software/service profiles 10 profiles × 4 requirements Adds lifecycle controls for the actual software, tool, platform, deployment, AI, security or data activity. Risk & technology domains 8 modules × 4 requirements Triggers extra controls for safety, hostile environments, privacy, AI, measurement, ecosystems, live services and legacy. Internal directives 8 directives × 4 requirements Controls eligible holders, coverage, technical review, decisions, status, appeals, confidentiality and launch assurance.
Controlled document set
Read, prepare and preserve the evidence Use the Programme Standard as the authoritative framework. The manuals, guides and controlled forms implement it and cannot weaken its requirements. Each file opens as a PDF in a new tab.
Standard & Internal Directives The full software baseline, digital profiles, risk domains, directives and annexes.
Applicant Guide Lifecycle scope, hub selection, release evidence, assessment access and readiness.
Corporate Recognition Application Holder identity, profiles, hubs, lifecycle roles, adoption and declarations.
Product & Service Scope Schedule Families, configurations, delivering hubs, deployment modes, responsibilities and exclusions.
Lifecycle & Release Dossier Requirements, source, build, validation, release, deployment, support and change evidence.
Self-Assessment & Evidence Dossier Implemented controls, outcomes, gaps, indicators and source-evidence mapping.
Software Lifecycle & Evidence Manual Practical controls for development, supply chain, builds, testing, release, AI and live services.
Assessment Checklist Assessor-facing applicability, evidence, findings and decision record.
Audit & Recognition Manual Hub and family coverage, technical review, panels, surveillance, appeals and status actions.
Status & Mark Usage Rules Authorised wording, verification, release boundaries, corrections and misuse response.
Governance & Monitoring Toolkit Controlled records for screening, audits, findings, decisions, monitoring and continuity.
Prepared decision controls
Important periods and safeguards Control Prepared period Meaning Implemented history Minimum 6 months Includes an internal audit, management review and three real events per family/hub. Recognition term Maximum 3 years Recognition remains corporate and does not extend automatically to new versions or acquisitions. Surveillance Months 12 and 24 Every hub is reviewed annually; technical facilities require physical visits. Initial decision All applicable requirements Met Every finding must be effectively closed before initial recognition. Consequential incident Within 48 hours when serious Protect users and evidence while technical impact and affected configurations are established. Appeal Within 30 calendar days A different conflict-free three-person panel reviews the challenged decision.
Build a release-linked digital evidence pack Start with the Applicant Guide, freeze the holder/hub/family boundary and connect requirements, source, dependencies, builds, validation, release and support evidence. Contact IAF before presenting any dossier as a live recognition application.