Who Owns Your Organisation’s Website?

Q: Who owns your organisation’s website?

It sounds like a simple question, but there usually isn’t one simple answer.

Your organisation may own the written content and branding. A web developer may manage the hosting. Someone in communications may have WordPress administrator access. An IT supplier may control the DNS. Finance may manage a payment account. Google Analytics might still be attached to the email address of somebody who left three years ago.

All of those arrangements might be perfectly workable.

The governance problem appears when nobody can clearly explain who controls each part, who is responsible for it, and what would happen if the person or supplier looking after it changed.

This is where website ownership becomes a broader question of how your organisation governs its website.

A well-governed organisation does not need to operate every part of its website itself. But it should retain control of its critical digital assets and know who is accountable for the website and the systems around it.

That means thinking about website ownership in four different ways:

legal rights, control, responsibility and accountability.

They overlap, but they are not the same thing.

Key Takeaways

• Website ownership is about more than whose name appears on an account or who has the WordPress password.
• Your organisation should retain control of critical assets such as its domain and important digital accounts.
• You can delegate day-to-day website management to staff and suppliers without giving away organisational accountability.
• Responsibility should be clear across areas such as domains, hosting, content, data, integrations and suppliers.
• If nobody can explain who controls each important part of the website, there is a governance problem even if the website works perfectly today.

“Ownership” Can Mean Four Different Things

One reason website ownership becomes confusing is that we use the same word to describe several different relationships.

Legal Rights

Genuine legal ownership questions surround websites.

Who owns the photographs? Who owns the written content? What rights does the organisation have to a custom design or piece of software? What does the contract with the web developer say? Are particular fonts, plugins or other components licensed rather than owned?

Those questions matter, but they are not the main focus here. If the contractual or intellectual-property position is unclear, review the agreement with the supplier and seek legal advice where necessary.

Even a domain name is not quite as straightforward as saying that an organisation “owns” it. Within the .au namespace, the registrant holds a licence to use the domain. auDA says that where somebody such as a web developer registers a .au domain on behalf of an organisation, the organisation’s details should be used because the registrant information determines who holds that licence.

But legal rights are only one part of the ownership question.

Control

Control is much more practical.

• Who can transfer the domain?
• Who can change its DNS records?
• Who can log into the hosting account?
• Who can add or remove WordPress administrators?
• Who can recover an account if the password is lost?
• Who can change where online payments are sent?

An organisation can legally have rights over something while still having very little practical control over it.

Responsibility

Responsibility is about who performs or manages the work.

Your communications manager might maintain the content. Your web developer might update WordPress and its plugins. An IT provider might manage DNS. Finance might reconcile payments.

There is nothing inherently wrong with spreading those responsibilities across different people and suppliers.

In fact, that is normal.

The important thing is that it happened deliberately, not accidentally.

Accountability

Accountability sits above the day-to-day work.

Someone within the organisation needs to ensure that the important responsibilities exist, that appropriate people or suppliers have been assigned to them, and that the arrangement continues to work when things change.

This distinction between delegation and accountability is well established in organisational governance.

The Australian Institute of Company Directors’ Not-for-Profit Governance Principles recognise that a board can delegate authority to management, staff and others, but those delegations should be defined and periodically reviewed. The board does not simply stop being accountable because someone else does the work.

That does not mean your board should be updating WordPress plugins.

It means the organisation should know who is responsible for maintaining the website, understand the extent of that responsibility, and retain appropriate oversight.

Your Organisation Should Control Its Critical Digital Assets

The domain name is the most obvious place to start because without it, people may no longer be able to reach the website at all.

Suppose your web developer registered the domain when the website was built.

That isn’t necessarily a problem.

The important questions are whether your organisation is the correct registrant, whether you know which registrar manages the domain, whether current organisational contacts receive important notices, and whether the organisation could regain or transfer control if the supplier relationship ended.

For .au domains, auDA specifically recommends using the organisation’s own registrant details when another party registers a domain on its behalf.

The same principle extends beyond the domain.

Your organisation does not necessarily need to administer every digital service directly. Doing so can create its own security and operational problems.

