The software industry is developing the institutional layer that other consequential technologies acquired as they matured. Professions, standards bodies, technical foundations, industry alliances, assurance providers and international standards are appearing across the disciplines software now touches. This is a follow-on to an earlier piece arguing that software is growing up. The evidence for that argument has since become substantially clearer, and it comes from a pattern the software industry has seen before in other technologies that became too important to remain governed by convention alone.
Some of it is brilliant. Some of it sucks.
It experiments. It moves quickly. It challenges assumptions. It sometimes has confidence ahead of judgement. And every so often it discovers why somebody told it not to do something in the first place.
That's not a criticism of innovation. A lot of what made software extraordinary came from precisely this freedom to experiment, ship quickly, break things, learn, and try again. The industry's cultural willingness to move fast built most of what we now take for granted.
The question, though, is what happens when something built with that culture becomes the infrastructure underneath banking, healthcare, transport, government, commerce and everyday life. Adolescent behaviour is defensible in an emerging industry. It's more complicated when the industry has already become foundational.
In The Software Industry Is Growing Up, I argued that software's increasing importance inevitably brings greater expectations around evidence and accountability. Customers, regulators, insurers, investors and boards were beginning to expect the discipline that other mature industries developed as they scaled.
Since writing that piece, I've started noticing something else.
The institutions of adulthood are appearing around it.
Last week I attended the inaugural forum of the TASP Alliance at Cambridge Tech Week. The discussion covered continuous assurance, accountability, liability, certification and the roles of government, academia, industry and insurers in assuring software built by AI. TASP Alliance itself is brand new, currently developing a framework, planning working groups and regional events, with backing from PwC and interest from UK government policy departments.
The important thing about the Cambridge moment wasn't just "here is another new organisation." It was the question that followed:
Why do I suddenly keep encountering organisations like this?
That question triggered a piece of research into the wider landscape. The pattern turned out to be more consistent than I had realised, and it maps to something the software industry has seen in other technologies before.
Commercial aviation had enormous innovation and commercial potential in its early decades. What it did not have, initially, was the surrounding governance and assurance infrastructure that scale demanded. Some of what needed to happen came from government. Some of it came from industry participants themselves recognising that common safety standards, professional disciplines and accident investigation processes were necessary if aviation was going to grow into something people trusted enough to use routinely.
Over time, aviation acquired an ecosystem that looks roughly like this: regulation, licensing, certification, airworthiness standards, professional disciplines, accident investigation, international standards, independent assurance, and continuous safety improvement. The industry didn't stop innovating. It built institutions around innovation that allowed the innovation to scale into something the wider public could rely on.
Electricity followed a similar path in a different form. Independent testing and certification became so normal that consumers barely think about the institutional machinery behind an electrical safety mark. Automotive engineering, pharmaceuticals, food safety, telecommunications: each in its own way went from craft to industry to institutionally-supported infrastructure.
The pattern is:
Innovation, then scale, then consequences, then scrutiny, then specialist knowledge, then institutions, then standards, then assurance, then evidence.
The honest limit of the analogy: I am not claiming software equals aviation on risk consequences. The risk profiles are different, the failure modes are different, and the operational disciplines are different. The comparison is institutional maturation, not risk equivalence. What we're looking at is how consequential technologies acquire the infrastructure that lets them scale responsibly, and software is now visibly acquiring parts of that infrastructure.
There is a small irony here worth naming. Aviation's whole institutional apparatus grew up around safety, because safety became the industry's non-negotiable. Software is now having its own safety conversation, particularly around AI, at exactly the moment its wider institutional layer is forming. The parallel is not accidental.
If institutional infrastructure only appeared when governments imposed it, we could reasonably describe it as regulation catching up with innovation. That framing misses something important about the current moment.
The frontier AI companies are themselves publicly asking for structural oversight of the sector.
OpenAI's CEO Sam Altman testified before the US Senate in May 2023 and explicitly proposed the creation of a federal agency to license powerful AI systems, set safety standards, and require independent audits from experts unaffiliated with either the creators or the government. That was not a defensive concession. It was a positive proposal for structural regulation of the industry the company itself leads.
Anthropic's CEO Dario Amodei has taken a similar or stronger position. In a 2026 essay, Amodei argued that governments should have the power to block dangerous AI deployments if they don't meet safety standards, comparing frontier AI models directly to airplanes: "Frontier AI models, like airplanes, should be required to go through technical testing and auditing, and their release should be blocked or reversed as a threat to public safety if they do not meet high standards of safety." An AI company CEO invoking the aviation model is exactly the parallel this article is drawing, made publicly by one of the people building the technology.
At the same time, other parts of the industry are pushing in a different direction. NVIDIA's CEO Jensen Huang has publicly argued against premature restrictions on open-weight AI models, warning that heavy-handed regulation risks pushing innovation overseas and concentrating frontier capability inside a small number of closed providers. In July 2026, Huang coordinated a coalition letter signed by more than twenty technology companies including Microsoft, Meta, Mozilla, Hugging Face and Palantir, advocating for continued development of both frontier closed and open-weight AI models, and urging policymakers to keep advanced model weights accessible.
What this means for the wider picture: the software industry is no longer having an adolescent argument about whether accountability matters. It is having a considerably more adult argument about what accountability should look like, who participates in it, what remains open, who performs assurance, and what evidence should be required.
Growing up doesn't mean becoming boring. It means working out which freedoms are worth preserving and which responsibilities come with them. That is the conversation currently under way across frontier AI, and it's the same conversation happening less visibly across the rest of the software industry.
The clearest evidence for the argument comes from looking at what has actually formed around software over the last twenty-five years. The ten organisations below are not a directory. They are evidence of a pattern.
Privacy and AI governance. IAPP was founded in 2000 and reports more than 90,000 members across more than 150 countries. It began as a privacy professional association and has extended into AI governance and digital responsibility as those disciplines matured into recognisable professions with their own credentials, education and career paths.
Trust and safety. TSPA serves a global community of trust and safety practitioners, with origins in the community that formed around the 2018 Content Moderation at Scale conference. Alongside it, DTSP launched in 2021 as an industry partnership around trust and safety practices, and in 2025 its Best Practices Framework was aligned with the publication of ISO/IEC 25389 as an international standard. That's an unusually clean maturation sequence: industry problem, industry practices, common framework, external scrutiny, international standard.
Accessibility. IAAP was founded in 2014 and now operates as a global professional association for accessibility practitioners, with credentials and educational programming that includes explicit work on European Accessibility Act implementation. Accessibility used to be treated as a final-audit item; increasingly it is treated as an engineering and product discipline present from the start of a project.
Software supply chain security. OpenSSF was founded in 2020 under the Linux Foundation with founding members including GitHub, Google, IBM, JPMorgan Chase, Microsoft, NCC Group, OWASP Foundation and Red Hat. It now maintains an Open Source Project Security Baseline, provides secure-development education, and runs a Global Cyber Policy Working Group with implementation resources around the EU Cyber Resilience Act.
AI assurance. AI Verify Foundation launched in Singapore in 2023 as a non-profit wholly owned by Singapore's Infocomm Media Development Authority. Its Global AI Assurance Sandbox lets organisations deploying generative AI work with specialist technical testers, and its Project Moonshot initiative provides practical GenAI evaluation and testing infrastructure. This is AI governance moving beyond published principles into testable technical assurance.
Age assurance. AVPA was formed in 2018 and now represents more than 35 organisations providing age-assurance solutions globally. Its policy work spans the EU Digital Services Act, UK and Australian Online Safety Acts, US COPPA and state age-design laws, India's data-protection regime, and other national systems. Age assurance has become a distinct technical and commercial category with its own suppliers, conformity assessment and industry association.
Cloud and AI security. Cloud Security Alliance was founded in 2009 and operates across the Americas, APAC, EMEA and China. Its STAR programme combines self-assessment with certification and third-party attestation, and publishes assessments in a public registry. In 2025 it introduced its AI Controls Matrix alongside the long-running Cloud Controls Matrix, and in 2026 formally launched the separate CSAI Foundation devoted to AI security, safety and trust.
Child safety. Technology Coalition was founded in 2006 and now brings together more than 50 technology companies around online child protection. Its recent operational work includes cross-industry tools such as Lantern rather than purely policy advocacy, demonstrating institutionalised cross-platform implementation.
App economy policy. ACT | The App Association represents startups, scaleups and small and medium-sized technology companies in policy debates that increasingly shape how the app economy operates. US-founded but genuinely multi-territory, ACT engages with policymakers across the EU as well as the US on the specific issues that disproportionately affect smaller technology companies: platform regulation under the Digital Markets Act and Digital Services Act, AI Act implementation, GDPR and data policy, digital fairness, standard-essential patents, and cross-border regulatory harmonisation. The multi-territory reach is a meaningful asset in itself, because most substantive compliance policy now crosses borders, and smaller technology companies without dedicated policy teams have had no organised way to engage with parallel regulatory processes in different jurisdictions until institutions like ACT started providing that representation.
Add TASP Alliance to that list as the newest example. The pattern is not a handful of similar organisations. It's an ecosystem containing professional bodies, technical foundations, trade associations, industry partnerships, standards bodies and assurance providers. That diversity is itself the point. A mature ecosystem does not produce one compliance organisation. It produces many, each specialised for a different accountability discipline.
Looking across the ten organisations above, a consistent sequence of maturation stages becomes visible. Different disciplines are at different stages, but the sequence itself is remarkably consistent across them.
Stage one: new obligations become specialist knowledge. Privacy, accessibility, trust and safety, supply chain security, AI governance and age assurance have all become too specialised for a general software engineer or occasional legal review to cover adequately. The complexity crossed a threshold where dedicated expertise became necessary.
Stage two: specialist knowledge becomes a profession. It acquires job titles, communities, conferences, continuing education and credentials. IAPP is the clearest example of this stage completed at scale. IAAP demonstrates it happening in accessibility. TSPA shows it happening in trust and safety in real time.
Stage three: principles become frameworks and controls. "Keep users safe" is not operationally useful. DTSP specifies processes. OpenSSF creates minimum security baselines. CSA turns cloud and AI risk into control matrices. AVPA develops industry conformity mechanisms. Broad aspirations get translated into repeatable operational practices that can be described, taught, implemented and reviewed.
Stage four: controls begin to require evidence. Self-assessment starts being supplemented by attestation, testing, certification and independent verification. CSA distinguishes self-assessment from third-party attestation. AI Verify brings specialist technical testers into an assurance sandbox. OpenSSF's baseline defines minimum requirements rather than aspirations. The industry moves from declaration toward demonstration.
Stage five: frameworks converge with regulation and international standards. DTSP's alignment with ISO/IEC 25389 is a particularly clean example. OpenSSF's cyber policy work produces implementation material for the EU Cyber Resilience Act. IAAP's 2026 European work connects accessibility practice directly with European Accessibility Act obligations. Industry practice, professional standards and legal requirement start pointing in the same direction.
Stage six: compliance moves earlier into engineering. IAAP explicitly talks about "shift-left" accessibility. OpenSSF addresses secure software development from the start of a project. AI Verify provides testing tools that engineers can use during development. The compliance question stops being "what paperwork do we have" and starts being "what are we building and shipping".
Different disciplines within software are at different points along this sequence. Privacy is a long way through. Trust and safety is moving quickly. AI assurance is at earlier stages but progressing rapidly. The important observation isn't which discipline is where. It's that all of them are visibly moving along the same maturation path.
Aviation provided the historical macro-pattern. These six stages describe the software-specific micro-pattern. Together they explain why the institutional layer is emerging now, and why it is likely to keep emerging across further disciplines the industry will need to formalise in the years ahead.
Software governance is a useful umbrella term for what the ten organisations above collectively cover, but it's worth being precise about what "governance" now means in practice for the software industry.
It is not one new profession. It is an ecosystem of professions.
Privacy, accessibility, trust and safety, software supply chain security, AI governance, age assurance and platform policy increasingly have different specialists, different vocabulary, different frameworks and different evidence requirements. A software organisation with meaningful exposure to any of these disciplines increasingly needs specialists (or specialist advisers) who understand that specific discipline in depth. A software organisation with exposure to several of them needs several specialists, or specialist teams, or increasingly specialist tooling to support them.
Software assurance is the machinery developing beneath software governance. Assurance in this sense means the mechanisms that produce evidence about what software actually does, rather than what it is declared to do. Certification, testing, attestation, independent audit, technical baselines, continuous monitoring and public registries are all different forms of assurance appropriate to different accountability disciplines. As with governance, the significant change is that software has moved from having almost no assurance infrastructure to having recognisably specialised assurance infrastructure across multiple disciplines simultaneously.
Neither software governance nor software assurance is a single thing. Both are becoming ecosystems of specialised disciplines that collectively describe how mature software gets built, shipped and evidenced. That is the shift the ten organisations above are collectively demonstrating.
Of all the disciplines maturing right now, AI assurance is the one where the process is visible almost month by month. It's worth naming what's happening because it captures the wider pattern in an unusually concentrated form.
The institutional layer is forming. AI Verify Foundation runs a Global AI Assurance Sandbox connecting organisations deploying generative AI with specialist technical testers. Cloud Security Alliance's AI Controls Matrix extends its control-and-assurance model into AI, and functions as an AI governance framework organisations can map their own controls against. CSA formally launched the separate CSAI Foundation in 2026 devoted specifically to AI security, safety and trust. These are the institutional building blocks of AI assurance appearing in real time.
The industry is asking for external oversight. OpenAI publicly proposed federal licensing of powerful AI systems and independent audits during Senate testimony. Anthropic has consistently advocated for stronger regulation, comparing frontier AI directly to aviation and arguing that governments should have the power to block deployment of unsafe technology.
The industry is also arguing about openness. NVIDIA and a coalition of more than twenty technology companies have advocated for continued availability of open-weight AI models, warning that overly restrictive frontier AI regulation could concentrate capability in a small number of closed providers and push innovation overseas. The coalition letter signed by Microsoft, Meta, Mozilla, Hugging Face and Palantir alongside NVIDIA argues that open models strengthen safety and cybersecurity, accelerate innovation, and enable sovereignty.
The point for the wider argument: the AI governance question is no longer whether governance should exist. It is what governance should look like, who participates in it, what remains open, who performs assurance, and what evidence should be required. That is exactly the kind of question a maturing industry asks. It is not the question of an industry avoiding accountability. It is the question of an industry working out how to hold itself accountable while preserving what made it valuable in the first place.
AI is not the only discipline moving through this sequence. Two others worth naming briefly, because they show the same pattern applied to different domains with different underlying dynamics.
Age assurance. Ten years ago, most app teams would not have listed "age assurance architecture" alongside authentication, payments or analytics as an engineering discipline. Today it is a distinct technical and commercial category. AVPA's membership includes more than 35 organisations providing age-assurance solutions. The European Commission's age verification blueprint released in July 2025 is a concrete example of age-related obligations becoming technical architecture rather than remaining policy statements. Age assurance now involves privacy design, identity infrastructure, user experience, safety considerations and regulatory implementation across multiple jurisdictions simultaneously. That is a mature engineering and compliance discipline forming from what was, quite recently, a set of scattered regulatory requirements.
Software supply chain security. Software has always been assembled from components. What is newer is the industrialised expectation that organisations know what components their software contains, where they came from, whether they have been tampered with, what obligations they carry, and what the organisation would do if a component turned out to be compromised. OpenSSF's Open Source Project Security Baseline is a technical minimum for open-source projects. The EU Cyber Resilience Act is a regulatory framework that will impose specific requirements on software products placed on the European market. Both are examples of software supply chain security moving from an implicit expectation into an explicit, evidenced discipline.
Both of these disciplines produce the same core insight: mature software is expected to demonstrate what it actually is and does, rather than assert it. That is a shift with implications that reach well beyond the specific compliance disciplines the article has named so far.
The practical consequence for engineering teams is worth stating plainly.
Every software release now ships obligations as well as features.
Adding an SDK doesn't just add functionality. It can introduce privacy, data-processing and supply-chain questions that the organisation needs to be able to answer. Adding a permission isn't just an API call. It can trigger consent and disclosure obligations depending on the jurisdiction and the sensitivity of what the permission covers. Adding an AI capability isn't just another feature. It can introduce governance and assurance questions that were not part of the product's previous compliance picture. Adding social functionality can create trust and safety questions. Adding age-sensitive functionality can trigger age-assurance requirements. Entering a new territory can change the applicable regulatory environment for functionality that was compliant elsewhere.
This is the shift-left engineering pattern that IAAP, OpenSSF and AI Verify all describe from different angles. Compliance work that used to happen at the end of a project, or at an annual audit point, is increasingly work that needs to happen during design and development. The reason is not primarily that regulators demand it. The reason is that periodic compliance review cannot keep up with software that ships continuously across the disciplines described above.
Everyone Talks About Technical Debt. Nobody Talks About Legal Debt covers the accumulation pattern that shift-left engineering is a response to. Ordinary product decisions (adding an SDK, changing a permission, adopting an AI model, entering an ecosystem) accumulate privacy, supply-chain, AI and governance obligations in the same way technical decisions accumulate technical debt. The remedy in both cases is visibility and continuous evidence rather than periodic reconciliation.
For engineering leaders, this changes what "shipping" means. Shipping used to mean delivering functional software that met product requirements. Increasingly it also means delivering software whose compliance implications the organisation can evidence and defend across whichever disciplines apply. That is a genuinely new engineering requirement, and it's one that most engineering organisations are still working out how to structure.
Look back at aviation, electricity, pharmaceuticals and other mature technologies. A consistent feature of their institutional maturity is the presence of independent evidence mechanisms. Certification, testing, inspection, audit, incident reporting, registries and continuous monitoring are all different forms of the same underlying principle: as industries mature, declarations from providers get supplemented (and sometimes replaced) by external evidence about what providers actually do.
Software has historically depended surprisingly heavily on declarations. Vendors declare their compliance posture. Developers declare their data practices. Organisations declare their controls to their auditors. The declarations are then reviewed periodically and either accepted or challenged.
The institutional evidence in this article suggests that pattern is changing. CSA's STAR programme combines self-assessment with independent attestation and publishes assessments in a registry. AI Verify brings specialist testers into an assurance sandbox. OpenSSF defines minimum technical baselines that can be measured against actual project state rather than declared. DTSP's ISO/IEC 25389 alignment moves platform trust and safety toward formal external standardisation. Each of these is an example of software moving along the same path other mature industries have walked: from declaration toward demonstration.
Perhaps software's next stage of maturity isn't primarily more regulation. It's better ways of producing evidence about the software we're actually shipping. That's a substantially harder problem than declaring compliance intent, but it's also the problem the institutional layer described in this article is collectively working to solve.
Aviation acquired insurance infrastructure alongside its regulatory and assurance infrastructure. Aviation insurance is not a footnote to aviation safety. It's one of the mechanisms by which airworthiness standards get enforced in commercial practice. Underwriters price risk based on operator certification, maintenance records, incident history and independent audit, and that pricing pressure reinforces the standards. Organisations that maintain higher standards get better insurance terms, and organisations that don't often become uninsurable or priced out of routine operation.
Software already has an early version of this pattern in cyber insurance. Getting a meaningful cyber insurance policy today typically requires demonstrable evidence of specific controls: multi-factor authentication, endpoint detection and response, vulnerability management, incident response planning, and increasingly external attestations such as SOC 2 or ISO 27001 certification. Cyber insurers do not accept declarations at face value. They require external audits, technical scans, and evidence that the controls exist and are operating. Cyber insurance became one of the earliest market forces pushing software from declaration toward external evidence, and it did so without waiting for regulators to require it.
The direction of travel is clear. As software liability becomes more concrete across additional disciplines (AI, product safety, supply chain, accessibility), insurance is likely to become a more significant force in each of them. Insurers pricing risk in AI systems will need evidence about how those systems behave, what data they use, and what safeguards are in place. Insurers pricing product liability for software supply chains will need evidence about component integrity, provenance, and release discipline. Each will drive its own version of the pattern cyber insurance has already established: external evidence supplied by specialist providers, priced into commercial terms, reinforcing the standards developed by the professional and technical institutions this article has described.
The TASP Alliance forum at Cambridge included insurers explicitly as one of the four categories the AI assurance conversation needs to engage: government, academia, industry, and insurers. That framing is right. Insurance is not a bolt-on to the accountability ecosystem. In every mature industry that has one, it's a load-bearing structure of it, and there's no reason to expect software will be different.
Mobile apps are an unusually clear lens through which to see the wider pattern, because they change continuously and combine first-party code with SDKs, permissions, APIs, privacy declarations, operating-system capabilities and jurisdiction-specific platform rules. Each mobile release touches multiple of the disciplines this article has covered, and each release ships evidence (or the absence of evidence) about how the app handles each of them.
Appnalysis is not trying to become another software governance body or compliance framework. That work belongs to the institutions in this article and the specialists they represent. Our role is further down the stack: making observable facts about mobile software easier to see, interrogate and evidence, so that the compliance and legal specialists interpreting those facts have a better technical fact pack to work from.
The aim, over time, is to provide for mobile apps what Bloomberg provides for financial markets: an aggregated evidence layer that turns scattered signals into an interrogable resource. That ambition is still being built rather than complete, but it matches the direction the institutional evidence in this article is pointing. As software governance becomes an ecosystem of professions, and as those professions increasingly require evidence rather than declarations, tools that produce continuous observable evidence about mobile software become more useful, not less.
For teams already working on the mobile compliance dimension of this pattern, Compliance Automation Software for Mobile Apps covers the evidence-layer question in depth, and Roadmap: Getting Your Mobile Compliance Right covers the structural approach compliance leads can use.
I've joked for years that software is going through adolescence.
Perhaps the interesting thing is that we're now beginning to see what comes next.
Not the end of experimentation. Not an industry where nobody takes risks. And certainly not universal agreement about regulation, openness or oversight. Instead, professions are appearing. Standards are developing. Assurance mechanisms are forming. Frontier AI companies are publicly asking for external oversight while others advocate for continued open-model access. Governments, insurers, academics and industry are working out their respective roles.
We've seen versions of this before in aviation, electricity, pharmaceuticals and other technologies that became too important to remain governed primarily by convention and trust. Software is now visibly acquiring its own version of that infrastructure, and the process appears to be accelerating.
Software isn't just growing up. The institutions of adulthood are appearing around it.
If you're building products, running compliance work, or thinking about where the software industry goes next, we'd be interested to hear how these patterns show up in your world.