Who Really Owns Your AWS Environment, Source Code and Technology Accounts?

Technology Account Ownership Can Become a Serious Business Risk

Technology account ownership is something business owners rarely think about until they need access and discover that somebody else controls it.

Your developer may have built the system. Your agency may have configured AWS. A former employee may have registered the domain. Your Microsoft 365 subscription might be connected to somebody’s personal email address. The source code may sit inside a GitHub organisation you cannot administer.

Everything can work perfectly for years.

Then the relationship changes.

Someone resigns. A supplier closes. There is a disagreement. You want to change developers. An invoice goes unpaid. A password stops working.

Suddenly a question that once felt administrative becomes very commercial:

Do you actually control the technology your business depends on?

I have seen this risk appear in businesses of very different sizes. The problem is rarely the technology itself. It is usually unclear ownership, poor governance and too much knowledge or control sitting with one person.

The good news is that you can identify and fix most of these risks before they become a crisis.

Takeaways

What Does Technology Account Ownership Actually Mean?

Technology account ownership means your business has the legal rights, administrative control and practical ability to manage the technology assets it relies on.

Those are three different things.

You might legally own some intellectual property but have no access to the system containing it.

You might have administrator access to an AWS account while the account recovery email belongs to your developer.

You might possess a copy of your source code but not have ownership rights to everything inside it.

Good technology ownership therefore involves more than having a username and password.

For each important technology asset, I want to establish:

• Who legally owns it?
• Whose name or organisation is the account registered under?
• Who controls the primary administrator account?
• Who controls account recovery?
• Who receives the invoices?
• Who has privileged access?
• Can the business remove another person’s access?
• Can someone outside the business remove the business’s access?
• Can the business operate if the current developer or supplier disappears tomorrow?

That final question catches a surprising number of problems.

Who Should Own Your AWS Account?

If AWS infrastructure is running an important part of your business, the business should have effective control of the AWS environment.

That sounds obvious.

It does not always happen.

A developer may create an AWS account while building your first product. They use their email address, credit card or consulting company’s details because it is quick. Nobody worries about it while the relationship is good.

Three years later, that AWS account may contain databases, servers, backups, storage, DNS configuration, security settings and production systems worth far more than the original development project.

AWS itself makes the importance of account control clear. Its documentation says the AWS account root user has complete access to the resources in the account. AWS recommends protecting that access, limiting everyday use of the root user, using MFA, and carefully controlling account recovery. It also recommends using a business-managed email address rather than relying on an individual for critical root account communications. AWS provides detailed root user security guidance.

For a business-controlled AWS environment, I would normally expect:

• The organisation to control the account.
• The organisation to control the primary email address.
• More than one appropriate person to have emergency administrative access.
• MFA to protect highly privileged accounts.
• Normal administration to use individual identities and roles rather than shared root credentials.
• Billing to be visible to the organisation.
• Recovery procedures to be documented.
• External developers to receive only the access required for their work.
• Access to be removable by the organisation.

The same principle applies whether you use AWS, Microsoft Azure or Google Cloud.

The platform is not really the issue.

Control is.

Does Your Business Actually Own Its Source Code?

This is where things become more interesting.

Businesses often assume:

We paid the developer, so we own the code.

That assumption can be dangerous.

IP Australia explains that intellectual property created by contractors in Australia generally belongs to the contractor unless the contract states otherwise. It recommends having a written agreement that clearly defines ownership, commercial usage rights, transfer of intellectual property and what happens when the working relationship ends. IP Australia’s guidance on intellectual property ownership is worth reading if contractors have created important software for your business.

This means there are at least two separate questions.

Can you access the source code?

And:

Do you have the legal right to use, modify, transfer and continue developing it?

You want the answer to both questions to be clear.

A sensible software agreement should deal with matters such as:

• Ownership of newly developed code.
• Pre-existing code brought in by the developer.
• Open-source components.
• Third-party libraries and licences.
• Contractor and subcontractor contributions.
• Documentation.
• Database structures.
• Infrastructure configuration.
• Deployment scripts.
• Automated tests.
• Designs and technical specifications.
• Rights to modify the software.
• What must be handed over when the relationship ends.

