How regulation creates software categories

Guide · Market Growth · 19 min read · last verified 2026-07-21

Regulation creates a software category when a new legal requirement forces many companies to solve the same compliance problem at once, turning a scattered cost center into an addressable market. GDPR seeded consent management, SOX seeded compliance and audit tooling, and FedRAMP seeded gov-cloud.

Founders building in regulated or regulation-adjacent spaces often sense this pattern before they can articulate it: a law passes, and within a couple of years a cluster of vendors appears selling nearly identical software to the exact same buyer, at the exact same title, solving the exact same clause of the exact same statute. That's not coincidence. It's one of the more reliable mechanisms by which brand-new software categories get created, and understanding how it works is useful whether you're trying to time an entry into a regulation-adjacent space or trying to figure out why a competitor suddenly has a product that looks like yours.

This piece describes the mechanism, walks through it using well-established, named regulations as examples, and lays out what's genuinely knowable about timing a category this way versus what's speculation dressed up as strategy.

The mechanism: how a legal requirement becomes a market

Most software categories emerge slowly, through iteration on an existing workflow that a lot of companies do slightly differently. Regulation-driven categories emerge differently, and faster, because a law does something unusual to demand: it makes the same specific requirement legally mandatory, on a fixed or semi-fixed timeline, for every company that meets certain criteria — a size threshold, an industry, a geography, a type of data handled.

That combination of characteristics is what makes the resulting category distinct from a normal one. Demand isn't discovered gradually by a founder noticing a workflow problem — it's created in large volume, all at once, by a legislature or regulatory body. The buyer isn't weighing whether to solve the problem — for many of them, non-compliance carries a real legal or financial risk that removes the option to simply ignore it. And the requirement is specific enough — a named right, a named control, a named audit — that a vendor can build a product that maps almost directly onto the legal text, rather than having to guess at a workflow.

Compare that to how most B2B categories form: a handful of companies feel a pain point, a founder builds something for one of them, and the category grows customer by customer, use case by use case, often taking years before the shape of the market is legible. Regulation short-circuits a large piece of that process. The "shape" of the buyer's need is written down in a statute or a framework document before a single line of product code exists. That's a genuine head start for anyone who reads the requirement carefully and builds specifically against it — and it's also why regulation-driven categories tend to attract a wave of vendors nearly simultaneously, because the requirement is public and legible to everyone at once, not just to whoever happens to notice a customer pain point first.

Case study: GDPR and the consent management category

The General Data Protection Regulation is the European Union's data protection law. It was adopted in 2016 and became enforceable in May 2018, and it applies to any organization processing the personal data of people in the EU, regardless of where the organization itself is based. Among its requirements: a lawful basis for processing personal data, which for many use cases means obtaining and recording clear consent; rights for individuals to access, correct, delete, or export their data; a requirement to report certain data breaches; and, for organizations that meet certain criteria, a designated data protection officer.

Before GDPR, "ask a website visitor whether they consent to tracking, record that answer, and honor it across every downstream tool that visitor's data touches" was not a discrete piece of software most companies bought — it was, at best, a checkbox a developer bolted onto a signup form. After GDPR became enforceable, it became a distinct, urgent, and well-defined problem: prove a specific consent state, at a specific time, for a specific user, and be able to produce that record on request. That's a narrow, well-specified technical problem, and it's exactly the kind of problem software is good at solving.

A category of consent management platforms grew directly out of that requirement — tools that show a visitor a consent banner, record the choice, propagate that choice to connected marketing and analytics tools, and keep an auditable log. Some of the vendors now associated with broader privacy and compliance management, such as OneTrust, built significant parts of their early business around exactly this need. The category didn't stop at consent banners, either — it expanded into adjacent GDPR requirements like data subject access request automation and data mapping, because once a vendor had a foothold with a compliance buyer around one clause of the regulation, the adjacent clauses were a natural expansion path.

