When Everything Went Offline: Why IT Documentation and Ownership Matter
Updated: Aug 25
Updated August 2026: I originally wrote this article after helping a small business recover from a situation where its email and website suddenly stopped working and the owner discovered that she did not know where critical parts of the company's technology actually lived. The original lesson was about documentation, and that is still important, but after working through more situations like this with small businesses, I think the bigger lesson is ownership.
A business can outsource the management of its website, Microsoft 365, network, backups and other technology without giving up control of those assets.
That distinction has become one of the principles behind how I run SNL-Tech Services. I have worked with businesses that felt trapped by previous technology providers because they could not get administrative credentials, documentation or enough access to move forward without the provider's cooperation. Those experiences influenced a deliberate decision I made about my own business. I want clients to stay with me because they trust me, because I know their environment and because they see value in having me manage their technology. I never want ownership or a lack of access to be the reason they feel they cannot leave.
That is also why I describe SNL-Tech Services as an IT partner rather than just another vendor. To me there is a meaningful difference. I can manage the technology, maintain it, document it and make recommendations, but the business should still understand what it owns, where its critical systems live and how it could regain control if the person managing those systems were suddenly unavailable.
The Business Lost Its Website and Email at the Same Time
The client story that originally led me to write this article started with a business that had been operating for years without much trouble from its technology. There was no internal IT person. Someone the owner knew had originally set up the website, email and domain, and everything had continued working, so there had never been much reason for the owner to think about what was happening behind the scenes.
Then one Monday morning the company's email stopped working. Shortly afterward, a customer called and told the owner that the website was down too. The owner reached out to the person who had originally set everything up, but his phone number had been disconnected. She eventually learned that he had moved across the country and was no longer in business.
That was when the deeper problem became visible. She did not know where the company's domain was registered. She did not have the credentials for it. She did not know what email platform the business was using, and there was no documentation showing how any of those pieces fit together. For four days, the business had no functioning website and no way to send or receive company email. By the time she reached me, she was trying to run the business through her personal phone while also trying to figure out who controlled technology that the company had depended on for years.
I helped recover access to the domain, established a new email platform and connected the business with a web developer who could rebuild the website. I also helped document the accounts and put a better management structure around the environment. The business ultimately became a client, and I continue maintaining its accounts, network documentation, equipment inventory and other technical information as the environment changes.
What stood out to me after the immediate problem was solved was that nothing had technically looked wrong until everything stopped working. The business had a website. Email worked. Customers could reach them. The owner had every reason to think the technology was being taken care of. What was missing was the ability to independently understand and control the systems when the person managing them disappeared.
Why IT Documentation for Small Business Matters
Good IT documentation should tell a business what it has, how important systems are configured, who manages them and where to find the information needed to support the environment. Ownership adds another question:
Could the business still control those systems if the current provider were no longer available?
That is why I do not think it is enough to tell a business owner, “Your web developer handles the website,” or “Your IT company handles Microsoft 365.” Those may both be perfectly reasonable arrangements. What I also want to know is whose account controls the service, who has administrative access, where the billing relationship sits, what the recovery process is and whether the business could transition to another qualified provider if circumstances changed.
The business owner does not need to become the system administrator. In fact, part of what clients hire me for is so they do not have to manage DNS records, Microsoft policies, network configurations or the other technical details themselves. What I want is a separation between management and ownership.
A provider can manage an asset without becoming the only route to that asset.
What Technology Should a Small Business Actually Control?
There are several business assets I pay particular attention to because losing control of any one of them can create a much larger operational problem.
Business asset | What I want the business to understand or control |
Domain name | Which registrar holds the registration, who the registrant is, when it renews, how the account is accessed and how control can be recovered. |
DNS | Where the authoritative DNS is managed, who can change records and how administrative access is maintained. |
Website hosting | Where the site actually lives, whose account controls the hosting environment and whether the business has appropriate independent access. |
Website files and database | Whether a complete copy can be obtained so the site could be restored or moved if necessary. |
Website backups | What is backed up, where copies are kept, how they can be accessed and what would be required to restore the site. |
Business email | Which platform provides the service, who controls the organization or tenant, what administrative continuity exists and how access could be recovered. |
Microsoft 365 | Tenant ownership, appropriate administrative access, emergency access planning, licensing information and current documentation. |
Cloud applications | Who owns the company account, which administrators exist, how billing works and how access is recovered or transferred. |
Network equipment | What the business owns or leases, how the equipment is managed, where configurations and credentials are documented and what depends on it. |
Backups | What is actually protected, where recovery copies exist, who can administer them and how recovery works. |
IT documentation | A current record of the environment that the business itself can access, not information available only through the provider managing it. |
The exact systems will differ from one company to another, but the principle is the same. If the business depends on something to communicate with customers, operate, get paid, access information or maintain its online presence, I want somebody to know where it lives and how the company retains control of it.
Your Domain, DNS and Website Are Three Different Things
One of the conversations I had with a client recently is a good example of why I separate these assets. We had access to the client's account where the DNS records were being managed, but there was a question about where the actual website lived. Having DNS records in one platform does not mean that platform is necessarily hosting the website. DNS can simply point traffic toward a completely different server where the website files and database are stored.
My concern was not that the existing setup was necessarily wrong. What I wanted to understand was what access the business itself had to the environment where the website actually lived.
If the site was hosted on a server controlled by one individual, could the company obtain the full WordPress site and database?
Did it have access to backups?
Could the site be moved to another hosting provider if the business ever needed to make a change?
would happen if the server were compromised, stopped working or the relationship with the person maintaining it changed?
I ask those questions because I have already lived through the other version of that story. In a separate client situation, a company's website was hosted on a local web developer's server and the site eventually became compromised. Because the developer controlled the hosting environment, we did not have the access needed to go into that environment and remediate the problem ourselves. It turned into roughly a month of trying to reach the developer and waiting for the problem to be addressed while the client had very little control over its own website.
That experience is one of the reasons I generally prefer business websites to be hosted through an established hosting platform under an account the business controls. A web developer can still have all of the access needed to design and maintain the site. The important part to me is that the business has a realistic path to recover, move or hand the website to someone else without depending entirely on one person.
I Am Building That Ownership Into a Website Project Right Now
I am currently helping one of my managed clients through a website rebuild where we have been able to apply this thinking from the beginning instead of trying to fix an ownership problem after something goes wrong. Their existing website is hosted through a third-party, and when the discussion came up about rebuilding it through another third-party arrangement, I recommended structuring the new site differently.
I helped establish a managed WordPress hosting environment with a well known hosting provider so that the business can maintain control of the hosting relationship. I then introduced the client to a marketing company that will handle the actual website design. Once the project is complete, the designer will hand the completed site over to the client and remain available if the business needs additional design help later.
My role is different from the designer's role. I am not building the website. Once it is complete, I will handle the technical management I am responsible for, including keeping the WordPress platform and plugins current and making sure the malware scanning and backup processes stay current. The marketing company handles design. I handle the ongoing technical management within my scope. The client maintains ownership and control of the asset.
That is the arrangement I prefer because it does not require the client to become a web developer or hosting administrator. It simply means professional help and business ownership can exist at the same time.
I Apply the Same Rule to My Own Managed IT Clients
This philosophy becomes particularly important because I operate SNL Tech Services as a single operator MSP. My clients rely on me to manage their technology, and I take that responsibility seriously, but I also do not want myself to become their single point of failure.
Microsoft 365 is a good example. For tenants I manage, I maintain the administrative access required to do my job, but I also establish emergency access planning so the business has a path into its own environment if normal administrative access becomes unavailable. Microsoft refers to these as emergency access accounts, although they are often called break glass accounts. Microsoft's current guidance recommends organizations maintain at least two cloud only emergency access accounts with Global Administrator access and protect them using phishing-resistant authentication.
For clients where I have implemented them, I use YubiKey FIDO2 security keys as part of that emergency access design. The client has its emergency access capability, and I maintain the access I need to manage the environment. The purpose is not for the owner to use those accounts for everyday administration. They exist so the business is not completely dependent on my normal administrative access during an emergency.
I talk more broadly about why administrative continuity, vendor access and documentation matter in Microsoft 365 for Small Businesses: Is Anyone Actually Managing Your Environment?. That article focuses on the ongoing management of Microsoft 365. The ownership principle here is simpler: a provider managing your Microsoft environment should not mean the business has no independent recovery path into its own tenant.
My Clients Should Have Access to Their Own IT Documentation
I take the same approach with the documentation I maintain for managed clients. For one construction company I support, I keep the operational documentation I need inside my own management environment, but I also created a documentation library inside the client's SharePoint environment and shared it with the owners.
When I make meaningful changes to their environment and update the documentation I maintain, I update the client's copy as well. That means I am maintaining the information in two places, my own management environment and theirs, and I am comfortable with the additional work because it serves a specific purpose. I want the owners to have ongoing access to current information about their own technology.
The client should not need to contact me years from now and hope I can produce documentation about an environment that belongs to them. I manage the technology and maintain the documentation, but the information describes their business, their systems and their assets, so I think they should have access to it too.
This is also one of the reasons my Microsoft 365 Audit and Tenant Security Review includes documentation as an important deliverable. I do not want an audit to end with a list of recommendations that exists only in an email. I want the business to have a useful record of what was found, what is configured and what changed when remediation is performed.
Why I Call Myself an IT Partner Instead of Just Another Vendor
I have worked with businesses that felt like they were being held hostage by a previous provider because they could not get all of their information. That does not mean I assume every provider who is slow to produce documentation or credentials is intentionally trying to trap a client. What matters is the position the business finds itself in when it wants to make a change and discovers that the information or access it needs is controlled entirely by someone else.
Those experiences influenced how I decided to run SNL Tech Services. I made a deliberate decision that I did not want access or ownership to be the reason a client stayed with me. I want them to stay because they trust the way I manage their environment, because I am proactive about what is coming and because they see the value in the relationship.
That is what I mean when I say I want to be an IT partner, not another vendor. To me, partnership includes protecting the client's ability to remain in control of its own business. I can maintain Microsoft 365, manage a firewall, document a network, work with a website designer or coordinate other technical services without making myself the owner of those assets.
I think a good test for any technology relationship is this:
If the person or company managing this technology disappeared tomorrow, could the business continue forward with another qualified provider?
That does not mean the transition would be effortless. A good provider has knowledge and context that naturally take time to transfer. What I do not want is for the transition to become impossible because nobody besides the previous provider has the credentials, documentation or legal control needed to access the systems.
Document the Recovery Path, Not Just the Password
Keeping a list of passwords is not enough either. Modern business systems often depend on MFA, recovery contacts, administrative roles, backup authentication methods, support relationships and billing information. A username and password may tell someone how an account normally works while providing very little help during an actual lockout.
For critical systems, I want the business to understand enough of the recovery path to answer questions such as:
Which company or platform provides the service?
Which business account controls it?
Who has administrative access?
What MFA or passkey methods are configured?
What happens if the normal administrator is unavailable?
Which email address or recovery method is used for account recovery?
Does that recovery method depend on another service that could fail at the same time?
Who is authorized to contact the vendor or registrar for support?
Whose payment method is attached to the account?
When does the service or registration renew?
Where are current backups and documentation kept?
Could the service, data or website be moved to another provider if necessary?
That last question is one I think business owners should ask more often. Portability may not be simple for every platform, but the business should at least understand what would be involved before a crisis forces the question.
A Business Controlled IT Mailbox Can Still Be Useful
I still like using a dedicated business controlled mailbox for IT related vendor notices, security alerts, renewals and account administration where it makes sense. It helps keep important technology communications from disappearing into an employee's personal inbox and gives the business a consistent contact point as staff or providers change.
I would not treat one mailbox as the only recovery mechanism for every system, however. If the company's email platform itself is unavailable, a recovery process that depends entirely on receiving a message in that same platform may not help very much. The correct recovery design depends on the vendor and service involved, which is why I want those recovery methods documented rather than assuming every account works the same way.
The same applies to MFA. CISA recommends businesses use MFA broadly and prioritize administrative accounts, with phishing resistant methods preferred where available. The important business question is not simply whether an account has MFA turned on. It is whether the company understands who controls the account and how authorized people regain access when something changes.
Ownership Does Not Mean Doing All of This Yourself
I do not expect the owner of a small business to personally maintain DNS, configure Microsoft Entra ID, update WordPress plugins, map a network and keep track of every administrative setting. That would defeat a large part of the reason businesses hire technology providers in the first place.
The distinction I want owners to understand is that outsourcing management does not require outsourcing ownership.
Your IT provider can manage Microsoft 365 while your business maintains appropriate emergency access and documentation. Your web developer can build and update the website while your business controls the hosting relationship. Your IT provider can manage your firewall while the business knows whether the equipment is owned or leased and has documentation showing how the network is structured.
The client can own the asset without doing the day-to-day work.
That is how I prefer to structure the relationships I manage.
Questions Every Business Owner Should Be Able to Answer
You do not need to know every technical setting in your environment, but I think you should be able to get clear answers to questions such as:
Where is our domain registered, and is the business the registrant?
Where is DNS managed?
Where is our website actually hosted?
Does the business have access to the hosting account?
Can we obtain a complete copy of the website and database?
How is the website backed up?
Which platform provides our business email?
Who has administrative access to Microsoft 365 or the email platform?
Do we have an emergency administrative access plan?
Which major cloud applications does the company rely on?
Are those accounts registered to the business rather than an employee or vendor?
Which IT equipment do we own and which do we lease?
Where is our current network and system documentation?
Can the owners or another authorized person access that documentation?
If our current IT provider, web developer or another vendor became unavailable, could another qualified provider take over?
If several of those questions cannot be answered, I do not think that automatically means something is wrong with the technology. It means the business may have an ownership and continuity gap worth addressing while everything is still working.
When Everything Works, Ownership Is Easy to Ignore
That is ultimately what the original client story taught me.
For years, the website worked. Email worked. The person who set everything up was available. There was no reason for the owner to think about the registrar, DNS, administrative accounts or documentation because none of those things were getting in the way of running the company.
Then the person disappeared and several systems failed at the same time.
The technical problems were fixable. What made the situation much harder was that the business did not have the information and access needed to begin fixing them.
That is why ownership is something I want to address before a client needs it. I want the domain properly controlled. I want the business to understand where the website lives. I want administrative continuity in Microsoft 365. I want the environment documented, and I want my managed clients to have access to the documentation that describes their own systems.
can manage all of those things for a client without owning them.
That is the difference I want between being another technology vendor and being an IT partner.
If your business is not completely sure who controls its domain, website, Microsoft 365 environment, network accounts or other critical technology, SNL Tech Services Business IT Solutions can help establish that baseline and document what the business actually has.
Want to Check Your Own IT Ownership and Documentation?
The original version of this article included my IT Documentation and Ownership Checklist, The checklist gives a small business owner a practical place to start identifying critical accounts, vendors, equipment and documentation before something goes wrong.
Download the IT Documentation and Ownership Checklist
Additional Resources
ICANN: Information for Domain Name Registrants
ICANN explains the role of the registrant, the relationship with the registrar and the registrant's rights and responsibilities for managing a domain registration.ICANN Information for Domain Name Registrants
ICANN: Domain Name Registrant Contact and Access FAQ
ICANN specifically addresses situations where a domain was registered by a web developer or administrative contact and the business later cannot access it. ICANN recommends keeping domain management credentials even when administration is outsourced.ICANN Registrant Access FAQ
ICANN: What Domain Name Registrants Should Know
ICANN provides practical guidance about maintaining control of a domain registration and cautions against making a web designer, hosting provider or other third party the registrant of record without carefully considering the implications.ICANN Domain Registrant Guidance
Microsoft Learn: Manage Emergency Access Administrator Accounts in Microsoft Entra ID
Microsoft's current June 2026 guidance recommends maintaining at least two cloud only emergency access accounts and using phishing resistant authentication such as FIDO2 passkeys for emergency access. It also covers secure storage, monitoring and regular validation of those accounts.Microsoft Entra Emergency Access Accounts
Microsoft Learn: Secure Privileged Access in Microsoft Entra ID
Microsoft's guidance covers privileged administrative accounts, emergency access planning and reducing dependence on individual administrator accounts.Microsoft Entra Privileged Access Guidance
CISA: Require Multifactor Authentication
CISA's small business guidance recommends MFA for business systems, starting with administrative accounts and using phishing resistant methods when available.CISA Multifactor Authentication Guidance
Comments