This is an area where your lawyer should review the actual contractual position. My role as a technology consultant is different. I can identify where technical ownership, access and dependency appear unclear and where you may need legal advice.

Who Controls GitHub, GitLab or Bitbucket?

Having your source code in Git does not automatically mean you control it.

I would want to know whether the repository sits inside:

• Your company’s organisation.
• The developer’s personal account.
• The development agency’s organisation.
• A separate organisation created specifically for your project.

Then I would check who owns or administers that organisation.

Imagine your production application is stored in a developer’s personal GitHub account.

You might have access today.

But can you guarantee access tomorrow?

Can you:

• Add another developer?
• Remove the current developer?
• Change repository permissions?
• Access all branches?
• See the commit history?
• Access deployment workflows?
• Access issue tracking?
• Recover deleted repositories?
• Transfer repositories?
• Manage security settings?

If the answer is “I need to ask my developer“, you may have a dependency worth investigating.

That does not mean the developer has done anything wrong. Sometimes these arrangements simply grow organically.

A startup begins with one developer.

One developer becomes three.

The prototype becomes the company’s main product.

Temporary arrangements quietly become permanent infrastructure.

That is exactly why periodic technology governance matters.

Your Domain Name May Be More Important Than Your Website

One of the smallest entries on a technology ownership checklist can carry one of the largest risks.

Your domain.

Consider what happens if you lose control of yourcompany.com.au.

You could potentially lose control of:

• Your website.
• Company email.
• Customer communications.
• Password recovery.
• SaaS logins.
• Brand identity.
• Marketing campaigns.
• Customer trust.

Yet domains are sometimes registered through an employee, web developer or agency account.

I prefer the business to control its domain registrar account directly.

The business should also know:

• Which registrar holds each domain.
• Who the registrant is.
• Which email address controls the account.
• Who receives renewal notifications.
• Whether auto-renewal is active.
• Where DNS is managed.
• Who can alter DNS.
• Whether MFA is enabled.

A beautiful website means very little if another organisation controls the domain pointing customers towards it.

The Same Problem Exists Across Your Other Technology Accounts

AWS and source code attract attention because they sound technical.

The broader risk is much bigger.

A proper Technology Review should consider the accounts and technology assets that keep the organisation functioning.

That could include:

Technology asset	Ownership or control to check
Cloud hosting	AWS, Azure, Google Cloud account owner and administrators
Source code	GitHub, GitLab or Bitbucket organisation and repository permissions
Domains	Registrar account, registrant and DNS administration
Email	Microsoft 365 or Google Workspace global administration
Website	Hosting, CMS and plugin accounts
Database	Administrative access, backups and encryption keys
SaaS platforms	Primary owner and billing administrator
App stores	Apple and Google developer accounts
Analytics	Google Analytics and related platforms
Advertising	Google Ads, Meta and other advertising accounts
CRM	Administrator, data export and billing control
Backups	Storage location, credentials and recovery process
Certificates	SSL/TLS certificate management
Password management	Business password manager and emergency access
API accounts	Provider ownership, keys and billing
DNS/CDN	Cloudflare or other DNS and content delivery services
Documentation	Technical documentation and architecture records

None of these problems is particularly glamorous.

That is partly why they get ignored.

Unfortunately, boring technology administration can become very exciting when the only person with the password has left the business.

Technology Account Ownership Is Also a Key Person Risk

Sometimes the business technically owns everything.

There is still a problem.

Only one person knows how any of it works.

That is a classic technology key person risk.

I often describe the test like this:

What happens on Monday morning if this person is unexpectedly unavailable?

Not “what happens if they resign in six months and provide a perfect handover“.

That is the comfortable version.

Think about illness, accidents, sudden resignations, supplier failure, contractual disputes or someone simply being unreachable.

Could another capable person:

1. Access your production systems?
2. Find the source code?
3. Restore a backup?
4. renew the domain?
5. Understand how software reaches production?
6. Contact critical suppliers?
7. Access cloud billing?
8. Revoke compromised credentials?
9. Respond to a cyber incident?
10. Keep your customers operating?