Case study: SOX and the compliance and audit-tooling category

The Sarbanes-Oxley Act was passed by the US Congress in 2002, following major corporate accounting scandals, and it applies to public companies. Section 404 of the act requires company management to assess and report on the effectiveness of internal controls over financial reporting, and requires an external auditor to attest to that assessment. In practice, that means a public company has to be able to demonstrate — with documentation, evidence, and a repeatable process — that its financial reporting controls actually work, year after year.

Before SOX, internal controls documentation for a lot of companies was informal: spreadsheets, emails, tribal knowledge held by a controller who'd been there a decade. Section 404 turned "demonstrate your internal controls are effective, on an ongoing and auditable basis" into a mandatory, recurring, well-specified obligation for every public company, with real consequences for getting it wrong. That's the same shape of trigger as GDPR: a specific legal requirement, applied broadly, on a recurring basis, that a generic software product could plausibly automate.

The governance, risk, and compliance software category — often shortened to GRC — grew substantially around this and adjacent requirements, covering control documentation, workflow and sign-off tracking, audit trail management, and reporting. Some of that demand was absorbed into modules of larger enterprise software suites; some of it was served by dedicated GRC vendors. Either way, the shape of the product across that category tends to map closely onto the shape of the compliance obligation it was built to satisfy — control frameworks, evidence collection, audit readiness — which is a strong tell, when you're looking at any compliance-adjacent product, that a regulation is the actual root cause of the category existing at all.

Case study: FedRAMP and gov-cloud

The Federal Risk and Authorization Management Program, established by the US federal government in 2011, standardizes the security assessment and authorization process cloud service providers must go through before federal agencies can use their products. Rather than every agency separately evaluating a vendor's security posture, FedRAMP creates a shared authorization that multiple agencies can rely on, at defined impact levels tied to the sensitivity of the data involved.

For a cloud vendor, this created a specific, expensive, well-defined gate: without FedRAMP authorization, selling cloud software to most federal agencies is effectively closed off, regardless of how good the product is. That gate created its own category of demand — dedicated gov-cloud infrastructure offerings from the major cloud providers, separate environments built to meet the control requirements, plus a smaller ecosystem of firms and tools that help vendors navigate the authorization process itself: control mapping, documentation preparation, continuous monitoring tooling required to maintain authorization once granted.

This example is a useful contrast with GDPR and SOX because the buyer isn't primarily "any company that meets a threshold" — it's specifically vendors who want to sell into the federal government, plus the agencies themselves. The category it created is narrower and more specialized as a result, but the mechanism is identical: a legal and procedural requirement, applied consistently across a large buyer set, created demand for software that didn't previously need to exist as a distinct product.

Why regulation-created categories behave differently from other categories

A handful of characteristics tend to be true of categories that get created this way, and they're worth understanding because they change how you'd approach building or competing in one.

The budget is often mandatory, or close to it, at least initially. When a purchase is driven by legal exposure rather than a productivity gain, the buying conversation is different. The pitch isn't "this will make your team faster," it's "this reduces a real, named risk you're currently carrying," which tends to compress the sales cycle for companies that have already decided compliance is non-negotiable — though it does not remove the sales cycle, and buyers in this position are often just as price-sensitive as any other, especially once the initial urgency passes and multiple vendors exist.

Timing is compressed and somewhat externally fixed. A regulation typically has an effective date, sometimes with a grace period before enforcement begins. That creates a real deadline that isn't set by the vendor or the buyer's internal planning cycle — it's set by the regulator. Vendors who are ready with a credible product before or shortly after that date have a structural advantage over vendors who show up after the initial wave of urgent buying has already happened and the market has settled into its steady state.

The requirement is unusually legible. Because the specification is written down in a public document — a statute, a regulatory framework, official guidance — the product requirements are knowable in a way that's rare in software. This is a double-edged advantage: it lowers the cost of figuring out what to build, but it also lowers that cost for every other founder reading the same document, which is why regulation-driven categories tend to see a cluster of new entrants appear on a similar timeline rather than a single first mover with a long head start.

