Who Owns Your Website in Malaysia? The Complete Control Checklist

Reviewed 29 August 2026. This is an operational checklist, not legal advice. Contract and intellectual-property questions should be reviewed by a qualified Malaysian lawyer.

Website ownership is not one thing

When a Malaysian company says, “We own our website,” that can mean four different things:

1. the company is named as the domain registrant;
2. authorised staff can administer the accounts that keep the site online;
3. the company has the contractual rights to use or modify the code, design and content; and
4. the company can recover, move and operate the system without depending on one supplier or former employee.

An invoice proves that money changed hands. It does not, by itself, prove every item above. Likewise, having a WordPress administrator login does not prove domain control, cloud billing control or ownership of custom source code.

The practical question is therefore not simply “Who owns the website?” It is: can your company prove control of every asset required to keep trading, and can it transfer that control safely?

1. Establish who controls the domain

For a .my domain, start with the accredited registrar through which it is registered. MYNIC defines the registrant as the person or organisation that applied for the domain, or the existing registrant that maintains it as the domain holder. It separately defines administrative, billing and technical contacts. Read the definitions in the MYNIC Registrant Agreement.

That distinction matters. An agency may legitimately act as the technical contact while your company remains the registrant. A staff member may handle billing without being the registrant. Do not infer the registration holder from who receives renewal invoices.

Record and verify:

• the exact registrant name and organisation;
• the registrar and registrar-account owner;
• the administrative, billing and technical contacts;
• the renewal date, payment method and auto-renewal status;
• access to DNS records and nameserver settings;
• whether multi-factor authentication is enabled; and
• the documented recovery route if the primary administrator is unavailable.

For .my names, MYNIC states that registrations are made through its officially appointed registrars; its registrar directory can help confirm whether you are dealing with an accredited provider.

For generic domains such as .com, identify the current registrar and registered name holder. ICANN's transfer framework distinguishes a change of registrar from a change of registrant. Its Transfer Policy also explains transfer locks and the AuthInfo code used in registrar transfers. A successful login is useful evidence of access, but the registration data and registrar process are the stronger evidence of who can authorise a transfer.

Pass condition: at least two current company representatives can reach the registrar through company-controlled identities, the registrant details are accurate, renewal cannot fail silently, and the transfer or recovery procedure has been tested without actually moving the domain.

2. Map DNS, hosting and cloud infrastructure

The domain is only the signboard. DNS determines where traffic and email go; hosting or cloud infrastructure runs the application; storage and databases hold business data. These may belong to different providers and accounts.

Build a one-page infrastructure register containing:

• DNS provider and zone identifier;
• hosting, cloud or server provider;
• production and staging environments;
• database, object storage and backup locations;
• content-delivery network and web application firewall;
• SSL/TLS certificate management method;
• billing owner and payment-failure contacts; and
• the person or role accountable for each service.

Avoid one shared “admin” password in a WhatsApp thread. CISA recommends requiring multi-factor authentication for privileged or administrative access and starting with admin accounts. Its MFA guidance for small and medium businesses also ranks phishing-resistant options above text or email codes. Use named accounts, MFA and a company-managed password manager or identity platform.

Pass condition: authorised staff can access billing, DNS, production and backups; former users can be removed; and a supplier account can be disabled without locking the company out.

3. Verify source code and deployment control

A copy of the visible website is not necessarily the source needed to maintain it. Modern systems may depend on a private repository, build configuration, environment variables, deployment credentials, database migrations and third-party services.

For a custom-built site, confirm that the company has appropriate access to:

• the Git repository and its organisation settings;
• the complete source and dependency lockfiles;
• deployment workflows and build instructions;
• environment-variable names and a secure recovery process for secrets;
• database schema and migration history;
• infrastructure configuration, where applicable; and
• an export or escrow arrangement if the contract limits direct repository access.

Technical access and legal rights are not interchangeable. Review the signed proposal, statement of work, licence terms and handover clauses for ownership or licensing of bespoke code, stock assets, fonts, themes, plugins and design files. If wording is unclear, obtain legal advice rather than assuming that possession of a ZIP file settles the question.

Pass condition: the company can produce a current build or export, identify all required secrets and services, and show the contractual basis on which it may use, maintain and transfer each component.

