You can't govern a web estate you haven't inventoried.
Website governance fails when the inventory is incomplete. Decentralized teams launch sites that central IT never records, so policies, permissions, and compliance evidence cover only the estate that leadership remembers. A verified, owned, continuously updated site inventory is the first governance control.
Every enterprise website governance model assigns ownership: marketing owns brand, IT owns infrastructure, departments own their pages. Almost none of them answer an earlier question: who owns which sites, exactly?
In the university, government, and NGO web estates that grew by accretion (a program microsite here, a grant-funded portal there), the governance policy covers the estate everyone remembers. The risk concentrates in the properties nobody does.
The upside is concrete. A leader with a verified inventory can answer an accessibility auditor in an afternoon rather than a quarter, apply one security fix across the whole estate instead of the part they can find, and retire a site on evidence instead of guesswork. That is what an inventory buys, and it is why the inventory comes before the policy.
Why Do Organizations Lose Track of Their Own Websites?
Organizations lose track of their websites because decentralized publishing is the operating model, not a failure of it. Website sprawl, the accumulation of sites, subdomains, and microsites faster than anyone records them, is the normal condition of a decentralized estate.
In higher education, decentralization is structural. Academic departments, research centers, athletics, student services, and continuing education each run their own corner of the estate, each on its own budget cycle.
The scale is routine, not exceptional. Campus estates running well over a hundred separate Drupal installations, each needing the same security patch applied individually, are documented across the higher education Drupal community.
Departments that launch sites outside central IT rarely do it out of malice. They do it for speed: the site ships for a conference, a grant, or a recruitment cycle. Ownership lapses later, quietly, when the organizer moves on, or the funding ends.
What Does an Ungoverned Web Estate Cost?
An ungoverned web estate costs an organization on three fronts: security exposure, compliance liability, and brand drift. The compliance line is the one that now carries hard federal deadlines.
Security exposure. An unpatched departmental CMS is an entry point no firewall rule accounts for, because nobody knows it is there. A site still running Drupal 7, which reached end of life on 5 January 2025, receives no security coverage from the community at all.
Compliance liability. Seyfarth Shaw identified 3,117 federal website-accessibility lawsuits under ADA Title III in 2025, a 27 percent increase over the 2,452 filed in 2024. Title III reaches private entities and public accommodations, including private universities; public institutions answer to Title II instead. Both are measured against the same WCAG 2.1 AA benchmark, so the exposure differs in which rule applies, not in what has to be fixed. In higher education, nearly 65 percent of respondents to an Educause IT Accessibility Community Group survey reported legal threats or actual lawsuits over technology accessibility, in a self-selected sample of institutions already engaged with the issue.
Brand drift. The slowest cost, and the one marketing feels first: off-template microsites, inconsistent messaging, and a recruitment journey that changes voice halfway through.
Did the ADA Title II Extension Reduce Your Exposure?
No. The April 2026 extension of the ADA Title II deadlines gave public entities more time. It did not shrink what has to be found and fixed.
The DOJ's April 2024 Title II rule made WCAG 2.1 AA the explicit standard for state and local government web content, public colleges and universities included. On 20 April 2026, an Interim Final Rule moved the date for entities serving 50,000 or more people from 24 April 2026 to 26 April 2027, and the date for smaller entities and special districts from 26 April 2027 to 26 April 2028. The standard did not change, and the extension does not pause private litigation.
The Department's own reasoning is worth reading if you are counting on tooling to close the gap. It extended the dates partly because it had overestimated what automation could do, noting that generative AI does not yet reliably automate the remediation of inaccessible content at scale. The regulator is describing this as human-owned work. An inventory is where that work starts, and it is also what makes AI-assisted remediation targetable later: you cannot queue a site for automated checking if it is not on the list.
The scope point matters more than the dates. The rule covers the web content a public entity provides, not the subset that lives on the central CMS. A department microsite on a forgotten subdomain is inside the rule's scope whether or not it is inside your inventory. The extension is time to find what you own.
The Inventory Is The First Governance Control
Our view: most governance failures are discovery failures first. Across the university and government Drupal estates Vardot has audited, the recurring pattern is a governance policy written against the estate that leadership remembers, then applied to an estate that is meaningfully larger.
A governance document without a verified inventory is a hypothesis. It names owners for the known properties and says nothing about the unknown ones, which is where the unpatched CMS and the uncaptioned video live.
Picture a 40-subsite university install. The policy assigns every college a content owner, and the estate still includes a 2019 conference site running Drupal 7 on a departmental server nobody has logged into since the organizer left. The policy is fine. It just does not apply to anything it cannot see.
That is why inventory is not preparation for governance. It is the first control, and every other control (permissions, workflow, compliance evidence) inherits its accuracy. In the Vardot Delivery System, this is the Align stage: you cannot blueprint an estate you have not mapped.
It is also where open source earns its keep. On an open platform, the inventory is something you can produce yourself: enumerate every site, read the code that runs it, and hold the authoritative record in your own systems. That ownership is what makes a complete inventory achievable, and it is the practical form the open-source argument takes in a governance conversation.
How Do You Build a Website Inventory That Holds?
A website inventory is the authoritative record of every web property an organization runs, who owns each one, and what obligations attach to it. An inventory that holds has three properties:
One named owner. A person, not a department.
A record created at provisioning. A site gets an inventory record when it gets a domain, not when an audit finds it.
A fixed reconciliation cadence. Quarterly, against DNS zones, TLS certificates, and analytics properties.
An inventory decays as fast as the estate changes, so name the run cost up front. Those three properties are the run cost.
On multisite platforms, this is cheaper to enforce. Varbase, Vardot's enterprise Drupal distribution, uses centralized provisioning, so an inventory record exists because the platform created it rather than because an audit found the site.
How Do You Know If Your Inventory Is Already Sound?
Three statements locate you:
You cannot say today, without polling departments, how many public sites your organization runs.
More than one team can put a site on the public internet without central IT knowing.
Your newest inventory record is older than your last reorganization.
If none of these describes you, your inventory practice is probably sound and formal discovery work will add little. If one or more do, discovery comes before policy, because the policy has nothing accurate to attach to.
What Should a Website Inventory Record Include?
Every record should capture six fields. Each one exists to answer a specific question an auditor, a security lead, or a successor will eventually ask.
Website inventory record: the six required fields
Field
What it tells you
Named owner (a person, not a department)
Who answers when the site breaks, drifts, or falls out of compliance
Platform, version, hosting location
Whether the site is patchable, and by whom
Last content update, last security patch
Whether anyone is actually maintaining it
Data collection and authentication status
Whether privacy and security obligations attach
Compliance surface (the rules the site must evidence: Title II, Section 508, multilingual obligations)
What an auditor can hold it to
Decommission criteria
What has to be true for the site to be retired, so abandonment is a decision rather than a default
Who Should and Shouldn't Pay for Formal Inventory Work?
Formal inventory work is the right spend for some readers and the wrong spend for others, and the split is not about size alone.
Two obligations decide it more often than estate size does: ADA Title II, which sets WCAG 2.1 AA for state and local government web content including public universities, and Section 508, which applies to federal agencies and to the contractors and grantees that supply them.
When formal discovery is worth buying, and when it is not
Buy formal discovery when
Don't buy it when
You cannot produce a current site list without polling departments
You run fewer than ten sites on one platform with one team
You carry a Title II or Section 508 obligation and have multiple publishing teams
You are mid-consolidation with a funded decommission date
Your estate spans more than one platform, host, or acquired institution
Your bottleneck is remediation capacity, not visibility
Three cases where formal discovery is the wrong spend are worth expanding, because all three are common:
You run fewer than ten sites on one platform with one team. A quarterly spreadsheet review by someone who already knows the estate beats any tooling or audit engagement you could buy, ours included.
You are mid-consolidation with a funded decommission date. Inventory the target platform properly. Continuous discovery for properties already scheduled for decommission is spend without return.
Your bottleneck is remediation capacity, not visibility. A better-documented list of issues you cannot staff to fix does not reduce exposure. Fund the fixes first.
Audit vendors, Vardot included, are paid to find things, so the default advice you will hear is to inventory everything, continuously. Those three conditions are the cases where that advice serves the vendor more than it serves you.
What Should a Compliance-Accountable Leader Do Before the Next Audit Cycle?
Before the next audit cycle, a compliance-accountable leader needs one thing settled: an inventory with named owners, or a dated plan to build one. Every other control in a governance program depends on it.
If you run a small single-platform estate, or your constraint is remediation capacity rather than visibility, buy neither audit nor discovery tooling. Vardot is paid both for governance and compliance audits and for the consolidation work that follows them, so telling you when not to buy is the cheapest credibility we can offer.
If you are working the higher education version of this problem, our Drupal Accessibility Control Map maps WCAG 2.2 AA and Section 508 criteria to specific Drupal controls. It covers 2.2 AA, which includes every 2.1 AA criterion the Title II rule requires.
It is a useful companion once the inventory tells you what those controls have to cover. If you would rather have the discovery run for you, that is what our governance and compliance audit covers.
Abdalrahman is a client-centric SRE and Security Manager at Vardot, where he leads a team of DevOps Engineers and supports the delivery of secure, reliable, and scalable digital platforms. He brings strong experience in automating, optimizing, and securing deployment workflows, helping teams improve operational efficiency, system resilience, and service uptime. He holds a Master’s in Computer Science and is pursuing an MBA, combining deep technical expertise with a growing strategic and business perspective to align engineering practices with client needs, business goals, and long-term platform sustainability.
A website inventory records the properties an organization runs: domains, owners, platforms, and obligations. A content audit assesses the pages inside a property for accuracy, performance, and accessibility. The inventory tells you which sites exist and who is accountable. The audit tells you what is wrong inside them. The inventory comes first, because a content audit can only cover the sites you already know about.
One named person in central IT or central web services should own the inventory, with departmental contacts named per site rather than per department. Ownership fails when it sits with a committee or a role that turns over, because inventory maintenance is a recurring task rather than a project. The owner does not have to run the sites. They have to be accountable for the record being current.
Discovery across DNS, certificate transparency logs, analytics, and billing typically takes days rather than weeks. Reconciling the findings takes longer, because assigning a named owner to every site means contacting departments and resolving the properties nobody claims. Plan for the unclaimed sites to consume most of the effort. They are also the ones carrying the compliance and security exposure.
Yes, though the work is smaller. A multisite gives you an authoritative list of the sites on that codebase, which is most of the inventory for those properties. It says nothing about the sites outside it: the departmental WordPress install, the standalone conference site, the platform an acquired institution brought with it. Multisite narrows the discovery problem. It does not close it.