If one person’s absence stops the business from doing those things, the problem is bigger than account administration.

A Key Person Technology Risk Review is designed to identify exactly this type of dependency.

This fits strongly with my “people before technology” approach.

The answer is rarely to distrust your developer.

The answer is to build a business that does not place an unreasonable level of risk on them in the first place.

A Developer Having Administrator Access Is Not the Same as Ownership

Businesses sometimes react to this issue by trying to remove developers from everything.

That would be the wrong lesson.

People need access to do their jobs.

Your developer may genuinely require powerful access to diagnose production problems or manage infrastructure.

The important distinction is between access and control.

Your business should be capable of granting access.

Your business should be capable of changing that access.

And your business should be capable of removing it.

The Australian Cyber Security Centre treats privileged accounts as particularly sensitive because they can change systems, privileges and security configurations. Its security guidance supports carefully controlling privileged access and monitoring its use. The Australian Government’s Essential Eight guidance is also a useful starting point for broader cyber security controls.

That does not mean your CEO should personally hold every password.

Good governance is not about giving everyone administrator access.

It is about making access deliberate, recoverable and accountable.

The Warning Signs That Your Business May Not Be in Control

A few answers should make you investigate further.

“Our developer looks after all that.”

Maybe they do a great job.

But who owns the account?

“I think the source code is on GitHub.”

Whose GitHub organisation?

“The agency pays AWS and invoices us.”

What happens if you change agencies?

“We’ve never needed the administrator password.”

That does not tell you whether you could obtain it during an emergency.

“Everything is backed up.”

Where?

Who can restore it?

Has anyone tested the restore?

“The developer owns the account, but we have access.”

Who can remove whose access?

“We’ve been with them for years.”

A long relationship is valuable. It is not a risk control.

Trust and governance can coexist perfectly well.

In fact, clear ownership usually makes supplier relationships healthier because nobody needs to rely on informal assumptions.

How I Would Check Technology Account Ownership

You do not need to begin with an enormous governance project.

Start with an inventory.

Step 1: List the systems the business cannot operate without

Think beyond servers.

Include software, communications, identity systems, domains, data, payment services, websites and customer-facing systems.

Step 2: Identify the account owner

Record the organisation, email address or individual under which each account was created.

Step 3: Identify the administrators

Who can add users, remove users, alter billing and make major configuration changes?

Step 4: Check account recovery

This is often missed.

An account may appear to belong to your business while password resets go to a former employee’s email address or mobile number.

Step 5: Check billing control

Billing records can reveal who the provider considers its customer.

They also tell you whether a service might suddenly stop if somebody else’s credit card expires.

Step 6: Check contractual ownership

For custom software, designs, documentation and other intellectual property, compare the practical arrangement with the contract.

Legal advice may be required here.

Step 7: Check whether control can be transferred

Imagine replacing the incumbent supplier.

What needs to happen?

If nobody knows, document it now rather than during an argument.

Step 8: Test business continuity

Choose an important system and ask someone other than its usual administrator to explain how access would be recovered.

Do not just admire the backup plan.

Test whether it works.

A Simple Red, Amber and Green Assessment

I often like simple assessment models because executives need to understand the risk without reading 60 pages of technical detail.

You can classify each important system like this:

Rating	Meaning
Green	Business controls ownership, administration, recovery and documentation. Appropriate external access can be revoked.
Amber	Business has access, but ownership, recovery, documentation or administrative control is incomplete.
Red	A supplier or individual controls a critical asset and the business cannot independently recover, transfer or administer it.

The aim is not to make every system green overnight.

Start with high-impact red risks.

Your production infrastructure is more urgent than a Canva account nobody has used since 2023.

Common Mistakes Businesses Make

Assuming access means ownership

Being invited into somebody else’s account is different from controlling the account.

Sharing one administrator login

Shared credentials make accountability and offboarding harder.

Create individual identities where the platform allows it.

Using personal email addresses

Critical accounts connected to someone@gmail.com are harder to control when that person leaves.

Forgetting recovery mechanisms

The recovery email, phone number or MFA device can matter more than the password itself.

Leaving ownership until the supplier relationship ends

That is probably the worst time to discover a disagreement.