4. Audit CMS, commerce and customer-data accounts

List every system capable of changing content, taking payment, viewing customer information or altering tracking. Typical examples include:

• WordPress, Shopify or another CMS;
• Stripe or another payment provider;
• transactional email and SMS services;
• Google Analytics, Tag Manager and Search Console;
• Meta Business Manager and advertising accounts;
• CRM, forms, live chat and marketing automation;
• cookie-consent and privacy-request tools; and
• maps, reviews, booking or marketplace integrations.

For each service, record the business owner, technical owner, recovery email, MFA status, billing entity, permission level and offboarding procedure. Prefer company-domain email addresses over a supplier's personal address. Keep at least two appropriately authorised owners for accounts whose loss would stop sales.

Do not give every collaborator permanent owner access. Apply least privilege: owners retain recovery and governance control, while suppliers receive the smallest role that supports the agreed work. Google makes the same distinction in Search Console between verified owners, delegated owners and lower permission levels. Its user-management guidance recommends regular permission audits, revoking people who no longer work on the property and removing leftover verification tokens.

Pass condition: the account register has no unknown owners, no former supplier with unnecessary access, no recovery address outside company control and no single person whose absence prevents recovery.

5. Confirm licences, creative assets and content rights

Premium software and creative assets often operate under licences rather than outright ownership. A theme, font, photograph, icon set or plugin can remain usable only while a subscription is active or while particular licence conditions are met.

Create a licence schedule showing the asset, vendor, licence holder, covered sites, renewal date, recurring price, cancellation effect, transfer conditions and purchase evidence.

An agency-wide licence is not automatically improper. It may be an efficient commercial arrangement. The risk appears when the arrangement is undocumented, the renewal dependency is hidden, or the company cannot replace the licence during handover. Ask what stops working when the engagement ends and budget for replacement licences where necessary.

6. Prove backups and recovery, not just access

Control is incomplete if the only working copy lives in one production account. Confirm the scope, frequency, retention and location of backups for files, databases, configuration and customer uploads. At least one recoverable copy should be isolated from the credentials used to administer production.

Then perform a restoration drill in a safe environment. Record who initiated it, which backup was used, what failed, how long recovery took and what remained manual. A green “backup completed” email is weaker evidence than a successful restore.

Document recovery if the current agency, hosting provider or administrator becomes unavailable. Name the contacts, verification documents, dependencies and recovery order: identity and email first, then registrar and DNS, infrastructure, data and applications.

7. Run a controlled handover test

You do not need to terminate a supplier to test operational independence. Ask a different authorised person to complete a non-destructive exercise:

1. locate the asset register and contracts;
2. sign in through the approved recovery route;
3. verify registrar, DNS and hosting access;
4. obtain a fresh source export or repository checkout;
5. restore a recent backup to staging;
6. identify all active administrators and integration keys; and
7. confirm the renewal calendar and escalation contacts.

Record gaps as business risks, not accusations. A cooperative supplier should be able to clarify roles and help close them. If a transfer is required, plan it carefully: ICANN notes that some registration changes can trigger transfer locks, and its domain-transfer overview explains the standard process for generic domains. For .my domains, follow the current MYNIC and accredited-registrar process rather than assuming the ICANN workflow applies unchanged.

A board-ready ownership scorecard

Mark each area verified, partially verified or not verified:

One red item does not necessarily mean the website is unusable. It means the board or owner cannot yet rely on evidence that the business can recover or transfer that part of the system.

What to do when the evidence is incomplete

Start with the assets that could stop revenue or communications: company email, domain, DNS, payments and production hosting. Preserve the current system before changing credentials. Avoid abrupt access changes that could break deployments, email delivery or integrations. Agree a written handover sequence, take verified backups, then rotate access and remove obsolete accounts.

If you need an independent baseline, Jaga's System Review is RM5,000 fixed and produces a decision-ready report with a 30-day action plan. Where the evidence reveals one defined implementation outcome, a Fixed-Scope Project starts from RM30,000. For a live system that needs recurring, prioritised releases, Monthly System Improvement starts from RM13,000 per month. Prices exclude SST unless stated otherwise.

The objective is not to eliminate suppliers. It is to make every supplier relationship governable: clear authority, minimum necessary access, recoverable company control and evidence that survives staff or provider changes.