The 60-Minute Website Vendor-Exit Drill: Can Your Business Operate Without Its Agency?

01 · Define control

What this drill actually tests

A handover checklist usually asks whether you have a domain login, hosting details, source code, analytics and backups. Those checks are useful, but possession is not proof. A two-year-old ZIP is not necessarily the source running in production. A backup has not demonstrated value until somebody restores it. Viewer access is not administrative control.

Original GreyBath editorial diagram. It is a control model for this audit, not an industry certification.

A company may legally own custom code but have no current copy. It may have hosting access but no tested database restore. It may see Google Analytics reports but lack the Administrator role needed to manage users. The purpose of the drill is to find the point at which the business would stop functioning during an exit or emergency.

02 · Prepare, do not disrupt

Run the first pass independently

Start with the people and evidence already available inside your organisation. If the first step is “call our developer and ask where that is”, record a dependency. It does not prove that the vendor has done anything wrong; outsourcing technical administration can be sensible. The question is whether the dependency is known, documented, recoverable and acceptable.

Do not revoke access, rotate keys, unlock a domain, change DNS records or test a deployment during this management audit. Service accounts, deploy keys, webhooks and verification tokens may rely on the current arrangement. After the first pass, involve the provider to verify facts and plan safe remediation.

Build one control sheet

Create a restricted spreadsheet or register. Do not paste passwords, API keys, one-time codes or account-recovery codes into it. Record the approved secure location of credentials instead.

Working templateScroll horizontally to view every fieldEach asset is grouped into a readable card below

03 · Gather evidence

The 60-minute website vendor-exit drill

Original GreyBath editorial roadmap. The time boxes guide discovery; they are not recovery-time promises.

Minute 0–8: Prove domain control

Start with the domain because it can affect the website, business email, subdomains and service-verification records. Identify the registrar using internal records and, for applicable domains, ICANN Lookup. An invoice from a reseller does not by itself identify the registrar of record.

Ask an authorised business user to sign in and verify the account name, email, recovery route, MFA, renewal status, payment method and expiry date. Do not unnecessarily unlock the domain. For gTLD transfers, ICANN explains that an Auth-Code is required and may be available through the registrar’s control panel or supplied through the applicable request process. The audit only needs to establish that an authorised holder knows the route.

Pass: the organisation can access the registrar, understands recovery and renewal, and knows the registrar relationship. Dependency: only a provider or one individual can act. Unknown: nobody can identify the account or recovery path.

Minute 8–15: Identify who controls DNS

The registrar and authoritative DNS provider may be different services. Record the nameservers, provider, business approval route and an appropriate administrative or recovery path. If the provider supports a zone export, note where a current copy can be maintained. Otherwise document the important records and their purpose.

Do not modify production records or delete an unfamiliar TXT, MX or CNAME entry. It may support email, a subdomain, a verification method or another business service. Ask one practical question: if the website server changed tomorrow, who inside the organisation could authorise the DNS change?

Minute 15–23: Verify hosting and deployment control

“Hosting” may actually be a shared account, VPS, cloud subscription, deployment platform, CDN, object store, database service—or several of these. The managing director does not need root access to every server. The organisation does need to know who owns the commercial relationship, who can appoint or remove technical administrators, where production runs and how a change reaches it.

Minute 23–31: Prove the current source exists

For a custom site, find the actual repository and verify its organisation or account owner, production branch, recent history, deployment relationship and build documentation. When repositories are held in a GitHub organisation, GitHub recommends at least two organisation owners so one unreachable owner does not make the organisation inaccessible.

A clean-clone test is stronger evidence than a ZIP archive: a technical person who did not build the project should be able to obtain the source, use documented dependency and configuration processes, build it and run it outside production. A large project need not complete that test inside this hour; record whether it has ever been done, when, and who owns the follow-up.

For a hosted builder, test account ownership, billing, administrators, content and media export, business-data export, domain control and what would need rebuilding after an exit. Lack of transferable source is not automatically a failure if the platform boundary was chosen knowingly.

Minute 31–41: Restore a backup—do not merely locate one

A “last backup” timestamp proves that a job reported something; it does not prove that the website can be recovered. AWS reliability guidance recommends periodic recovery testing and warns against assuming that a backup is valid without restoration evidence.

For application files, the database, uploads, configuration and any infrastructure definition, record what is backed up, how often, where it is stored and the date and outcome of the last isolated restore. Choose the frequency from acceptable data loss and business criticality rather than copying a generic “daily” rule.

A server restore may still leave the customer journey broken if it depends on DNS, identity, payment, CRM, SMTP, storage or another SaaS product. Capture those dependencies separately.

Minute 41–47: Trace forms and business-email delivery

Submit each commercially important form as a customer would: enquiry, quotation request, support case, dealer request or job application. Trace where the record goes, which mailbox or CRM receives it, which mail-delivery service sends notifications, who owns that service and how a failure becomes visible.

A browser “thank you” message proves only that the interface responded. It does not prove that the enquiry reached the person or system responsible for acting on it.

Minute 47–52: Verify Analytics and Search Console control

In Google Analytics, check account or property Access Management and confirm a named, business-controlled administrator. Google documents that users can be added at either level and that adding or changing users requires the Administrator role at the relevant level. Access to history can be lost or delayed when administration is informal; avoid a shared login.

In Search Console, confirm a business-controlled verified owner—not only a delegated full user. Google documents multiple verification methods and notes that more than one can help if an existing method fails. Record the property, verification method, recovery path and other owners. Do not remove a provider’s access during this audit.

Minute 52–57: Map hidden third-party dependencies

Look beyond the obvious accounts. A CDN, WAF, transactional-email service, CAPTCHA, consent tool, payment gateway, maps service, chat widget, font licence, search product, video host, image CDN, SMS provider, CRM or ERP integration may be essential even though it works silently.