Treating documentation as optional

Access without knowledge may still leave you unable to operate the system.

Depending completely on goodwill

A good relationship is valuable.

It should sit alongside clear contracts, documented access and sensible governance rather than replace them.

What Should You Do If Your Developer Currently Owns Everything?

Do not panic.

And do not start by sending an angry email demanding every password by 4 pm.

First understand the situation.

There may be perfectly reasonable historical reasons for the current structure.

I would normally work through it in this order:

1. Identify the critical accounts.
2. Confirm current ownership and administrator access.
3. Check the relevant agreements.
4. Identify what needs transferring.
5. Create business-controlled accounts where required.
6. Transfer assets carefully.
7. Create appropriate access for the existing developer.
8. Document recovery and continuity procedures.
9. Test access.
10. Review it periodically.

The objective is not to remove your developer.

It is to make the commercial relationship safer for everyone.

If ownership questions reveal broader problems with architecture, suppliers, security, documentation or governance, an independent Technology Review can provide a clearer picture.

Where the issue is specifically concentrated around one employee, contractor or supplier, a Key Person Technology Risk Review may be the better starting point.

Technology Ownership Should Be Part of Technology Strategy

Ownership can sound like an operational detail.

It is actually part of technology strategy.

If the business intends to grow, raise investment, acquire another company, sell the business or change suppliers, unclear technology ownership can create friction at exactly the wrong time.

An investor or buyer carrying out Technology Due Diligence may ask questions about:

• Intellectual property ownership.
• Software licensing.
• Cloud infrastructure.
• Security.
• Supplier dependency.
• Source code access.
• Key people.
• Documentation.
• Business continuity.

Finding weak ownership during due diligence can turn an easily fixed housekeeping issue into a transaction risk.

A good Technology Strategy therefore considers who owns and controls important technology, not just what technology the company plans to buy next.

Questions I Would Ask Your Technology Team

If you want to start the conversation internally, ask these questions:

• Who owns our AWS, Azure or Google Cloud accounts?
• Who controls the root or highest-level administrator access?
• Which email addresses are used for account recovery?
• Where is our source code stored?
• Does the company control the source code organisation?
• What does our development contract say about intellectual property?
• Who controls our domain names?
• Who controls DNS?
• Who administers Microsoft 365 or Google Workspace?
• Where are our backups?
• Who can restore them?
• When was recovery last tested?
• What happens to our systems if our developer leaves?
• Which critical services are billed to personal credit cards?
• Which accounts use personal email addresses?
• Which former employees or suppliers still have access?
• Where is this information documented?

You do not need perfect answers immediately.

What matters is discovering where you do not know the answer.

Those gaps tell you where to look next.

Frequently Asked Questions

Who should own a company’s AWS account?

The business using the AWS environment should normally have effective organisational control of its AWS accounts, billing, recovery mechanisms and administrative access. Developers and managed providers can still have the permissions they need without controlling the business’s underlying account.

Does paying a software developer mean I own the source code?

Not necessarily. IP Australia advises that intellectual property created by a contractor in Australia generally belongs to the contractor unless the contract states otherwise. Have the contractual position checked if ownership is unclear.

Should my developer have administrator access?

They may legitimately require high-level access for certain work. The important point is that the business should control how access is granted and should be able to revoke or change it when necessary.

How do I check technology account ownership?

Create an inventory of critical systems and record the legal owner, account owner, administrators, recovery details, billing arrangements and supplier dependencies for each one. Pay particular attention to anything the business cannot recover without help from one individual.

What happens if my developer owns our AWS account?

Establish the exact account structure before making changes. Confirm contractual rights, business access, billing, recovery mechanisms and the safest way to move the environment into business control. Complex production environments should be transferred carefully to avoid outages or data loss.

Final Thoughts

Technology governance should make the business stronger without making relationships harder. Good developers and suppliers should not have to carry the entire organisation’s operational risk on their shoulders.

If you are unsure who really controls your cloud environment, source code or critical systems, finding out now is considerably easier than finding out during a dispute, cyber incident or supplier change. Technology account ownershipis a small governance question that can reveal a very large business risk.