Category boundaries tend to be set by the regulation, not by product innovation. A vendor's roadmap in this kind of category is substantially constrained and directed by the evolving interpretation of the requirement — regulatory guidance, enforcement patterns, and amendments to the underlying law — more than it would be in a category shaped purely by customer feedback and market experimentation.

Compliance buyers often want a defensible answer, not necessarily the best one. Because the underlying motivation is risk reduction, a buyer choosing between vendors is frequently optimizing for "this is a credible, well-regarded choice that I could defend to an auditor or a board" as much as for feature differentiation. That reality shapes what actually wins deals in these categories — reputation, references, and clear evidence of meeting the specific control requirements, often weighted more heavily than in categories driven by productivity or growth outcomes.

The pattern shows up across other named regulations too

The same mechanism recurs across a number of other well-known regulatory regimes, and it's worth being able to recognize the shape quickly rather than treating each one as a separate phenomenon.

The Health Insurance Portability and Accountability Act, HIPAA, governs the handling of protected health information in the United States and includes a Privacy Rule and a Security Rule. It created sustained demand for healthcare-specific compliance tooling, including software to manage business associate agreements — the contracts required between a healthcare organization and any vendor that touches protected health information on its behalf — and tools to track and document required security safeguards.

The Payment Card Industry Data Security Standard, PCI DSS, isn't government regulation but an industry standard created by the major card networks through the PCI Security Standards Council, and it functions the same way for the purposes of this pattern: any merchant or processor handling card data has to meet a defined set of security controls. It helped create demand for payment tokenization services and dedicated compliance tooling aimed specifically at merchants trying to reduce the scope of systems that touch raw card data.

The California Consumer Privacy Act, CCPA, gives California residents specific rights over their personal data and took effect at the start of 2020. It extended a GDPR-shaped set of obligations — data access and deletion rights, opt-out mechanisms — to a large population of US-facing companies that weren't necessarily subject to GDPR, and it substantially widened the addressable market for the consent and privacy-rights tooling that GDPR had already created demand for in Europe. This is a common secondary pattern: a second, similar regulation in a new jurisdiction doesn't necessarily create a brand-new category so much as it expands the addressable market for a category that already exists, because the underlying software requirements overlap heavily even when the legal text differs.

How to tell whether a new regulation will create a durable category or just a temporary checkbox

Not every new regulation spawns a lasting software category, and it's worth being able to tell the difference before betting a company on one.

A few things tend to correlate with durability. Ongoing obligation versus one-time compliance matters a great deal — a regulation that requires continuous monitoring, periodic recertification, or an evolving control set (like SOX's annual assessment cycle, or FedRAMP's continuous monitoring requirement) creates recurring demand, which supports a subscription software business. A regulation that requires a single, one-time attestation with no ongoing obligation is more likely to be satisfied with a one-time project — a consultant, a manual process, an internal spreadsheet — and less likely to sustain a standalone software category on its own.

Breadth of the affected buyer population matters too. A requirement that applies narrowly, to a small number of large organizations, can still be a viable business, but it looks more like an enterprise services business serving a limited account list than a broad self-serve software category. A requirement that applies to a wide population, including smaller and mid-sized companies who can't easily staff an internal compliance function, creates room for a scalable software product to replace what would otherwise be manual or outsourced effort.

Ambiguity in enforcement and interpretation cuts both ways. Some early regulatory ambiguity is actually good for category formation, because it creates anxiety that drives buyers toward any credible-looking solution rather than waiting for perfect clarity. But regulation that stays permanently ambiguous, with no meaningful enforcement track record, risks stalling the category in an extended "wait and see" phase where buyers under-invest because the real cost of non-compliance never becomes concrete.