For each service, record what it does, who owns the account, who receives the bill, what fails if it expires, where its credentials are managed and what must be rotated when a provider leaves. Do not copy the credential itself into the register.

Minute 57–60: Run the human-dependency test

For every critical asset, ask whether exactly one person knows how it works or exactly one person can recover it. The individual might be an agency owner, employee, freelancer, founder or IT administrator; the continuity risk comes from the concentration, not the job title.

Record second-owner coverage, controlled recovery and the offboarding route. Check whether former staff or vendors still have access, but plan removals with the current technical owner so service accounts and deployments are not broken.

04 · Prioritise the gaps

Score dependencies, not website quality

This scoring model is a prioritisation aid, not an industry security certification. Apply it to eight operational areas: domain; DNS; hosting and deployment; source or platform; backup and recovery; forms and email; Analytics and Search Console; and third-party services.

The maximum is 16. Do not turn the total into a cybersecurity grade. An individual zero can matter more than the total: a company scoring 14/16 may still face a serious continuity issue when the zero is attached to its domain.

05 · Fictional example

A manufacturer scores 9/16

Example Components Pvt Ltd is fictional. Its four-year-old website has had no major incident, so management assumes the company controls everything because agency invoices have always been paid. The drill produces this hypothetical result:

The result does not say that the website is badly designed or that the provider is untrustworthy. It identifies concentrated dependencies. The fictional company’s remediation order is:

1. Domain and DNS continuity: document the DNS service and establish an approved recovery route without changing live records.
2. Source continuity: mirror or move the project into an organisation-controlled repository with appropriate administrators.
3. Restore evidence: restore the backup into an isolated non-production environment and test the basic website journey.
4. Analytics control: add a named business-controlled administrator under the platform’s permission model.
5. Third-party inventory: map SMTP, CAPTCHA and other production dependencies to their accounts, owners and exit steps.

No redesign is required. The improvement is governance.

06 · Keep the result current

Turn the findings into a continuity register

The audit sheet captures a point in time. Convert confirmed facts into a maintained register, restrict access, and add a link or description for the evidence rather than a secret.

Maintained registerScroll horizontally to compare every fieldEach asset is grouped into a readable card below

Useful evidence includes “login tested”, “ownership screen checked”, “current export downloaded”, “restore completed” and “second administrator confirmed”. That turns a document into an audit trail.

07 · Avoid false red flags

When vendor-managed infrastructure is reasonable

Agency ownership or operation is not automatically a defect. Multi-client managed hosting, enterprise licences, managed CDN or WAF services, proprietary SaaS platforms and vendor-operated deployment infrastructure can be legitimate choices.

Judge the arrangement by its service boundary: is it documented; does the contract say what happens at termination; can required business data be exported; are renewals and licences clear; is the migration process understood; and does the organisation control its domain and essential identity or recovery routes?

A vendor-managed system can be operationally sound. An undocumented system that nobody inside the company can identify, recover or replace is the risk.

08 · Control without credential sprawl

Do not create a security problem while fixing an ownership problem

“Send every administrator password to the owner” is the wrong response. Organisational control means continuity of authority, not universal root access. Use named accounts, role-based permissions, least privilege, MFA, controlled recovery, an approved password manager and documented offboarding.

NIST’s final CSF 2.0 Small Business Quick-Start Guide recommends prioritising controls such as MFA, password management, restricted access and tested backups. CISA advises requiring MFA for remote and privileged or administrative access and aiming for phishing-resistant methods. Apply those principles according to the risk and platform; do not use them as a reason to give more people permanent administrator rights.

09 · Solve the problem earlier

Put the exit test into the next website contract

The easiest time to remove ambiguity is before development begins. Define the operational answer to each of these questions before signing:

Domain

Who registers and renews it, and which organisation controls recovery?

Hosting

Who owns or operates the account, and what is delivered at termination?

Source code

Which custom source is delivered, which third-party components remain separately licensed, and where is the repository?

Data

What can be exported, in which format, on what timetable and through which approved process?

Design assets

Which editable files, fonts and licences are included?

Accounts and credentials

Who creates accounts, grants access, protects recovery and revokes access?

Backups

What is backed up, how long is it retained, and how is restoration tested?

Maintenance

Which monitoring, updates and incident tasks remain the provider’s responsibility?

Exit assistance

Which documentation, exports, knowledge transfer and migration support are included, and at what cost?

Intellectual-property ownership, licensing and termination clauses should be reviewed for the actual contract and jurisdiction. Do not paste generic internet wording into a legal agreement.

10 · Treat control as a living state

Repeat the drill after trigger events

An annual review is useful, but event-based checks catch the changes most likely to invalidate your evidence. Repeat the relevant parts after changing an agency, losing a developer or administrator, redesigning the site, moving hosting or DNS, migrating business email, changing legal entity, acquiring a company, adding payments or customer accounts, introducing a CRM or ERP integration, or discovering an inaccessible account.

Set restore-testing frequency from the website’s business criticality, recovery objectives and rate of architectural change. AWS also recommends testing disaster-recovery implementation and testing again when significant changes can affect the recovery approach; there is no universal frequency that suits every website.

What the drill does not prove

Passing this exercise does not prove that the website is secure against every attack, legally compliant, accessible, fast, search-optimised, free of software vulnerabilities, correctly licensed, adequately insured or backed up to a particular regulatory standard. Those require separate evaluations.

The drill answers a narrower question: does the organisation have enough verified control and knowledge to operate, recover and transition its website without relying blindly on one provider or one person?

11 · Start with evidence

15 actions to take next

If any item cannot be completed without one particular person, the exercise has already found a useful dependency.