But for critical services, somebody inside the organisation should at least know:

what the service is, why you use it, who controls it, who pays for it, who currently manages it, and how the organisation would recover or transfer access if necessary.

That might include your hosting, DNS or CDN provider, WordPress installation, analytics, Search Console, transactional email service, payment gateway, CRM, learning platform, and any critical third-party services connected to the website.

The right arrangement varies by organisation.

The principle is simpler:

You can delegate administration without making your organisation dependent on somebody else’s continued presence.

The Website Is More Than WordPress

Another reason ownership becomes fragmented is that what we casually call “the website” is usually a collection of systems.

WordPress may be the visible part, but an organisational website might also depend on a CRM, payment gateway, membership database, email platform, learning management system, document repository, event system or several external APIs.

Different systems may legitimately have different owners and responsibilities.

For example, WordPress might display a member directory while the authoritative member record lives in a CRM.

The communications team may decide what information appears on the website without being responsible for the database that contains it.

A web developer might maintain the integration between the website and a payment system without having any authority to decide your organisation’s refund or reconciliation policies.

This distinction matters because technical access is not the same as organisational ownership.

In strategy and discovery work, I often find that asking “who owns this?” produces different answers depending on whether we’re talking about the domain, the content, the data, the hosting or the decision itself.

That is usually the point at which a website discussion becomes a governance discussion.

“Jane Looks After the Website” Is Not a Governance Model

Many organisations have someone who knows how everything works.

Let’s call her Jane.

Jane knows which registrar the domain is with.

She knows the hosting company.

She has the WordPress login.

She knows which plugin sends the membership form to another system.

She remembers why a particular page must never be deleted.

She knows who to contact when something breaks and which credit card pays for the service everyone else has forgotten exists.

Jane might be exceptionally good at looking after the website.

The problem isn’t Jane.

The problem is that Jane has become the documentation.

If Jane retires, changes organisations, takes extended leave or simply cannot remember why something was configured seven years ago, a surprising amount of organisational knowledge can disappear with her.

I have seen the same pattern with external suppliers.

“We don’t know. Our developer handles all that.”

Again, that can describe a perfectly healthy supplier relationship.

A specialist web company may be exactly the right organisation to manage your hosting, website maintenance, backups and technical infrastructure.

The governance problem is not that you trust them.

It is that nobody inside the organisation knows what “all that” actually includes or what would happen if the relationship changed.

The issue isn’t trust. It’s continuity.

A Working Website Can Still Have an Ownership Problem

Weak website governance does not necessarily announce itself with an outage.

The website might look current. Pages might load quickly. Forms might work. Payments might be processed. Your web developer might respond promptly whenever you contact them.

Underneath that healthy-looking website, however, you might discover that an analytics account belongs to a former employee, only an external agency can change your DNS, a critical service is being charged to an old credit card, or an integration exists that nobody remembers commissioning.

People with privileged website access may also no longer work with the organisation.

None of those issues automatically means there is an immediate crisis.

They are signals that control and responsibility have become unclear.

This matters even more where the website handles organisational or personal information.

The Office of the Australian Information Commissioner (OAIC) makes clear that protecting personal information involves both technical and organisational measures. Its APP 11 guidance specifically includes governance, internal procedures, access security and third-party providers among the matters organisations may need to address. It also notes that information can still be “held” by an organisation when it outsources storage to a third party, where the organisation retains control.

Australian Signals Directorate (ASD) guidance takes a similar approach to cyber security. Its Information Security Manual recommends clearly defining and documenting the responsibilities shared between organisations and their suppliers, including through a shared responsibility model.

This wider principle applies beyond cyber security and privacy.

Outsourcing a system does not outsource the need to understand who is responsible for it.

Who Should Be Responsible for What?

No single organisational chart will work for every website.

A small association with two employees will structure responsibilities very differently from a national organisation with communications, operations and IT teams.

But the following ownership map gives you somewhere to start.

This does not mean that every area needs its own full-time owner.

It means that for each important part of the website, the organisation should be able to identify an accountable organisational owner, the person or supplier responsible for operating it, the access required to manage or recover it, and enough documentation to maintain continuity.