Whether the requirement can be absorbed into an adjacent existing product is the biggest risk to a standalone category's durability. If the compliance need can be reasonably bolted onto a tool companies already own — a feature added to an existing HR platform, a module added to an existing cloud console — a lot of the addressable demand for a dedicated point solution disappears once the incumbents catch up. Point-solution vendors in regulation-driven categories often have a window of a few years of standalone relevance before the feature gets absorbed into a broader platform, and the strongest ones use that window to build defensibility beyond the original narrow compliance feature — deeper workflow integration, breadth across multiple regulations, or a data moat — rather than assuming the point-solution advantage is permanent.

What this means if you're building in a regulation-adjacent space

If you're evaluating whether to build toward a newly created or newly expanded regulatory requirement, a few practical implications follow from the pattern above.

Read the actual text of the requirement, or a reliable summary of it, before you build anything. Because the specification is public, the gap between "vaguely aware there's a new privacy law" and "precisely aware of what the specific relevant clause of the actual regulation requires a data processor to record" is often the gap between a generic product and one that a compliance buyer trusts immediately because it visibly maps to their obligation.

Expect a cluster of competitors on a similar timeline, and plan for it rather than being surprised by it. Because the trigger is public, you are very unlikely to be the only founder who read the same regulation and had the same idea. Differentiation in these categories tends to come from execution speed, depth on the specific requirement, and credibility with the buyer, more than from being first to notice the opportunity.

Think about which piece of the compliance workflow is defensible beyond the initial mandate. A narrow feature that maps to one clause of one regulation is a reasonable way to get a first customer and a beachhead market, but it's rarely a durable standalone company on its own — the strongest plays in this space tend to expand into adjacent obligations, additional regulatory frameworks, or a broader trust and risk workflow once the initial foothold is established.

Be realistic about how this affects your addressable market. A newly created regulatory requirement can meaningfully expand total addressable market for a category almost overnight, but only for the population of companies actually subject to the requirement — it's worth being precise about who that population actually is, rather than assuming the whole regulation-adjacent market is now in play.

Watch for the requirement itself as an ongoing market signal: draft regulations, proposed amendments, and regulatory guidance documents are public well before enforcement begins, and reading them early is one of the more reliable ways to anticipate demand before your competitors do, rather than reacting only once a law is already in force and the first wave of vendors has already shown up.

Reading a new regulation before you build: what to actually look for

When you're evaluating whether a proposed or newly enacted regulation is worth building toward, it helps to read it the way a product manager reads a spec rather than the way a founder reads a news headline. A few specific questions are worth answering directly from the source text, not from secondhand summaries.

Who exactly is in scope? Regulatory text usually defines the covered population precisely — by revenue threshold, headcount, industry classification, type of data processed, or geography. "Applies to companies handling personal data of EU residents" and "applies to publicly traded companies" are very different addressable populations, and the precision of the definition tells you how big and how identifiable your buyer list actually is, which matters enormously for whether a self-serve motion or a targeted enterprise motion is the right fit.

What specifically has to be produced, recorded, or demonstrated? The strongest regulation-driven products map to a concrete artifact the law requires — a consent record, a control attestation, an audit log, a signed agreement. If the requirement is vague on what evidence actually has to exist, it's harder to build a product that a compliance buyer will trust to satisfy it, and it's more likely the market will initially be served by consulting and legal advice rather than software.

Is there a recurring obligation or a one-time one? Look specifically for words like "periodic," "annual," "continuous," or "ongoing" attached to the compliance activity. A regulation that only requires action once, at the time a company first becomes subject to it, supports a much smaller software opportunity than one that requires the same demonstration repeatedly over time.

What's the enforcement mechanism, and has it been used? A requirement with a defined penalty structure and a regulator that has a track record of enforcing it creates real urgency. A requirement with vague or largely theoretical enforcement creates weaker urgency, at least until the first few visible enforcement actions happen — which is itself worth watching for as a signal that the category is about to heat up.

