Reseller hosting can suit a law firm’s public website. It is not automatically suitable for confidential case files, client communications or legal documents, and no provider can make a firm compliant just by hosting it. The right way to decide is to ask specific questions about uptime, security, backups and data handling, then match the answers to what the hosting will actually store.<\/p>\n\n\n\n
Words like secure hosting and compliant hosting prove very little. Compliance depends on the jurisdiction, the data involved, the contracts in place and the firm’s own obligations. We are a hosting company, not lawyers, so nothing here is legal advice. What follows is a list of questions that separate real answers from marketing.<\/p>\n\n\n\n
We have hosted 700,000+ websites over 20+ years across 25 worldwide server locations, and legal clients tend to ask sharper questions than most. This guide is for law firms, and for the agencies and resellers who host websites for them.<\/p>\n\n\n\n
Ask what uptime is promised in writing, what the history shows, what the guarantee excludes, how outages are detected and who responds. A firm’s website is often the first place a client or a referrer looks, so an outage costs trust as well as enquiries. No provider can honestly promise that nothing will ever fail.<\/p>\n\n\n\n
A guarantee is a promise with a remedy, and history is evidence of how a provider actually performs. They are different, and a firm should ask for both. A page that says 99.9% uptime tells you what the provider is willing to credit you for. It does not tell you how often the servers stayed up.<\/p>\n\n\n\n
Ask whether the provider publishes a status page and keeps a record of past incidents. Ask how long the worst outage in the last year lasted and what caused it. A provider who answers plainly is worth more than one who recites a percentage. Be wary of anyone promising 100%. Nobody can.<\/p>\n\n\n\n
Do the arithmetic too. 99.9% over a month still allows around 43 minutes of downtime. Whether that is acceptable depends on the firm.<\/p>\n\n\n\n
An SLA is a contract, so read it like one. Look for how uptime is measured, over what period and what remedy applies when the target is missed. Remedies are usually service credits, not compensation for lost business.<\/p>\n\n\n\n
The exclusions matter more than the headline number. Scheduled maintenance, attacks, events outside the provider’s control and problems caused by the customer’s own site often fall outside the guarantee. Ask about the claim process too. If you must file within a short window, put that in your calendar.<\/p>\n\n\n\n
Remember that an SLA covers the infrastructure, not your website’s code. A broken plugin is not an outage the host will credit.<\/p>\n\n\n\n
Ask how the provider finds out something is down. Good answers describe automated checks, alerts that reach a person and staff who are available around the clock. Poor answers describe customers reporting problems.<\/p>\n\n\n\n
A law firm should also run its own monitoring on the website, separate from the host’s. Free and cheap uptime services check the site every few minutes and send an email or text. Independent monitoring gives you evidence of an outage after the fact, and it catches problems the host’s checks miss, such as a site that loads but shows an error.<\/p>\n\n\n\n
We run 24\/7 support, and a firm should expect response times described in terms of tickets and chat, not promises of instant fixes.<\/p>\n\n\n\n
Redundancy means no single failure takes the service down: more than one power source, more than one network path, spare drives and spare capacity. Ask what the provider has in place and which parts remain single points of failure. On a shared server, the server itself usually is one.<\/p>\n\n\n\n
Location matters too. Our 25 worldwide server locations let a firm host near its clients, and multi location hosting<\/a> can place sites in the region where visitors are. Distance affects speed, and it also affects which country’s rules apply, which we cover in the compliance section.<\/p>\n\n\n\n Do not confuse a CDN with redundancy. A CDN such as CloudFlare CDN<\/a> can serve cached copies of pages when the origin is briefly unavailable, depending on configuration, but it does not replace a working server for dynamic parts like contact forms.<\/p>\n\n\n\n Backups only help if you can reach them and restore from them quickly. Ask how a restore is requested, who performs it and how long it usually takes. Some providers restore on request through support. Others give you a self service panel. Know which you have before the day you need it.<\/p>\n\n\n\n Ask about connectivity as well. If the backup lives in the same data center as the server, a facility level problem can take out both. Ask where the copy sits and how it is reached. And ask for the procedure in writing, with steps and contacts, so that a stressed partner at 8 a.m. is not guessing.<\/p>\n\n\n\n The backup section later in this guide goes deeper. For now, remember the order of questions: where, how often, how fast and who.<\/p>\n\n\n\n Ask what controls protect the servers and the network, how connections are encrypted, how accounts are protected, how malware and vulnerabilities are handled, how fast patches go on and what happens when something goes wrong. Ask for specifics. A provider that answers every question with “we take security seriously” has not answered any of them.<\/p>\n\n\n\n Ask which controls are in place at the network edge and on the server: firewalls, attack mitigation, brute force blocking, intrusion detection and account isolation. Also ask about the data center itself, such as physical access control. Providers differ, and some controls are standard while others cost extra.<\/p>\n\n\n\n Ask who operates the facility. Many hosts rent space in data centers run by others, which is normal, but you should know who is responsible for what. A clear answer names the layers: facility, network, server and application.<\/p>\n\n\n\n Our own platform uses LiteSpeed web servers and supports CloudFlare CDN, which can add a filtering layer in front of a site. These are tools, not guarantees, and we would tell any firm the same: no tool makes a site invulnerable.<\/p>\n\n\n\n Every law firm site should load over HTTPS, especially any page with a contact form. SSL, technically TLS, encrypts data between the visitor’s browser and the server, so a message typed into a form cannot be read in transit. Ask whether certificates are issued and renewed automatically, and who watches for expiry. An expired certificate shows visitors a full page browser warning, which is damaging for a firm. Resellers can also offer certificates to clients through an SSL reseller program<\/a>.<\/p>\n\n\n\n One point firms often miss: HTTPS protects the trip, not the destination. A contact form message is encrypted on its way to the server, but once it is emailed to a partner it travels by email, which has its own protections. Think about where submitted information goes, and whether the form should ask for sensitive details at all.<\/p>\n\n\n\n Most website compromises start with a stolen or weak password, not a clever attack. Ask whether control panel logins support multi factor authentication, how admin accounts are separated and whether you can restrict who has access. Get the answer for your specific plan.<\/p>\n\n\n\n Inside the firm, practice matters as much as the feature. Use unique passwords in a password manager, turn on multi factor login for the hosting account, the domain registrar and the WordPress admin, and remove access when a staff member or contractor leaves. Many firms have a former web designer who still holds a working login.<\/p>\n\n\n\n Ask how support verifies identity too. A support agent resetting a password for the wrong caller is an access control failure at the provider’s end.<\/p>\n\n\n\n Ask whether the provider scans for malware, how often and what happens when something is found. Ask also whether scanning is the host’s job or yours. On many shared plans the answer is that the host protects the server while the customer protects the site.<\/p>\n\n\n\n Most law firm sites run WordPress or a similar platform, and outdated plugins are the usual way in. Vulnerability management means keeping the platform, themes and plugins updated, removing what is unused and watching for known flaws. Decide who does this and write it down: the agency, the firm or the host.<\/p>\n\n\n\n A scanner finds problems after they arrive. Updates and good access control stop many from arriving at all.<\/p>\n\n\n\n Ask how quickly the provider patches servers when a serious flaw is announced, and how customers are told. Ask whether maintenance windows are announced in advance. For incident response, ask for the steps: how they detect a breach, isolate an account, notify customers and restore service.<\/p>\n\n\n\n Notification deserves its own question. If personal data may have been exposed, a firm may have legal duties to act within set times, and those depend on the jurisdiction. Ask how quickly the provider will tell you, and through which channel. A provider that cannot describe its process is a risk in itself.<\/p>\n\n\n\n Logs answer the question of what happened. Ask which logs are kept, for how long and whether you can get them. Web access logs, control panel login records and email logs all help in an investigation.<\/p>\n\n\n\n Ask also about the provider’s own administrative access. Which staff can reach your account, and is that access logged? You do not need names, but you should expect a policy. Inside your own account, use separate logins for each person where you can, so logs show who did what. Shared logins make logs useless.<\/p>\n\n\n\n Keep the logs somewhere a compromised account cannot erase them.<\/p>\n\n\n\n Sometimes, for some uses, but no hosting plan is compliant on its own. Whether a setup meets a firm’s obligations depends on the jurisdiction, the data involved, the contracts in place and the technical controls used. A public marketing website is a very different case from a system holding client files. The firm’s own counsel or regulator should decide what applies.<\/p>\n\n\n\n A public law firm website holds marketing material: practice areas, lawyer profiles, articles and a contact form. Confidential legal systems hold case files, client communications, privileged documents and billing records. These carry very different risks and duties.<\/p>\n\n\n\n Shared reseller hosting is designed for the first kind of workload. It is built to serve web pages and run common web applications affordably, with many accounts per server. It is not designed or sold as a vault for privileged material, and a firm should not treat it as one.<\/p>\n\n\n\n If a firm wants a client portal or document sharing, look at dedicated systems built for that purpose, with their own security design, audit trails and contracts. The website can stay on ordinary hosting while the sensitive work lives elsewhere.<\/p>\n\n\n\n Start with an inventory. List what the hosting account holds: website files, a database of pages and users, contact form submissions, email, newsletter lists, analytics data and backups. Mark each as public, internal or confidential.<\/p>\n\n\n\n The surprise is usually the contact form. A form that emails messages leaves nothing behind, but a form plugin that stores entries in the database keeps every enquiry, including whatever visitors type. Many firms discover years of enquiries sitting in a WordPress table.<\/p>\n\n\n\n Decide what you actually need to keep. Data you never store cannot leak, so a form that asks for less, and a plugin set to delete old entries, are real controls.<\/p>\n\n\n\n Privacy duties vary by country, state and profession. A firm might be covered by data protection laws such as GDPR, local privacy statutes and professional conduct rules about confidentiality. Which ones apply depends on where the firm operates, where its clients are and what data it holds.<\/p>\n\n\n\n This article cannot tell a firm which rules apply. What we can say is how to prepare. Know what personal data the site collects, have a privacy notice that matches reality, collect only what is needed and be able to delete data on request. These steps help under most regimes.<\/p>\n\n\n\n Then ask the firm’s own lawyers or regulator. A law firm has the advantage of having people on hand who can answer the question properly.<\/p>\n\n\n\n Data location means the country where servers sit. Some rules and some client expectations care about it, since the laws of that country can apply to stored data. Ask the provider where your account’s data lives, including backups and email, and whether you can choose.<\/p>\n\n\n\n We operate in 25 worldwide server locations, which gives a firm choices when location matters. Do not assume location equals compliance, though. Moving a site to a local server may satisfy a client’s preference without settling any legal question.<\/p>\n\n\n\n Remember that a CDN and email services may handle data in other countries too. Ask about each service in the chain.<\/p>\n\n\n\n When a provider stores or handles personal data for a firm, privacy laws in many places treat it as a processor, and may expect a written agreement describing how the data is handled. Whether one is required for a basic website depends on what data the site stores and which laws apply.<\/p>\n\n\n\n Ask the provider whether it offers a data processing agreement, who its own subprocessors are, such as data centers, backup storage and email relays, and how it notifies you of changes. Read the terms of service for liability limits. They often cap what the provider owes you, and a firm should know that figure before an incident, not after.<\/p>\n\n\n\n If you are a reseller, you sit in the chain. You are the firm’s provider and our customer, so ask us the same questions, and pass on honest answers.<\/p>\n\n\n\n Responsibility is shared, and the split is usually set in the contract. The provider is responsible for its infrastructure: the facility, network, servers and the platform it runs. The firm is responsible for its data, its website, its staff’s access and its own legal duties.<\/p>\n\n\n\n The agency or reseller in the middle takes on the work of configuring and maintaining the site. Write down who does what: updates, backups, access reviews and the incident contact. Gaps between the three parties are where problems hide. A provider’s logo on a page does not move the firm’s obligations onto the provider.<\/p>\n\n\n\n Distrust any promise that hosting makes a firm compliant. Compliance is an outcome of how the firm operates, not a product feature.<\/p>\n\n\n\n Ask how often backups run, how long they are kept, where they are stored, who can access them, whether they are encrypted and whether anyone tests a restore. Then set recovery targets for the firm and compare them with what the provider can deliver. A backup that has never been restored is a hope, not a plan.<\/p>\n\n\n\n Frequency decides how much you can lose. Daily backups mean up to a day of changes may be lost. For a mostly static law firm site that is usually fine. For a site with a busy blog or stored enquiries, you may want backups more often.<\/p>\n\n\n\n Retention decides how far back you can go. A hacked site often goes unnoticed for days or weeks, so a backup that only keeps the last two days may contain the infection too. Ask for several weeks of history. Think about the opposite problem as well. Backups copy personal data, so keeping them forever creates its own risk, and the firm’s retention policy should cover them.<\/p>\n\n\n\n A backup stored on the same server dies with the server. Ask for a copy in a separate location, ideally a different data center or provider. Then ask who controls that storage and who else can reach it.<\/p>\n\n\n\n Keep your own copy as well. A firm or agency can pull a monthly backup of the site to its own storage, which protects against a problem with the provider itself, such as a billing dispute or a terminated account. Keep it somewhere access controlled, since it holds the whole site.<\/p>\n\n\n\n Set a reminder to check that the copy still downloads and opens, because a silent failure here removes your safety net.<\/p>\n\n\n\n A backup is a full copy of the site, including the database and any stored enquiries. If someone steals it, they have everything. Ask whether backups are encrypted while stored and while moving, and who inside the provider can read them. Practices vary by provider, so ask and keep the answer on file.<\/p>\n\n\n\n Control your own copies too. Do not email backup files or leave them in a shared folder. Use encrypted storage, limit who can download them and delete old ones on a schedule.<\/p>\n\n\n\n A short written rule about who may download backups, and where they go afterward, settles most arguments before they start.<\/p>\n\n\n\n Test a restore at least once or twice a year. Pick a restore point, restore to a staging copy and check that pages load, forms work, the database is intact and the media library is complete. Time the exercise.<\/p>\n\n\n\n Testing also reveals gaps in the procedure: unclear contacts, missing credentials, a restore tool that fails on large sites. Better to find those on a calm Tuesday than during an outage. Record the result with the date, because a firm may need to show diligence later.<\/p>\n\n\n\n Share a short summary with the firm each time. Seeing that the process works is reassuring for clients and for their insurers.<\/p>\n\n\n\n Two terms help. Recovery point objective, or RPO, is how much recent data you can afford to lose, measured in time. Recovery time objective, or RTO, is how long you can afford to be down.<\/p>\n\n\n\n For a law firm site, the numbers can be modest: perhaps a day of lost changes and a few hours of downtime. Write them down, then ask the provider whether its backup schedule and restore process can meet them. If they cannot, you have found a gap while it is cheap to fix. Higher targets cost more, so choose them by need, not by fear.<\/p>\n\n\n\n Disaster recovery covers serious events: a failed server, a lost data center, a ransomware attack or an account takeover. Decide who does what. The provider restores infrastructure, the firm or agency restores the site and someone talks to clients.<\/p>\n\n\n\n Write a one page plan with contacts, credentials stored safely, backup locations, restore steps and a note on how to tell clients and staff what is happening. Business continuity is broader than hosting, and email, the website and any case systems should each have a plan. Hosting is one part of it.<\/p>\n\n\n\n Agree on who has authority to make decisions during an incident, because delays over who may approve a restore cost more than the restore itself.<\/p>\n\n\n\n Tell them plainly that shared hosting suits public websites and not confidential files, that accounts share a server, that security is split between the host and the site owner, and that more sensitive needs call for different infrastructure. Honest limits win more trust with legal clients than big promises, and they protect you.<\/p>\n\n\n\n Draw the line clearly in your proposal. A website serves public pages. An application, such as a client portal or case management system, handles confidential data and needs its own security design. Document hosting stores privileged files, and needs access control, encryption and audit trails.<\/p>\n\n\n\n Shared hosting such as our cPanel web hosting<\/a> is built for websites. If a firm asks you to host a portal on a shared plan, treat that as a flag, not a sale. Say so, and suggest suitable alternatives.<\/p>\n\n\n\n A portal needs login security, audit trails and a written agreement about the data it holds, and a plain shared plan offers none of those by design. Declining that work protects the client and keeps your reputation intact.<\/p>\n\n\n\n On shared hosting, many accounts live on one server. Good platforms separate accounts so one cannot read another’s files, and set limits so one busy site cannot starve the rest. Isolation quality varies, and no isolation is perfect.<\/p>\n\n\n\n Explain that to a legal client in plain words. Shared means shared. The risk from neighbors is reduced by isolation and monitoring, but it is not zero. A firm that wants no neighbors at all is describing a VPS or dedicated server, not a shared plan.<\/p>\n\n\n\n Put a sentence in your proposal that says exactly what isolation you provide, so nobody reads more into the word than you meant.<\/p>\n\n\n\n The biggest risk is rarely the server. It is the content. A staff member uploads a client’s document to the media library, a draft page with case details gets indexed by search engines, or a form stores sensitive enquiries where every plugin can read them.<\/p>\n\n\n\n Help firms set rules: nothing confidential goes into the website, drafts stay private, forms ask for contact details and a short description only, and the site tells visitors not to send sensitive details through it. A short line on the form asking visitors not to include confidential facts in a first message is cheap protection for both sides.<\/p>\n\n\n\n Move up when the firm needs isolation, custom security settings or controls that shared hosting cannot offer. A VPS<\/a> gives a private slice with root level control, and a dedicated server<\/a> gives a whole machine to one customer.<\/p>\n\n\n\n Say honestly that more infrastructure is not more compliance. A dedicated server badly managed is worse than a well run shared account. Someone must patch it, monitor it and back it up. That duty is the price of control. If the firm lacks a technical team, price managed support into the offer.<\/p>\n\n\n\n The extra monthly cost often surprises firms, so raise it early, before they have fallen in love with the idea of a private server.<\/p>\n\n\n\n Put expectations in writing. State what you host, what you back up and how often, who has access, how quickly you respond and what you do not promise. Include a sentence that hosting does not by itself make the firm compliant with any law or professional rule.<\/p>\n\n\n\n That sentence protects you and educates them. We have seen hosts lose sleep over a client who assumed the word secure meant legally covered. A clear proposal turns an unspoken assumption into a discussed one.<\/p>\n\n\n\n Ask the firm to confirm in writing that they have read it. A signed line takes seconds and settles most later arguments.<\/p>\n\n\n\n Document what you do, set service expectations in writing, build clear support and escalation paths, keep backup and recovery records, review the providers in your chain and avoid every claim you cannot prove. Reliability for legal clients is mostly about being specific, consistent and honest.<\/p>\n\n\n\n Write a plain document describing your hosting: where servers sit, how accounts are separated, how backups work, how SSL is handled, how access is controlled and how incidents are handled. One or two pages is enough.<\/p>\n\n\n\n Base it on facts you can verify. Ask your upstream provider for the details you cannot see yourself, and compare them with our reseller features<\/a> page to see what a plan includes. Update the document when anything changes. Law firms often ask for something like this during vendor review, and having it ready speeds a sale and prevents improvised answers.<\/p>\n\n\n\n Decide what you will promise and promise only that. State support hours, target response times for different problem types, planned maintenance notice and what counts as an outage. Mirror the limits of your own provider’s SLA, because you cannot promise more than your upstream gives you.<\/p>\n\n\n\n Avoid uptime percentages you cannot back. If your upstream offers a figure, you can refer to it carefully. If you add your own, make sure your monitoring can prove it. A billing system such as the free WHMCS license<\/a> we include with reseller plans also includes a support ticket system, which gives you an organized record of plans, renewals and requests.<\/p>\n\n\n\n Define who the client contacts, how, and what happens next. A simple ladder works: client to you, you to the upstream provider, with response targets at each step. Tell clients which problems you handle and which you escalate.<\/p>\n\n\n\n We run 24\/7 support for resellers, so an infrastructure problem at midnight has somewhere to go. Make sure your own side is just as clear. If you are the only person, say when you are available and what happens outside those hours. A law firm will forgive limits that are stated. It will not forgive silence during an outage.<\/p>\n\n\n\n Keep a record for each client: what is backed up, how often, where it is stored, how long it is kept and how to restore it. Add the date and result of your last test restore. This is the file you open on a bad day.<\/p>\n\n\n\n Store credentials in a password manager, not in the document. Keep a second copy of the document outside the hosting account, since a document stored only on the failed server helps nobody. Review it twice a year with the client, which also reminds them that you take their site seriously.<\/p>\n\n\n\n Your service depends on others: the hosting provider, the data center, the domain registrar, DNS, email delivery, a CDN and any plugins that send data elsewhere. List them, and know what each can see.<\/p>\n\n\n\n Review them at least yearly. Look at their terms, their incident history and any changes to ownership or location. For email delivery, we offer MailChannels spam free email<\/a>, which is one provider to list and review like any other. When a client asks who handles their data, you want the list ready.<\/p>\n\n\n\n Keep the list in the same file as your backup and recovery notes, so both are found together when an incident hits.<\/p>\n\n\n\n Do not write compliant hosting, secure hosting for lawyers or guaranteed safe on your site or in proposals unless you can name the standard, the scope and the evidence. Vague claims create liability. They also mislead clients who may rely on them.<\/p>\n\n\n\n Say what you actually do: encrypted connections, regular backups, monitored servers and controlled access. Say what you do not do, and point firms to their own advisers for legal questions. Honest wording will lose you the occasional client who wanted a magic word, and win you the careful ones, who are the clients worth having.<\/p>\n\n\n\nBackup connectivity and recovery procedures<\/h3>\n\n\n\n
What Security Questions Should Law Firms Ask a Hosting Provider?<\/h2>\n\n\n\n
Server and network security controls<\/h3>\n\n\n\n
SSL and encrypted website connections<\/h3>\n\n\n\n
Account access and multi-factor authentication<\/h3>\n\n\n\n
Malware detection and vulnerability management<\/h3>\n\n\n\n
Security patching and incident response<\/h3>\n\n\n\n
Access logs and administrative controls<\/h3>\n\n\n\n
Can Reseller Hosting Meet a Law Firm’s Compliance Requirements?<\/h2>\n\n\n\n
Website hosting versus confidential legal systems<\/h3>\n\n\n\n
Identifying which data the hosting environment actually stores<\/h3>\n\n\n\n
Privacy and data protection obligations<\/h3>\n\n\n\n
Data location and residency considerations<\/h3>\n\n\n\n
Contracts, processors, and third-party providers<\/h3>\n\n\n\n
Compliance responsibility between the law firm and hosting provider<\/h3>\n\n\n\n
How Should Law Firms Evaluate Backups and Disaster Recovery?<\/h2>\n\n\n\n
Backup frequency and retention periods<\/h3>\n\n\n\n
Off-server backup storage<\/h3>\n\n\n\n
Backup encryption and access controls<\/h3>\n\n\n\n
Recovery testing<\/h3>\n\n\n\n
Recovery time and recovery point objectives<\/h3>\n\n\n\n
Disaster recovery responsibilities<\/h3>\n\n\n\n
What Should a Reseller Tell a Law Firm About Shared Hosting?<\/h2>\n\n\n\n
Website hosting versus application and document hosting<\/h3>\n\n\n\n
Resource isolation and account separation<\/h3>\n\n\n\n
Risks of placing sensitive information on a public website<\/h3>\n\n\n\n
When VPS or dedicated infrastructure may be more appropriate<\/h3>\n\n\n\n
Setting realistic security and compliance expectations<\/h3>\n\n\n\n
How Can Resellers Build a Reliable Hosting Service for Law Firm Clients?<\/h2>\n\n\n\n
Documenting hosting security controls<\/h3>\n\n\n\n
Creating clear service-level expectations<\/h3>\n\n\n\n
Establishing support and escalation procedures<\/h3>\n\n\n\n
Maintaining backups and recovery documentation<\/h3>\n\n\n\n
Reviewing third-party providers and infrastructure<\/h3>\n\n\n\n
Avoiding unsupported compliance claims<\/h3>\n\n\n\n