You can run a website without IT staff. But you can outsource the work, not the ownership. The basic shape is to keep the domain registrant, the DNS control panel and the administrator accounts in your company's name, and hand updates and checks to an outside provider.
Companies that have left the names and contact details with outsiders for years can find themselves unable to touch their website or email when a staff member leaves or a contract with an agency ends. The cause is less technical than organisational: nobody knows who holds what.
This article starts with a one-hour inventory, then works through who should hold what, starting with the domain. At the end you will find a responsibility-split table, a handover sheet for departures and an operations log template. Technical terms are explained where they first appear.
The first hour: an inventory
Have someone in the company fill in this table. Writing "unknown" is fine; every unknown becomes your first task.
| Item | Where to check | What to write down |
|---|---|---|
| Domain | JPRS WHOIS, contracts, invoices | Registrant, expiry date, contract holder, who can log in to the control panel |
| DNS | Control panel | Who can edit it, whether a copy of the settings exists |
| Server | Invoices, control panel | Contract name, plan, payment method |
| CMS (the site's editing screen) | Administrator list | Number of administrators, accounts of people no longer using it |
| Contract, control panel | Whose inbox receives invoices and expiry notices | |
| Backups | Contract, work records | Where they are, when a restore was last tried |
| Measurement | Search Console, GA4 | Whether your own account is the owner |
Pay particular attention to where expiry notices go. If it is a former employee's personal address or the agency's address, neither renewal reminders nor alerts about suspicious changes will reach you.
No one in-house to look after the website?
Your outside web person, starting with a domain and access inventory
Domains: the most damaging to lose, the easiest to forget
A domain underpins both your website and your email addresses. If it stops, both stop.
Look at the registrant and the contacts separately
| Term | Meaning | What to check |
|---|---|---|
| Registrant | The organisation or person that registered the domain | That it is your company's legal name |
| Sponsoring registrar (管理指定事業者) | The business that passes the registrant's requests to JPRS; one per domain | Which company you contract with |
| Registration and technical contacts | Contacts registered for organisational JP domains such as co.jp | That they are not people who have left |
| Public contact (公開連絡窓口) | Contact published for general-use JP domains (.jp) | That someone actually receives it |
You can check .jp and co.jp information in JPRS WHOIS. For general-use JP domains the registrant name may be hidden by a setting; in that case ask your registrar. Domains such as .com follow procedures and periods outside the JPRS rules, so check your registrar's terms.
An agency sometimes registers the domain on your behalf, leaving its own name as registrant. That is not wrong in itself; the problem is that you need a procedure when the relationship ends.
What happens at expiry
According to JPRS, a JP domain name expires at the end of the month one year after registration, and unless it is cancelled by then, JPRS renews it for a year. Renewal procedures and fees, however, differ by registrar, and JPRS itself describes cases where a domain is cancelled unintentionally because a renewal deadline was missed.
| State | General-use JP domain | Organisational JP domain (e.g. co.jp) |
|---|---|---|
| Period after cancellation | One month from the next day (to month end) | Six months from the next day (to month end) |
| Recovery window | From the 1st to the 20th of the month it enters the cancelled state | When cancelled by request, the 1st to the 20th of that month |
| If not recovered | The record is deleted and the same string can be registered again | The record is deleted and the same string can be registered again |
Recovery normally carries a fee, and its handling and acceptance period vary by registrar.
JPRS warns that once a cancelled domain is registered by a third party, it may be used for fraudulent sites, or the same email addresses may be recreated. Passwords for services that used those addresses as logins could then be reset and the accounts taken over. Unless there are grounds under the dispute resolution policy, such as trademark infringement, the third party's registration and use cannot be stopped.
An unintended cancellation through expiry can be prevented by checking where renewal notices go and how renewal is paid. Fill in those two items first in the inventory table.
Preventing domain hijacking
In its note on hijacking, JPRS recommends deciding in-house who manages domains and how, checking status regularly in WHOIS, monitoring change notices from the management service in one place, and using strong passwords and two-factor authentication.
For an important domain there is also Registry Lock, which restricts changes to registration information. Its availability varies by registrar, and some do not offer it.
When switching providers, use the change of sponsoring registrar procedure: obtain the authorization code from the current registrar, then apply to the new one. It can take several days, so do not start on the day the contract ends.
DNS: save the current settings before any change
DNS is the setting that ties your domain to servers and email. The records that point to your website and those that route your email are managed separately, and changes here are where accidents tend to happen.
A common mistake is switching DNS management along with a server move and not carrying over the email records. The website works, but enquiry notification emails stop arriving.
When I change DNS, I follow this order:
- Export and save every current record
- Write down the change and the reason for it
- Decide the rollback steps first
- After the change, check both the website and sending and receiving email
- Record the change in the operations log
Keep the number of people with DNS editing rights to a minimum. If an outside provider needs them, grant them only while working, or through an account dedicated to that person.
Server and CMS updates: scope depends on how the site is run
IPA's Information Security Guidelines for SMEs, Version 4.0 explain that what you must secure yourself depends on how the website is operated.
| Operating model | Server-level security | What your side handles |
|---|---|---|
| Own server (on-premises) | All your own | Everything |
| Rental server or cloud | The provider | Security related to building and running the site |
| Online mall or ASP (a service providing the functions as a bundle) | The provider | Updating content and managing login credentials |
Your model changes what you outsource. With an all-in-one service such as Wix, outsourcing is mostly text updates, and credential management stays in-house. With WordPress on a rental server, maintenance centres on updating the core and plugins and keeping up with PHP versions.
Write the update procedure into the operations log:
- Take a backup before updating
- If possible, test in a staging environment (a copy of production for checking)
- After updating, check the home page, a contact-form submission, receipt of the email, and login to the admin screen
- Decide in advance how to roll back if something breaks
- Delete unused plugins and themes
A contact form can look correct and still fail to deliver. Always include a real test submission in the update checks. IPA's 20 Points for Secure Website Operations is a checklist meant to be reviewed regularly; I recommend going through it with your provider at least once a year. If you have custom-built forms or features, review IPA's How to Secure Your Website with the developer.
A backup only helps once you have restored from it
IPA's guidelines added "Take backups!" to their six basic security principles, and list regularly checking that backed-up data can be restored.
There is more to save than the website files.
| Item | Easy to miss because |
|---|---|
| The CMS database | Articles and enquiry history live here, not in files |
| Uploaded images and attachments | They are large and often left out |
| Configuration files | They hold environment-specific settings |
| The list of DNS records | It needs saving after every change |
| Often a separate contract from the website |
Do not rely on the hosting company's backups alone. Retention and restore conditions vary by plan, and if tampering goes unnoticed for long, every stored generation may already be compromised. IPA's Guide to Using Cloud Services Safely includes "take responsibility for backups", advising you to keep important information in your own hands and take multiple generations.
A few times a year, actually restore one.
Restore test procedure
1. Prepare a test environment (do not overwrite production)
2. Restore files and the database from the backup
3. Check the home page, inner pages, images, admin login and a form submission
4. Record the time from start to finish
5. Write down what failed and what to change next time in the operations log
The time record is the important part. When an incident happens, it lets you tell customers and colleagues how many hours recovery will take.
Multi-factor authentication and how to hold access
Japan's Ministry of Internal Affairs and Communications, on its cybersecurity site for the public, describes multi-factor authentication as combining two or more of knowledge, possession and biometric factors, and encourages using it wherever a system allows.
Set it up in this order: domain management, server management, CMS administrators, Google accounts, then accounting and billing screens. Lose control of domain management and every other safeguard loses its footing.
Keep access to three rules:
- Create an account per person; do not share IDs and passwords
- Give outside providers only the access their work needs, and remove it when the contract ends
- Review the administrator list every quarter and remove anyone who no longer needs access
If all authentication sits on the owner's smartphone, a phone change or loss can lock the whole company out. Print recovery codes and keep them somewhere lockable, and register a second administrator where possible.
Responsibility-split table: decide before an incident
This table shows a common division of responsibilities. The actual split is decided in the contract.
| Event | Your company (the client) | Outside provider (build and maintenance) | Hosting and other providers |
|---|---|---|---|
| Domain expiry | Keep payment method valid, receive notices | Check the date in the log and alert you | Renewal desk |
| DNS misconfiguration | Approve changes | Change and roll back by procedure | Run the DNS platform |
| SSL certificate expiry | Receive notices | Check renewal settings | Provide auto-renewal (plan-dependent) |
| Server outage | Decide what to tell customers | Isolate the cause, contact the provider | Restore service |
| CMS updates | Approve downtime and cost | Carry out and test | Provide the platform |
| Form not delivering | Report the fault, check receipt | Investigate and fix | Run email delivery |
| Defacement or unauthorised access | Decide on taking the site down, contact stakeholders, decide on reporting | Investigate, restore, preserve records | Provide logs, isolate |
| Account takeover | Recover as the named account holder | Check the extent of impact | Identity-verification procedure |
| Suspected personal-data leak | Decide on and make reports and notifications | Investigate facts and report | Provide logs |
| Backup and restore | Review test results | Take backups and maintain the restore procedure | Automatic backups (plan-dependent) |
There is a reason to put this table in the contract. IPA's guidelines state that even when an outsourced party is at fault, those affected will hold the outsourcing company responsible for its oversight, and that the contract should state the outsourced party's responsibilities and required measures. Outsourcing does not remove your accountability.
When you suspect an incident, first, do not rush to delete things. IPA's incident response guide advises cutting the network or stopping services when damage could spread, while taking care not to erase records left on the system through careless actions such as switching equipment off.
Japan's Personal Information Protection Commission gives, as one example of a reportable case, a website that has been tampered with so that personal information entered by users is sent to a third party. A report should be made promptly once discovered, and where the act may have been done for an improper purpose, within 60 days of discovery. Confirm whether and what to report case by case with a lawyer or other specialist and the Commission's guidance.
Handover sheet for when someone leaves
Once a departure is decided, fill in this sheet before their last day.
| Item | Action | How to confirm it is done |
|---|---|---|
| Domain contacts | Update the registration contact and notice address | Check WHOIS and the registrar's screen |
| Names and billing on server and other contracts | Change to a company address | Invoice emails arrive at the new address |
| Admin login details | Disable the leaver's accounts | The leaver cannot log in |
| Multi-factor registrations | Remove the leaver's phone, register another device | Login works from the new device |
| CMS administrators | Delete unneeded administrators | Check the administrator list |
| Search Console | Update owners and check unused tokens | Check under Users and permissions |
| GA4 | Update administrators | Your company account has access |
| Decide forwarding and a shared inbox | Notices are received | |
| Provider contact | Tell providers the new point of contact | The provider replies |
| Operations log | Bring it up to date; the next person reads it | The next person can log in alone |
In Search Console, an owner who has been removed can re-verify ownership while their verification token remains. This is covered in what to check in a monthly retainer contract.
A one-person provider is itself a single point of failure
I work alone myself, so I will be direct. With a one-person provider, if that person cannot work because of illness or an accident, everything stops. It is the flip side of the benefit of fast contact and one person knowing the whole picture. Expecting round-the-clock support from one person is not realistic either.
| Aspect | One-person provider | Company |
|---|---|---|
| Point of contact | You reach the person directly | Through an account manager |
| Risk during absence | Stops if the person cannot work | A team exists, but staff rotate |
| Handover | Only in their head unless documented | Not necessarily documented internally either |
| Cost tendency | Little company overhead | Organisational costs are added |
Whichever you choose, the steps are the same:
- Keep domain, server, CMS and analytics accounts in your company's name
- Receive updated procedures and system descriptions after each piece of work
- Avoid adding custom mechanisms that only one person can fix
- Decide what happens if you cannot reach them for three business days, and have candidate replacements in mind
- Write into the contract what is handed over on termination and how far the provider will cooperate
Operations log template
Copy this template. Never write passwords in it; record only where they are kept.
Website operations log (template)
Last updated: Updated by:
[1. Basics]
Site URL / purpose / internal owner / outside provider and contact
[2. Domain]
Domain name / registrant / sponsoring registrar / expiry date
Renewal contact / payment method / control panel login URL
Where login details are kept / where multi-factor is registered
[3. DNS]
Where it is managed / last changed / where the record list is kept
[4. Server and CMS]
Provider and plan / contract name / billing contact / CMS type and administrators
Plugins in use / last updated / where the update procedure is kept
[5. Backups]
What / how often / where stored / generations kept / last restore test / time taken
[6. Measurement]
Search Console owner / GA4 administrator / where the enquiry ledger is
[7. Contacts]
Incident contacts / order of contact / what to do if unreachable
[8. Change history]
Date / who / what / result of checks
What to outsource, and what drives the cost
Rates vary widely with conditions, so here are the factors that drive cost instead.
| Factor | Why it affects cost |
|---|---|
| Type of site | ASP-style services have no CMS updates; own servers have the widest scope |
| Number of plugins or custom features | More checking after updates |
| Update frequency | Weekly or monthly |
| Support hours | Whether nights and weekends are included |
| Number of restore tests | How many times a year |
| Documentation | Whether a log is created and maintained |
When you get a monthly quote, confirm in writing the monthly cap on hours and what is not included. The arithmetic for turning a monthly fee into hours is in what a ¥50,000–¥100,000 monthly SEO or website retainer can buy. If you are building or rebuilding the site, also see what it costs to outsource a website, and how to brief it.
When I take on maintenance, I likewise start with an inventory of the domain and access, and agree in writing a monthly cap on hours and the scope of support. I do not guarantee response times. Details are on the website fixes and maintenance page.
Three things to check this week
This week, do just these three things.
- Fill in the inventory table
- Check the domain registrant and where renewal notices go
- Confirm with your provider or in-house where backups are stored and when a restore was last tried
If you can answer all three, you are ready to start talking about what to outsource.