Is there a natural adjacent obligation you could expand into? Regulations rarely arrive alone. A privacy law usually sits alongside breach notification requirements, data retention rules, and vendor management obligations. Reading the full regulatory landscape a new law sits inside, not just the single headline requirement, helps you assess whether there's a realistic expansion path beyond the first narrow feature — which matters for whether this becomes a company or a feature that a bigger platform eventually absorbs.

The difference between a compliance feature and a compliance category

It's worth being precise about a distinction that gets blurred a lot in how founders talk about this opportunity: not every regulation-driven product is a category, and not every feature that helps with compliance deserves to be pitched or built as a standalone company.

A compliance feature solves one narrow requirement well enough to be sold, but its natural home is inside a broader existing product a company already owns — a consent toggle inside a CMS, an access log inside an identity provider, an attestation workflow inside an existing GRC suite. These are genuinely useful, and they're often the right scope for an early beachhead, but they tend to get absorbed by adjacent platforms as those platforms mature, because the buyer would rather have one fewer vendor to manage.

A compliance category exists when the requirement is broad and complex enough that no single adjacent platform naturally owns the whole workflow, and the problem requires enough dedicated depth — data mapping across dozens of systems, ongoing monitoring across a wide control framework, coordination across legal, security, and engineering teams — that a best-of-breed vendor has a durable reason to exist independent of any one company's existing stack. GDPR's privacy management workflow and SOX's broader GRC workflow both grew into categories in this fuller sense; a lot of narrower point requirements within adjacent regulations never got past the feature stage before being absorbed elsewhere.

The practical implication: if you're assessing a regulation-driven opportunity, be honest with yourself about whether the workflow you're building is complex and cross-cutting enough to plausibly resist absorption, or whether it's a well-defined feature that's genuinely useful as a wedge but should be pursued with a clear-eyed expansion plan rather than an assumption that the initial narrow scope is durable on its own. This connects to a broader strategic choice worth thinking through early — whether you're building toward a defensible standalone position or a feature that a later, larger platform will eventually fold in, which is part of the same thinking covered in strategy vs. planning: the plan for the next two quarters looks similar either way, but the strategic bet underneath it is very different.

Risks and caveats: regulatory categories can also stall or collapse

It's worth being honest about the failure modes, because the framing of "regulation creates categories" can make the pattern sound more reliably lucrative than it actually is in practice.

Enforcement can be inconsistent or delayed, which softens the urgency that drives buying and can leave a category of vendors selling into a market that isn't moving as fast as the initial reading of the law suggested it would. Amendments and legal challenges can narrow or reshape a requirement after vendors have already built against an earlier version of it.

Larger incumbent platforms are also a real structural threat to standalone vendors in this space, and it's worth understanding why they're so often able to respond fast. A platform with a large existing installed base doesn't need to win new customers to compete for the compliance budget — it only needs to convince its existing customers that the new checkbox feature it just shipped is good enough, which is a much easier sale than a net-new vendor relationship. This is also frequently how existing companies enter a newly created regulatory category in the first place: not by building something new from scratch, but by repositioning an existing product they already sell to the same buyer, adding the specific control or workflow the new regulation requires. That's a repositioning move rather than a pivot in the fuller sense — the underlying business and customer base don't change, only the framing and feature set — and the distinction between the two is covered in more depth in pivot vs. repositioning. Standalone vendors competing against that kind of incumbent response need a genuinely deeper or broader answer than the incumbent's bolted-on feature, not just an earlier launch date.

And buyers, once the initial anxiety around a new law settles, tend to consolidate spend onto fewer vendors over time, which compresses the number of viable standalone companies a given regulation can support long-term.

None of this means the underlying mechanism is unreliable — GDPR, SOX, and FedRAMP are well-established, durable examples of regulation creating lasting categories. It means the mechanism explains why a category exists and why demand appeared quickly, not that every company that enters the resulting category will succeed, or that every new regulation will produce a category as durable as those three did.