A company prepares for a deal, changes contractors, enters a new market, or restores the site after an outage. In each of those cases the same question comes up: what the company’s digital system is made of, who controls it, and whether it keeps working when the people involved change. The answer decides what the site is worth in a deal and what its further development will cost; sales diagnostics and brand presence in AI answers are outside the scope of this article.
A digital asset has five layers: rights, infrastructure, software, data and content, and accumulated commercial visibility. For the purposes of this article, a managed digital asset is the set of site components and connected systems for which the company can confirm the right to use, administrative control, a backup, and a handover procedure.
The article gives a way to check each layer and record the results in a register. The accounting and legal treatment of the components is determined by specialists under the applicable rules; this article shows which questions to put to them.
A digital asset has several layers
The five layers answer the question “what the system is made of.” The second axis answers “how the company owns it,” and there are five types of control.
Company property: a component whose copyright the company owns by contract or by law. Example: commissioned source code or the site copy. Administrative control: the component belongs to a third-party service and the company controls the account. Example: analytics, Google Search Console, ad accounts. Licensed component: the right to use is limited by license terms. Example: the CMS, theme, plugins, fonts, stock images, SaaS services. External resource: the component exists outside the company’s control. Example: reviews on third-party platforms, external links, mentions. Accumulated result: a state that markets and search engines change. Example: rankings and visibility.
The domain sits in a place of its own: the company holds the registration under an agreement with the registrar and controls the account, so both the contract and account access have to be confirmed.
The “layer × type of control” matrix shows exactly what has to be confirmed in each cell. For code it is a signed copyright assignment (or, for code written by employees, work-made-for-hire status) plus access to the repository. For analytics it is an account in the company’s name with administrator rights. For a CMS theme it is a license covering use on this domain. For rankings it is the Search Console history, which stays with the company even though the result itself can change.
Whether the asset is recognized on the balance sheet is determined by the applicable accounting standards, and that question is answered by the company’s accountant.
Infrastructure keeps the system running
Domain and DNS
The domain is registered to the company, and the registrar account carries the company’s contact details; a contractor’s or an individual employee’s contact in the domain record creates a dependency. What gets checked: the registrant name in the domain record, access to the registrar account, two-factor authentication, backup access for a second administrator, the renewal date, and the payer. Whoever controls the registrar account can change DNS or start a transfer. Transfer rules depend on the registrar and the top-level domain (TLD), so exact timelines are confirmed in the registrar’s own terms.
Hosting and servers
The hosting or server contract is with the company and payments come from the company. Backups exist, are stored off-site, and someone has tested a restore from them. A change log on the server makes it possible to see what changed and when. The check is simple: restore a test instance from the latest backup and record the time and the result.
Repository and deployment
Source code is kept in a repository where the company holds owner rights; the status of an invited collaborator means the owner is somebody else. Change history is preserved, collaborator rights have been reviewed, the release procedure is documented, and a release can be rolled back to the previous version. In the Inward Labs model, for development and integrations the client receives access to the repository and the server, a monthly report, and documentation once the work is complete.
Three questions test continuity: can the company renew the domain tomorrow, restore the site from a backup, and ship a fix without the previous contractor?
Rights decide what can be used
Technical access and legal rights are different things. Access to the repository allows the code to be changed; the right to use and transfer that code is set by contract and by law. The items whose legal basis must be checked: source code, design, copy, images, video, databases. Third-party components are checked separately: the CMS and its license, themes and plugins, libraries, fonts, stock materials, SaaS services, and contractor terms.
Under US copyright law the position is as follows. Copyright vests initially in the author of the work (17 U.S.C. § 201(a)). Code, design, or copy that an employee creates within the scope of employment is a work made for hire: the employer is considered the author and, unless both parties have agreed otherwise in a signed written instrument, owns the copyright (17 U.S.C. §§ 101, 201(b)). Work commissioned from an outside contractor, such as an agency or a freelancer, is a work made for hire only if it falls within one of the nine categories listed in the statute and both parties sign a written agreement saying so (17 U.S.C. § 101). Computer programs are not named among those categories, so custom code ordered from a contractor is generally not a work made for hire, and without a signed written assignment the copyright stays with the contractor. Other than by operation of law, a transfer of copyright ownership, including an exclusive license, is valid only if it is in writing and signed by the owner of the rights or the owner’s authorized agent (17 U.S.C. §§ 101, 204(a)). The rights of attribution and integrity under 17 U.S.C. § 106A apply only to works of visual art; electronic publications and works made for hire are excluded from that definition (17 U.S.C. § 101). The terms of the contract also matter, and a lawyer confirms how this applies to a specific situation.
The documents that confirm the right to use and to transfer: the contractor agreement with a signed copyright assignment and written acceptance of the deliverables; for in-house staff, job descriptions and employment agreements with an intellectual property assignment clause; licenses for fonts, images, and plugins; SaaS terms with the data export rules that apply when a subscription ends.
The list of questions for legal review: does the contractor agreement include a signed assignment of copyright in the code and the design; is there a valid license or other legal basis for every image and font on the site; do the CMS and plugin licenses allow the site to be transferred to another owner; in whose name are the SaaS accounts and who is entitled to transfer them; is employee-created work properly documented (employment agreements, intellectual property assignment clauses, job descriptions); what is the handover procedure if the contract with the contractor is terminated?
The owner should take the questions in this section to a lawyer for review; the article does not assess the terms of specific licenses.
Data accumulates value
Data is treated here as the history a company keeps and passes on. Using data for sales diagnostics is covered in the article on the route from search to sale.
Analytics data
The history of traffic, events, key events, and segments lives in the analytics account. What gets checked: the account owner, whether export is available, how deep the stored history goes. An account in the name of an employee who has left, or of a contractor no longer working with the company, means the history is lost along with the access.
Commercial data
Products, categories, prices, inventory, inquiries, orders, and transactions have a single source of truth: the accounting system, the CMS, or the CRM. When there are two sources and they disagree, the history becomes unreliable. Keeping a catalog of thousands of items manageable is part of our development service.
Interaction data
Internal search, session recordings, drop-off and objection reasons, and A/B test history accumulate slowly and cannot be recovered. A company that has lost two years of test history starts over from scratch.
For all three groups the checks are quality, completeness, access, backup, export, and documentation. The owner gets an answer to two questions: which history would be lost if an account or a system changed, and what it would cost to build it up again.
Automations hold the operating logic
Integrations with CRM, ERP, payment, delivery, and notifications are the company’s operating rules written in code; a single script only implements one of those rules. The inventory export schedule, the rule that turns an inquiry into a deal, the handling of a failed payment, the exceptions for particular categories — all of that is operating logic that keeps working as long as someone remembers how it is built.
An inventory of automations records for each one: inputs, outputs, schedule, processing rules, error handling, exceptions, owner, and the recovery procedure after a failure. In the Inward Labs model the integrations, settings, and data stay in the client’s infrastructure, and the documentation is handed over once the work is complete. An inventory like that shows which processes survive changes in people and systems, and which rest on one person.
Search visibility strengthens the digital asset
The search visibility built up by technical SEO together with development gives the business access to demand that already exists, and that is where its commercial value lies. At the same time rankings and visibility reflect a current state and they change: Google states directly that meeting its requirements, guidelines, and policies does not mean a page will be crawled, indexed, or served.
So two things are kept apart. Site structure, pages, content, technical decisions, data, and development history stay in the company’s infrastructure under the contract; these are the components that get handed over. Rankings and visibility are the result of those components performing in the market; they are observed and cannot be handed over. External links and mentions are not company property: they sit on third-party sites and can disappear without the company’s involvement; how that public data shapes brand presence in AI search is covered in a separate article.
Rankings and visibility are not declared to be the client’s property. What belongs to the client, or is transferred to them, is the code, structure, content, settings, data, accounts, documentation, and automations within the scope of the contract. Visibility and rankings remain a changing result produced by the market and by search engines.
That is how an owner separates the components the company holds from the market results that change.
Transferability shows the quality of the asset
Transferability is tested by one scenario: the system is taken over by a new employee, a new contractor, an in-house IT team, a buyer of the business, or an investor. The system is transferable if within an agreed timeframe the new owner receives rights, access, documentation, and backups, and can ship a change without the previous contractor.
An illustrative case. On day one the new team asks for access to the repository, the server, the domain, analytics, and the CRM, plus the integration documentation. It finds the repository in the previous developer’s personal account, the domain at a registrar with the contact details of an accountant who has left, and no description of how inventory data reaches the site from the accounting system. Every such finding turns into a task with an owner and a deadline.
Critical dependencies on personal accounts and on specific individuals are recorded in a separate list. Documentation reduces the dependency without removing it: a document describes the system as of the day it was written, and the system keeps changing.
The transferability test and the dependency list are two verifiable tools an owner takes into negotiations about a deal or a handover.
An investor checks manageability and risk
Technology due diligence before a deal looks at the same components through the lens of risk and future cost. Roland Berger’s consulting guide to due diligence of digital acquisition targets, published in August 2023, sets out the review areas: architecture and scalability, security, development processes and code quality, data and analytics, team, intellectual property, vendors, compliance, and technical debt. The guide provides the structure of those areas; this article quotes no statistics from it.
| Review area | Business consequence | Who reviews it |
|---|---|---|
| Rights and contracts | The component cannot be transferred or used after the deal | Lawyer |
| Architecture and scalability | Cost of growth: whether the system survives twice the catalog or twice the traffic | Technical auditor |
| Security | Risk of downtime and data loss; regulatory consequences | Security specialist |
| Data quality | Unreliable history for decisions and reporting | Analyst, financial auditor |
| Technical debt | Every new feature costs more than the last | Technical auditor |
| Critical dependencies | Operations halt when one person leaves or one service is switched off | Technical auditor, operations manager |
| Cost of development | The budget for the year after the deal | Financial and technical auditors |
| Business continuity | Time to recover after a failure | Technical auditor |
This table gives an investor a map of the questions that affect deal risk and the cost of development; legal, accounting, and security expertise is provided by the relevant specialists.
The register records what the digital asset contains
The register brings all the layers into one document. The mandatory rows: domain, DNS/CDN, server, CMS, repository, design, content, analytics, Search Console, ad accounts, CRM, integrations, backups, documentation. Nine columns are filled in for each row.
| Asset | Location | Owner | Administrator | Legal basis | Backup | Handover step | Criticality | Review cadence |
|---|---|---|---|---|---|---|---|---|
| Domain | Registrar | Company — finance director accountable | IT | Registrar contract, account in the company’s name | Second admin with break-glass access | Update the account contacts | High | Quarterly |
| DNS/CDN | DNS provider, CDN provider | Company | IT | Contract, account in the company’s name | Settings export | Hand over administrator access | High | Quarterly |
| Server | Hosting provider | Company | Development | Contract, company as payer | Off-site copies, tested restore | Hand over access and documentation | High | Quarterly |
| CMS | Company server | Company | Development | CMS license, theme and plugin licenses | Included in the server backup | Confirm the license terms allow transfer | High | Twice a year |
| Repository | Git platform | Company — tech lead accountable | Development | Signed copyright assignment or work made for hire | Mirror or backup | Transfer owner rights | High | Quarterly |
| Design | Design system files | Company | Marketing | Signed copyright assignment, font licenses | Copy in company storage | Hand over files and licenses | Medium | Annually |
| Content | CMS, storage | Company | Marketing | Author agreements, image licenses | Included in the backup | Hand over with the CMS | Medium | Annually |
| Analytics | Analytics service | Company | Marketing | Account in the company’s name | History export | Grant Administrator access to the new team | High | Quarterly |
| Search Console | Google service | Company | Marketing | Account in the company’s name, domain verification | Report export | Add the new team as owner | Medium | Quarterly |
| Ad accounts | Ad platforms | Company | Marketing | Account in the company’s name, company as payer | Campaign history | Hand over administrator access | Medium | Quarterly |
| CRM | CRM service | Company | Sales | Subscription in the company’s name | Database export | Confirm export terms before termination | High | Quarterly |
| Integrations | Server, iPaaS | Company — process owner accountable | Development | Code under contract, service licenses | Documentation and a copy of the code | Hand over documented inputs, outputs, and schedules | High | Quarterly |
| Backups | Separate storage | Company | IT | Backup policy | Tested restore | Hand over storage access | High | Monthly |
| Documentation | Company storage | Company | Development | Internal document | Copy | Hand over as is | Medium | Twice a year |
Rows with empty cells, or with “unknown” in them, become tasks. The register is reviewed on the dates set in it and attached to the deal or handover documents.
The work product stays in the client’s infrastructure
The Inward Labs contract model is built on the work product belonging to the client company. Code, copy, settings, analytics configurations, accounts, and accumulated data stay in the client’s infrastructure. Accounts are created in the company’s name, or moved under its control where the work calls for it. The client can keep using the work product without placing further orders. The exact scope of rights and the handover procedure are set by the contract in force, and that is where the inventory starts for Inward Labs clients.
What the owner should do
- Appoint an owner for the digital asset register and fill in the fourteen rows; the Inward Labs approach treats architecture, code, data, and search visibility as connected business assets, and the register reflects exactly that composition. Owner: head of the company or finance director. Timeframe: two weeks.
- Check administrative control over the domain, the repository, and analytics: account in the company’s name, owner rights, backup access. Owner: IT or the tech lead. Timeframe: one week.
- Give the lawyer the list of six legal questions together with the contracts and licenses. Owner: the company’s lawyer. Timeframe: one month.
- Run a test restore of the site from a backup and record how long it takes. Owner: development. Timeframe: two weeks.
- Set the date of the next register review and attach the register to the deal or handover documents. Owner: the register owner. Timeframe: once the register is filled in.
RUN AN INVENTORY OF YOUR DIGITAL ASSET
Inward Labs will record the composition of the system, its owners, access, dependencies, and the handover procedure.