In a smaller organisation, one person may fill several of those roles.

That’s fine.

What matters is that the responsibilities are visible.

What If You Inherited the Website?

Most organisations are not starting with a blank sheet of paper.

You may have inherited a website that has evolved over ten or fifteen years.

A former CEO chose the original web company.

A volunteer registered the domain years ago using their own email address.

Someone in communications created the Analytics account.

Another developer moved the hosting five years later.

A membership system was connected to WordPress.

A new payment service was introduced.

An automation was added to fix a particular process.

Staff changed. Committee members changed. Suppliers changed.

Eventually, the current arrangement stops looking like an architecture somebody designed and starts looking like organisational archaeology.

That does not mean the answer is to tear it all down.

I wouldn’t begin by moving accounts, replacing platforms, or centralising everything under a new provider.

I would start by finding out what you actually have.

• What exists?
• Why does it exist?
• Who controls it?
• Who uses it?
• What depends on it?
• Who currently pays for it?
• What would happen if it stopped working?
• Is the current arrangement genuinely a problem?

Only once you’ve answered those questions can you sensibly decide whether to keep, improve, integrate, migrate, replace, or retire something.

Sometimes an inherited arrangement really does need changing.

Sometimes the technical arrangement is perfectly reasonable, and the only missing pieces are clearer responsibility, better documentation and a reliable recovery process.

Inventory before remediation.

What Good Website Ownership Looks Like

Good website governance does not mean keeping a giant folder of passwords and making the CEO an administrator of every system.

It means the organisation can answer reasonable questions about the digital infrastructure it relies on.

• What systems support the website?
• Who controls the important accounts?
• Who can authorise significant changes?
• Who is responsible for keeping content accurate?
• Which system is authoritative for important organisational data?
• What does each supplier manage?
• How would access be recovered?
• Where are unusual integrations or dependencies documented?
• What happens when a staff member, committee member or supplier changes?

Your senior management team does not need to understand every technical detail.

You hire specialists precisely because they understand things you should not have to manage yourself.

But the organisation should retain enough knowledge and control to keep the website understandable and recoverable.

That’s a useful standard.

You don’t need to know everything your web developer knows.

You do need to know enough to remain in control.

Start by Asking One Question

If you are unsure how well your website is governed, there is a simple question that can reveal a lot:

If the people currently looking after our website disappeared tomorrow, what would we struggle to access, understand or operate?

You don’t need to turn the answer into a major governance project immediately.

Start by bringing together the people who currently are responsible for the domain, hosting, website, content, data, payments, integrations, and supplier relationships.

Map four things:

What exists → Who controls it → Who is responsible → What isn’t clear

The gaps are usually more useful than the completed boxes.

They show you where organisational knowledge is sitting with one person, where an external supplier has become a dependency, where access is uncertain, or where nobody has actually been given responsibility.

Then you can decide what deserves attention.

Website Ownership Is Really About Continuity

There is nothing wrong with relying on specialists.

A good web developer should know more about maintaining your website than your CEO.

A communications manager should know more about publishing content than the board.

Your CRM administrator should understand the member database better than your web agency.

Healthy organisations delegate specialist work.

The difference is that the delegation is deliberate.

Staff will change.

Boards and committees will change.

Suppliers will change.

Technology will change.

The organisation should still retain enough control, documentation and decision-making authority for its website and surrounding digital systems to keep operating.

That is why the most useful test of website ownership isn’t simply who can log in today.

It’s whether the organisation remains in control when the people involved tomorrow are different.

When the Answers Aren’t Clear

If mapping your website’s ownership exposes old accounts, unclear responsibilities, undocumented integrations, or a heavy dependency on one person or supplier, that doesn’t automatically mean you need to rebuild your website.

Often the first thing you need is simply a clearer understanding of what you have, where the risks and dependencies sit, and what deserves attention first.

That’s the kind of problem I work through in a WordPress Platform Audit + Strategy Session. We’ll clarify how your current website is set up, identify the important risks and dependencies, and work out what your organisation should address next.