{"id":4959,"date":"2026-02-11T15:20:30","date_gmt":"2026-02-11T12:20:30","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/web-hosting-security-checklist-for-small-businesses\/"},"modified":"2026-02-11T15:20:30","modified_gmt":"2026-02-11T12:20:30","slug":"web-hosting-security-checklist-for-small-businesses","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/web-hosting-security-checklist-for-small-businesses\/","title":{"rendered":"Web Hosting Security Checklist for Small Businesses"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>Most small businesses already know that website security matters, but it often stays on the \u201cwhen we have time\u201d list. Meanwhile, the same shared passwords, open FTP accounts and untested backups keep running for years without anyone looking at them. The good news: you do not need an enterprise security team to make a big difference. With a focused <a href=\"https:\/\/www.dchost.com\/web-hosting\">web hosting<\/a> security checklist, you can close the most common gaps in a few hours and then maintain them with simple routines.<\/p>\n<p>In this guide, we prepared a practical, small-business\u2011oriented checklist that covers four areas where we see incidents most often as the dchost.com team: <strong>hosting panel access<\/strong>, <strong>FTP\/SFTP and file access<\/strong>, <strong>database security<\/strong> and <strong>backups &amp; disaster recovery<\/strong>. Each section explains what to do, why it matters, and how to prioritize when you have limited time and budget. You can use it as a one\u2011time hardening guide, or as a recurring audit list every quarter. Let\u2019s walk through it step by step and make your hosting stack a lot harder to break.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#How_to_Use_This_Web_Hosting_Security_Checklist\"><span class=\"toc_number toc_depth_1\">1<\/span> How to Use This Web Hosting Security Checklist<\/a><\/li><li><a href=\"#1_Secure_Hosting_Panel_Access_cPanel_DirectAdmin_Plesk_Custom\"><span class=\"toc_number toc_depth_1\">2<\/span> 1. Secure Hosting Panel Access (cPanel, DirectAdmin, Plesk, Custom)<\/a><ul><li><a href=\"#11_Use_a_unique_strong_password_and_a_password_manager\"><span class=\"toc_number toc_depth_2\">2.1<\/span> 1.1 Use a unique, strong password and a password manager<\/a><\/li><li><a href=\"#12_Enable_twofactor_authentication_2FA\"><span class=\"toc_number toc_depth_2\">2.2<\/span> 1.2 Enable two\u2011factor authentication (2FA)<\/a><\/li><li><a href=\"#13_Restrict_where_logins_can_come_from\"><span class=\"toc_number toc_depth_2\">2.3<\/span> 1.3 Restrict where logins can come from<\/a><\/li><li><a href=\"#14_Use_separate_users_and_roles_instead_of_shared_logins\"><span class=\"toc_number toc_depth_2\">2.4<\/span> 1.4 Use separate users and roles instead of shared logins<\/a><\/li><li><a href=\"#15_Monitor_login_alerts_and_activity_logs\"><span class=\"toc_number toc_depth_2\">2.5<\/span> 1.5 Monitor login alerts and activity logs<\/a><\/li><\/ul><\/li><li><a href=\"#2_Lock_Down_File_Access_FTP_SFTP_SSH_and_File_Manager\"><span class=\"toc_number toc_depth_1\">3<\/span> 2. Lock Down File Access: FTP, SFTP, SSH and File Manager<\/a><ul><li><a href=\"#21_Stop_using_plain_FTP_move_to_SFTP_or_FTPS\"><span class=\"toc_number toc_depth_2\">3.1<\/span> 2.1 Stop using plain FTP; move to SFTP or FTPS<\/a><\/li><li><a href=\"#22_Use_persiteperpurpose_FTPSFTP_accounts\"><span class=\"toc_number toc_depth_2\">3.2<\/span> 2.2 Use per\u2011site\/per\u2011purpose FTP\/SFTP accounts<\/a><\/li><li><a href=\"#23_Prefer_SSH_keys_over_passwords_where_available\"><span class=\"toc_number toc_depth_2\">3.3<\/span> 2.3 Prefer SSH keys over passwords where available<\/a><\/li><li><a href=\"#24_Treat_the_webbased_File_Manager_like_a_control_panel\"><span class=\"toc_number toc_depth_2\">3.4<\/span> 2.4 Treat the web\u2011based File Manager like a control panel<\/a><\/li><\/ul><\/li><li><a href=\"#3_Database_Security_Essentials\"><span class=\"toc_number toc_depth_1\">4<\/span> 3. Database Security Essentials<\/a><ul><li><a href=\"#31_Use_separate_leastprivilege_database_users\"><span class=\"toc_number toc_depth_2\">4.1<\/span> 3.1 Use separate, least\u2011privilege database users<\/a><\/li><li><a href=\"#32_Restrict_where_database_logins_can_come_from\"><span class=\"toc_number toc_depth_2\">4.2<\/span> 3.2 Restrict where database logins can come from<\/a><\/li><li><a href=\"#33_Keep_database_engines_patched_and_monitored\"><span class=\"toc_number toc_depth_2\">4.3<\/span> 3.3 Keep database engines patched and monitored<\/a><\/li><li><a href=\"#34_Do_not_leave_database_management_tools_exposed\"><span class=\"toc_number toc_depth_2\">4.4<\/span> 3.4 Do not leave database management tools exposed<\/a><\/li><\/ul><\/li><li><a href=\"#4_Backup_Strategy_That_Actually_Works_When_Things_Go_Wrong\"><span class=\"toc_number toc_depth_1\">5<\/span> 4. Backup Strategy That Actually Works When Things Go Wrong<\/a><ul><li><a href=\"#41_Follow_the_321_backup_rule\"><span class=\"toc_number toc_depth_2\">5.1<\/span> 4.1 Follow the 3\u20112\u20111 backup rule<\/a><\/li><li><a href=\"#42_Decide_what_exactly_you_will_back_up\"><span class=\"toc_number toc_depth_2\">5.2<\/span> 4.2 Decide what exactly you will back up<\/a><\/li><li><a href=\"#43_Encrypt_backups_and_manage_keys_safely\"><span class=\"toc_number toc_depth_2\">5.3<\/span> 4.3 Encrypt backups and manage keys safely<\/a><\/li><li><a href=\"#44_Set_realistic_backup_frequencies_and_retention\"><span class=\"toc_number toc_depth_2\">5.4<\/span> 4.4 Set realistic backup frequencies and retention<\/a><\/li><li><a href=\"#45_Regularly_test_restore_procedures\"><span class=\"toc_number toc_depth_2\">5.5<\/span> 4.5 Regularly test restore procedures<\/a><\/li><\/ul><\/li><li><a href=\"#5_ApplicationLevel_Basics_CMS_Plugins_and_HTTP_Security\"><span class=\"toc_number toc_depth_1\">6<\/span> 5. Application\u2011Level Basics: CMS, Plugins and HTTP Security<\/a><ul><li><a href=\"#51_Keep_core_themesplugins_and_dependencies_updated\"><span class=\"toc_number toc_depth_2\">6.1<\/span> 5.1 Keep core, themes\/plugins and dependencies updated<\/a><\/li><li><a href=\"#52_Harden_admin_login_areas\"><span class=\"toc_number toc_depth_2\">6.2<\/span> 5.2 Harden admin login areas<\/a><\/li><li><a href=\"#53_Use_HTTPS_and_basic_HTTP_security_headers\"><span class=\"toc_number toc_depth_2\">6.3<\/span> 5.3 Use HTTPS and basic HTTP security headers<\/a><\/li><\/ul><\/li><li><a href=\"#6_Practical_20Point_Web_Hosting_Security_Checklist\"><span class=\"toc_number toc_depth_1\">7<\/span> 6. Practical 20\u2011Point Web Hosting Security Checklist<\/a><ul><li><a href=\"#Panel_and_account_access\"><span class=\"toc_number toc_depth_2\">7.1<\/span> Panel and account access<\/a><\/li><li><a href=\"#FTPSFTP_SSH_and_file_access\"><span class=\"toc_number toc_depth_2\">7.2<\/span> FTP\/SFTP, SSH and file access<\/a><\/li><li><a href=\"#Database_security\"><span class=\"toc_number toc_depth_2\">7.3<\/span> Database security<\/a><\/li><li><a href=\"#Backups_and_recovery\"><span class=\"toc_number toc_depth_2\">7.4<\/span> Backups and recovery<\/a><\/li><li><a href=\"#Applicationlevel_basics\"><span class=\"toc_number toc_depth_2\">7.5<\/span> Application\u2011level basics<\/a><\/li><\/ul><\/li><li><a href=\"#Putting_It_All_Together_for_Your_Business\"><span class=\"toc_number toc_depth_1\">8<\/span> Putting It All Together for Your Business<\/a><\/li><\/ul><\/div>\n<h2><span id=\"How_to_Use_This_Web_Hosting_Security_Checklist\">How to Use This Web Hosting Security Checklist<\/span><\/h2>\n<p>Before jumping into settings, it helps to frame security work in a way that is realistic for small businesses. You probably do not have a full\u2011time sysadmin, but you still hold customer data, leads and orders that you cannot afford to lose. That means you need a <strong>small number of high\u2011impact controls<\/strong> that are easy to maintain.<\/p>\n<p>We recommend using this checklist in three passes:<\/p>\n<ul>\n<li><strong>Pass 1 \u2013 Must\u2011do today:<\/strong> Items that prevent common hacks and data loss, such as strong panel access, disabling plain FTP and enabling automatic backups.<\/li>\n<li><strong>Pass 2 \u2013 Within 1\u20132 weeks:<\/strong> Improvements like IP restrictions, better database accounts and backup encryption.<\/li>\n<li><strong>Pass 3 \u2013 Quarterly routine:<\/strong> Review users, rotate passwords\/keys and run restore tests.<\/li>\n<\/ul>\n<p>Several of the practices below tie into broader security concepts like zero\u2011trust access and disaster recovery. If you want to go deeper on access design, you can read our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/zero-trust-ile-hosting-ve-sunucu-erisimini-guvenceye-almak\/\">zero\u2011trust access to hosting panels and servers<\/a>, but for now we will stay at a practical, small\u2011business level.<\/p>\n<h2><span id=\"1_Secure_Hosting_Panel_Access_cPanel_DirectAdmin_Plesk_Custom\">1. Secure Hosting Panel Access (cPanel, DirectAdmin, Plesk, Custom)<\/span><\/h2>\n<p>Your hosting control panel is the \u201cmaster key\u201d to your site: from there you can change DNS, reset email passwords, upload files, create databases and more. If someone gets in, they do not need fancy exploits. They can just log in and use the same buttons you use every day. That is why panel access deserves special attention.<\/p>\n<h3><span id=\"11_Use_a_unique_strong_password_and_a_password_manager\">1.1 Use a unique, strong password and a password manager<\/span><\/h3>\n<p>First, never reuse your panel password on other services (email, social media, accounting tools, etc.). Password leaks elsewhere are one of the easiest ways attackers get into hosting accounts.<\/p>\n<ul>\n<li>Use at least <strong>12\u201316 characters<\/strong> with a mix of letters, numbers and symbols.<\/li>\n<li>Generate it with a reputable <strong>password manager<\/strong> rather than inventing something you might reuse.<\/li>\n<li>Do not share the main panel password over email or chat; if someone else needs access, create a separate user account where possible.<\/li>\n<\/ul>\n<p>On shared hosting, your panel login often controls everything under your account. Treat it like you would treat online banking credentials.<\/p>\n<h3><span id=\"12_Enable_twofactor_authentication_2FA\">1.2 Enable two\u2011factor authentication (2FA)<\/span><\/h3>\n<p>Two\u2011factor authentication adds a one\u2011time code (via an app or SMS) on top of your password. Even if your password leaks, attackers cannot log in without that second factor.<\/p>\n<ul>\n<li>Enable 2FA in the \u201cSecurity\u201d or \u201cLogin\u201d section of your panel (cPanel\/DirectAdmin\/Plesk all support this in modern versions).<\/li>\n<li>Prefer an <strong>authenticator app<\/strong> (TOTP) over SMS where possible, as it is more resistant to SIM\u2011swap attacks.<\/li>\n<li>Store backup codes in a secure place (encrypted notes in your password manager, for example).<\/li>\n<\/ul>\n<p>For small businesses, 2FA is one of the highest\u2011value, lowest\u2011effort security upgrades you can make.<\/p>\n<h3><span id=\"13_Restrict_where_logins_can_come_from\">1.3 Restrict where logins can come from<\/span><\/h3>\n<p>Once 2FA is in place, the next step is limiting where logins can originate. This dramatically shrinks the attack surface.<\/p>\n<ul>\n<li>If your panel supports it, <strong>restrict logins by IP<\/strong> to your office IP and the IPs of trusted remote workers.<\/li>\n<li>Consider using a VPN or zero\u2011trust access layer so that the panel is only reachable through a protected tunnel (we discuss design options in more depth in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/zero-trust-ile-hosting-ve-sunucu-erisimini-guvenceye-almak\/\">zero\u2011trust access to hosting and servers<\/a>).<\/li>\n<li>Avoid accessing the panel from public Wi\u2011Fi unless you are on a VPN.<\/li>\n<\/ul>\n<p>If your team is small and locations are predictable, IP\u2011based restrictions alone already make brute\u2011force attacks much less realistic.<\/p>\n<h3><span id=\"14_Use_separate_users_and_roles_instead_of_shared_logins\">1.4 Use separate users and roles instead of shared logins<\/span><\/h3>\n<p>Many incidents we investigate at dchost.com start the same way: a single shared control panel password has been given to multiple people over the years, and nobody remembers who still has it. The fix is simple:<\/p>\n<ul>\n<li>Where your panel allows it, create <strong>individual user accounts<\/strong> for staff, the web agency and freelancers.<\/li>\n<li>Grant only the <strong>minimum permissions<\/strong> needed (for example, allow database access but not billing, or email management but not DNS).<\/li>\n<li>Remove accounts immediately when someone leaves your company or project.<\/li>\n<\/ul>\n<p>This is basic \u201cleast privilege\u201d in action. It also makes auditing easier because you can see which user did what.<\/p>\n<h3><span id=\"15_Monitor_login_alerts_and_activity_logs\">1.5 Monitor login alerts and activity logs<\/span><\/h3>\n<p>Most modern hosting panels can send you an email when there is a login from a new IP or when multiple failed logins occur. Turn these alerts on and make sure they go to a monitored mailbox.<\/p>\n<ul>\n<li>Review panel logs occasionally for strange activity: unexpected IPs, logins at odd hours, or configuration changes you do not recognize.<\/li>\n<li>If you see anything suspicious, <strong>immediately change the password, revoke 2FA tokens and review sub\u2011users<\/strong>.<\/li>\n<\/ul>\n<p>Simple visibility like this often catches problems early, before a full compromise or data loss.<\/p>\n<h2><span id=\"2_Lock_Down_File_Access_FTP_SFTP_SSH_and_File_Manager\">2. Lock Down File Access: FTP, SFTP, SSH and File Manager<\/span><\/h2>\n<p>File access is the second big pillar of hosting security. Historically, many sites have been managed with plain FTP, often left open forever in desktop clients. From an attacker\u2019s perspective, an old FTP account with a weak password is a golden ticket.<\/p>\n<h3><span id=\"21_Stop_using_plain_FTP_move_to_SFTP_or_FTPS\">2.1 Stop using plain FTP; move to SFTP or FTPS<\/span><\/h3>\n<p>Plain FTP sends your username, password and file contents <strong>in clear text<\/strong>. Anyone on the same network path can intercept them. You should use an encrypted protocol instead:<\/p>\n<ul>\n<li><strong>SFTP<\/strong> (SSH File Transfer Protocol) runs over SSH; it is widely supported and our preferred choice.<\/li>\n<li><strong>FTPS<\/strong> is FTP over TLS; better than plain FTP but usually more complex to configure correctly.<\/li>\n<\/ul>\n<p>We highly recommend reading our dedicated guide <a href=\"https:\/\/www.dchost.com\/blog\/en\/ftp-yerine-sftp-kullanmanin-zamani-geldi\/\">\u201cFrom FTP to SFTP: Secure File Transfer on Shared Hosting and VPS\u201d<\/a> if you are still on legacy FTP. It walks through client configuration, port choices and common migration pitfalls.<\/p>\n<p>On your hosting account, disable plain FTP access altogether if your panel allows it. Many modern setups either force SFTP\/FTPS or offer a toggle to turn off unencrypted FTP.<\/p>\n<h3><span id=\"22_Use_persiteperpurpose_FTPSFTP_accounts\">2.2 Use per\u2011site\/per\u2011purpose FTP\/SFTP accounts<\/span><\/h3>\n<p>Instead of one all\u2011powerful FTP account used for everything:<\/p>\n<ul>\n<li>Create a <strong>separate account for each website<\/strong> or project, restricted to that site\u2019s directory.<\/li>\n<li>If an agency or freelancer needs access, give them a <strong>dedicated user limited to the relevant folder<\/strong>.<\/li>\n<li>Remove accounts as soon as they are no longer needed, and review all FTP\/SFTP users at least quarterly.<\/li>\n<\/ul>\n<p>This way, even if one set of credentials leaks, the blast radius is limited.<\/p>\n<h3><span id=\"23_Prefer_SSH_keys_over_passwords_where_available\">2.3 Prefer SSH keys over passwords where available<\/span><\/h3>\n<p>On VPS or <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>s with SSH access, use <strong>SSH keys<\/strong> for SFTP and SSH rather than passwords:<\/p>\n<ul>\n<li>Generate a key pair on your workstation and upload the public key to the server.<\/li>\n<li>Disable password authentication over SSH where feasible.<\/li>\n<li>Protect your private key with a passphrase and store it only on your devices.<\/li>\n<\/ul>\n<p>Key\u2011based authentication virtually eliminates brute\u2011force password attacks against SSH. Combined with IP restrictions and a firewall, it is a very strong baseline. For deeper hardening tips (no\u2011root login, Fail2ban, auto updates, etc.), our <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-guvenlik-sertlestirme-kontrol-listesi-sshd_config-fail2ban-ve-root-erisimini-kapatmak\/\">VPS security hardening checklist<\/a> is a useful companion.<\/p>\n<h3><span id=\"24_Treat_the_webbased_File_Manager_like_a_control_panel\">2.4 Treat the web\u2011based File Manager like a control panel<\/span><\/h3>\n<p>Most hosting panels include a File Manager tool. It is convenient, but also powerful:<\/p>\n<ul>\n<li>Always <strong>log out<\/strong> when you are finished, especially on shared or public computers.<\/li>\n<li>Avoid editing critical config files (like <code>wp-config.php<\/code> or <code>.env<\/code>) from untrusted machines.<\/li>\n<li>Be careful when using \u201cextract\u201d or \u201cupload archive\u201d features \u2013 make sure you know exactly which directory you are working in.<\/li>\n<\/ul>\n<p>Think of File Manager as equivalent to full SFTP access. It deserves the same strong password, 2FA and login protection as your main panel.<\/p>\n<h2><span id=\"3_Database_Security_Essentials\">3. Database Security Essentials<\/span><\/h2>\n<p>Databases hold the most sensitive part of your website: customer information, orders, login hashes, content, everything. Yet many compromises we see come down to one small thing: a database user with far too many permissions, or a database port exposed directly to the internet.<\/p>\n<h3><span id=\"31_Use_separate_leastprivilege_database_users\">3.1 Use separate, least\u2011privilege database users<\/span><\/h3>\n<p>Instead of connecting your application with a powerful \u201croot\u2011like\u201d user, create a dedicated user with only the permissions it needs:<\/p>\n<ul>\n<li>For a typical CMS (WordPress, Joomla, etc.) a user usually needs <strong>SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER and INDEX<\/strong> on its own database \u2013 not global privileges.<\/li>\n<li>Do not reuse the same database user across multiple websites; compromise of one site should not grant access to others.<\/li>\n<li>Use <strong>strong, random passwords<\/strong> for database users; store them in your configuration files but nowhere else.<\/li>\n<\/ul>\n<p>This is a simple change that limits how much damage can be done if an application vulnerability is exploited.<\/p>\n<h3><span id=\"32_Restrict_where_database_logins_can_come_from\">3.2 Restrict where database logins can come from<\/span><\/h3>\n<p>On shared hosting, your database server is often reachable only from the web server itself (localhost). On VPS and dedicated servers, you may have more freedom \u2013 but that flexibility can be dangerous.<\/p>\n<ul>\n<li>Only listen on <strong>localhost<\/strong> unless you have a clear reason to allow remote database connections.<\/li>\n<li>If you must allow remote access (for a reporting tool, for example), restrict it by <strong>specific IP address<\/strong>, not <code>%<\/code> (any host).<\/li>\n<li>Use a VPN or SSH tunnel for remote database administration rather than opening the port to the public internet.<\/li>\n<\/ul>\n<p>Blocking the database port at the firewall level is one of the most effective protections you can put in place.<\/p>\n<h3><span id=\"33_Keep_database_engines_patched_and_monitored\">3.3 Keep database engines patched and monitored<\/span><\/h3>\n<p>MySQL, MariaDB and PostgreSQL all release regular security and bug\u2011fix updates. On managed hosting, these are usually applied for you; on VPS and dedicated servers, you (or your admin) are responsible.<\/p>\n<ul>\n<li>Apply security updates on a regular schedule and avoid running very old major versions.<\/li>\n<li>Monitor <strong>slow query logs and error logs<\/strong> for unusual patterns that might indicate abuse or brute\u2011force attempts.<\/li>\n<li>Use strong, unique passwords for database root\/admin accounts and restrict access to them even from within your own team.<\/li>\n<\/ul>\n<p>Patch management is a broader topic on its own; we cover trade\u2011offs between automatic and manual updates in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/linux-sunucularda-ve-web-uygulamalarinda-yama-yonetimi-otomatik-guncelleme-mi-manuel-mi\/\">patch management for Linux servers and web apps<\/a>, which is worth reviewing if you manage your own VPS.<\/p>\n<h3><span id=\"34_Do_not_leave_database_management_tools_exposed\">3.4 Do not leave database management tools exposed<\/span><\/h3>\n<p>Tools like phpMyAdmin are convenient, but they are also frequent targets:<\/p>\n<ul>\n<li>Protect phpMyAdmin with <strong>panel authentication, additional HTTP auth or IP restrictions<\/strong>.<\/li>\n<li>Avoid generic URLs like <code>\/phpmyadmin<\/code>; use panel\u2011integrated access where possible.<\/li>\n<li>Do not install multiple admin tools \u201cjust in case\u201d; keep the attack surface small.<\/li>\n<\/ul>\n<p>Combined with least\u2011privilege users and network restrictions, this significantly reduces the chance of a direct database breach.<\/p>\n<h2><span id=\"4_Backup_Strategy_That_Actually_Works_When_Things_Go_Wrong\">4. Backup Strategy That Actually Works When Things Go Wrong<\/span><\/h2>\n<p>Backups are often treated as a checkbox: \u201cour hosting provider says they have backups, so we are fine.\u201d Unfortunately, that is not enough. As a hosting provider, we have seen two patterns repeat: people either had no usable backups at all, or they had backups but had never tested restoring them \u2013 and discovered gaps during a crisis.<\/p>\n<p>A reliable backup strategy starts with two concepts: <strong>RPO<\/strong> (Recovery Point Objective \u2013 how much data you can afford to lose) and <strong>RTO<\/strong> (Recovery Time Objective \u2013 how fast you need to be back online). For a detailed discussion with small\u2011business examples, see our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/kobiler-icin-rpo-rto-ve-felaket-kurtarma-plani-hosting-tarafinda-gercekci-hedefler\/\">RPO, RTO and disaster recovery planning for small businesses<\/a>. Here we will focus on the practical checklist.<\/p>\n<h3><span id=\"41_Follow_the_321_backup_rule\">4.1 Follow the 3\u20112\u20111 backup rule<\/span><\/h3>\n<p>The classic but still very relevant rule is:<\/p>\n<ul>\n<li><strong>3 copies<\/strong> of your data (1 primary + 2 backups)<\/li>\n<li>stored on <strong>2 different types of media<\/strong> (for example, NVMe disk + object storage)<\/li>\n<li>with at least <strong>1 copy off\u2011site<\/strong> (different data center or provider)<\/li>\n<\/ul>\n<p>In practice, for a small business website hosted at dchost.com, that might look like:<\/p>\n<ul>\n<li>Automatic daily backups <strong>on the hosting server<\/strong> for quick restores.<\/li>\n<li>Automatic off\u2011server backups to <strong>separate storage in another data center<\/strong>.<\/li>\n<li>Optional periodic exports (database dumps, critical files) downloaded and archived by you for an extra safety layer.<\/li>\n<\/ul>\n<p>If you want a step\u2011by\u2011step overview of implementing this on typical panels and VPS, our article on the <a href=\"https:\/\/www.dchost.com\/blog\/en\/3-2-1-yedekleme-stratejisi-neden-ise-yariyor-cpanel-plesk-ve-vpste-otomatik-yedekleri-nasil-kurarsin\/\">3\u20112\u20111 backup strategy and automating backups on cPanel, Plesk and VPS<\/a> is a solid companion to this checklist.<\/p>\n<h3><span id=\"42_Decide_what_exactly_you_will_back_up\">4.2 Decide what exactly you will back up<\/span><\/h3>\n<p>A common misconception is that \u201cbacking up the website\u201d magically covers everything. In reality, you should be explicit:<\/p>\n<ul>\n<li><strong>Web files:<\/strong> application code, uploads, media, configuration files.<\/li>\n<li><strong>Databases:<\/strong> all databases used by your site or apps (e\u2011commerce, CRM, blog, etc.).<\/li>\n<li><strong>Email data:<\/strong> if you are using hosting\u2011side email, mailbox contents and settings.<\/li>\n<li><strong>DNS and configuration:<\/strong> zone files, custom records, <a href=\"https:\/\/www.dchost.com\/ssl\">SSL certificate<\/a>s and panel configuration where possible.<\/li>\n<\/ul>\n<p>Make sure your backup plan and tools actually cover all of these. For example, automated cPanel backups can usually include home directory, databases and email, while separate VPS backup tools may require explicit database dumps.<\/p>\n<h3><span id=\"43_Encrypt_backups_and_manage_keys_safely\">4.3 Encrypt backups and manage keys safely<\/span><\/h3>\n<p>Backups often contain the most complete copy of your sensitive data. If those backups are stolen or misused, the impact can be severe. That is why <strong>encryption and key management<\/strong> are crucial, especially when you store copies off\u2011site or in object storage.<\/p>\n<ul>\n<li>Encrypt backups at rest, either through the backup software or storage layer.<\/li>\n<li>Store encryption keys <strong>separately<\/strong> from the backup location.<\/li>\n<li>Document who has access to keys and how they can be rotated if compromised.<\/li>\n<\/ul>\n<p>We dive deeper into encryption options and real\u2011world key management patterns in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/yedek-sifreleme-ve-anahtar-yonetimi-rehberi\/\">backup encryption and key management for GDPR\u2011safe hosting and object storage<\/a>. If you handle any personal data, this is particularly important for regulatory compliance as well as security.<\/p>\n<h3><span id=\"44_Set_realistic_backup_frequencies_and_retention\">4.4 Set realistic backup frequencies and retention<\/span><\/h3>\n<p>Your RPO\/RTO targets should drive how often you back up and how long you keep copies:<\/p>\n<ul>\n<li>For active e\u2011commerce or booking sites, daily database backups are usually the bare minimum; many businesses opt for <strong>every 4\u20136 hours<\/strong> plus daily full backups.<\/li>\n<li>For low\u2011change corporate sites, daily or even every\u2011other\u2011day backups might be enough.<\/li>\n<li>Keep at least <strong>7\u201314 days<\/strong> of rolling backups, plus monthly snapshots if storage allows, so you can recover from infections that went unnoticed for a while.<\/li>\n<\/ul>\n<p>Do not forget retention on off\u2011site backups. Very short retention (1\u20132 days) may save disk space but leaves you with few options if a problem is discovered late.<\/p>\n<h3><span id=\"45_Regularly_test_restore_procedures\">4.5 Regularly test restore procedures<\/span><\/h3>\n<p>A backup you have never tried to restore is only a theory. The first time you perform a full restore should not be during an incident. Instead:<\/p>\n<ul>\n<li>Schedule <strong>regular test restores<\/strong> (for example, every 3\u20136 months).<\/li>\n<li>Restore to a <strong>staging or test environment<\/strong>, not over your live site.<\/li>\n<li>Verify that the restored site loads, logins work, and critical workflows (checkout, forms, dashboards) behave normally.<\/li>\n<\/ul>\n<p>We strongly recommend following the approach in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/hosting-tarafinda-felaket-kurtarma-provasi-cpanel-ve-vps-yedeklerini-test-etme-rehberi\/\">disaster recovery drills for hosting: safely testing cPanel and VPS restores<\/a>. Having a simple, documented runbook dramatically reduces stress when something does go wrong.<\/p>\n<h2><span id=\"5_ApplicationLevel_Basics_CMS_Plugins_and_HTTP_Security\">5. Application\u2011Level Basics: CMS, Plugins and HTTP Security<\/span><\/h2>\n<p>Even if your panel, file access, database and backups are well secured, application\u2011level vulnerabilities can still compromise your site. Most small businesses run a CMS such as WordPress, Joomla, Drupal or a custom PHP\/Laravel application. The good news is that a few disciplined habits close most of the common holes.<\/p>\n<h3><span id=\"51_Keep_core_themesplugins_and_dependencies_updated\">5.1 Keep core, themes\/plugins and dependencies updated<\/span><\/h3>\n<p>Outdated CMS versions and plugins are one of the most common infection vectors we see in support tickets.<\/p>\n<ul>\n<li>Enable automatic minor security updates where available.<\/li>\n<li>Schedule a monthly or bi\u2011weekly window to apply larger updates after taking a fresh backup.<\/li>\n<li>Remove unused plugins, themes and modules instead of leaving them dormant but vulnerable.<\/li>\n<\/ul>\n<p>On custom applications, make sure your framework and key libraries (Laravel, Symfony, Node.js packages, etc.) are updated regularly and that known security advisories are addressed promptly.<\/p>\n<h3><span id=\"52_Harden_admin_login_areas\">5.2 Harden admin login areas<\/span><\/h3>\n<p>For any application with an admin panel:<\/p>\n<ul>\n<li>Use strong, unique passwords and enable 2FA where possible.<\/li>\n<li>Restrict access to the admin URL by IP (via .htaccess, Nginx rules or a WAF) if your team has static IPs.<\/li>\n<li>Rename or protect default admin URLs where the platform allows (for example, moving WordPress <code>wp-login.php<\/code> behind an additional protection layer).<\/li>\n<\/ul>\n<p>These measures complement your hosting panel security, creating multiple layers an attacker has to pass through.<\/p>\n<h3><span id=\"53_Use_HTTPS_and_basic_HTTP_security_headers\">5.3 Use HTTPS and basic HTTP security headers<\/span><\/h3>\n<p>All admin access and user logins should be done over HTTPS, with a valid SSL\/TLS certificate. Modern hosting like ours at dchost.com typically provides free certificates and automatic renewals.<\/p>\n<p>Beyond HTTPS, setting basic <strong>HTTP security headers<\/strong> such as HSTS, X\u2011Frame\u2011Options and Content\u2011Type options further reduces attack surface (for example, mitigating clickjacking or MIME\u2011type confusion). If you want a deeper dive, our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/http-guvenlik-basliklari-rehberi-shared-hosting-ve-vpste-csp-hsts-x-frame-options-ve-digerleri-nasil-ayarlanir\/\">HTTP security headers on shared hosting and VPS<\/a> shows concrete examples for Apache, Nginx and hosting panels.<\/p>\n<h2><span id=\"6_Practical_20Point_Web_Hosting_Security_Checklist\">6. Practical 20\u2011Point Web Hosting Security Checklist<\/span><\/h2>\n<p>To make this easy to apply, here is a condensed checklist you can work through and revisit regularly:<\/p>\n<h3><span id=\"Panel_and_account_access\">Panel and account access<\/span><\/h3>\n<ol>\n<li>Use a <strong>unique, strong password<\/strong> for your hosting panel (stored in a password manager).<\/li>\n<li>Enable <strong>two\u2011factor authentication (2FA)<\/strong> on the panel for all admin users.<\/li>\n<li>Restrict panel access by <strong>IP, VPN or zero\u2011trust access<\/strong> where supported.<\/li>\n<li>Create <strong>separate panel sub\u2011users<\/strong> for staff\/agency with least\u2011privilege roles.<\/li>\n<li>Turn on <strong>login alerts<\/strong> and review panel logs for unusual activity.<\/li>\n<\/ol>\n<h3><span id=\"FTPSFTP_SSH_and_file_access\">FTP\/SFTP, SSH and file access<\/span><\/h3>\n<ol start=\"6\">\n<li>Disable plain FTP and use <strong>SFTP or FTPS<\/strong> for all file transfers.<\/li>\n<li>Use <strong>per\u2011site SFTP accounts<\/strong> restricted to specific directories.<\/li>\n<li>On VPS\/dedicated, use <strong>SSH keys instead of passwords<\/strong> and disable root SSH login.<\/li>\n<li>Review and remove <strong>old or unused FTP\/SFTP users<\/strong> at least quarterly.<\/li>\n<li>Treat the panel File Manager as sensitive: always log out and avoid using it from untrusted devices.<\/li>\n<\/ol>\n<h3><span id=\"Database_security\">Database security<\/span><\/h3>\n<ol start=\"11\">\n<li>Create <strong>separate, least\u2011privilege database users<\/strong> per application.<\/li>\n<li>Restrict database access to <strong>localhost or specific IPs<\/strong>; block the port at the firewall.<\/li>\n<li>Protect phpMyAdmin and similar tools with <strong>extra auth and\/or IP restrictions<\/strong>.<\/li>\n<li>Keep database engines <strong>patched<\/strong> and monitor error\/slow query logs.<\/li>\n<li>Use strong, unique passwords for database admin\/root accounts.<\/li>\n<\/ol>\n<h3><span id=\"Backups_and_recovery\">Backups and recovery<\/span><\/h3>\n<ol start=\"16\">\n<li>Implement the <strong>3\u20112\u20111 backup rule<\/strong> with on\u2011server and off\u2011site copies.<\/li>\n<li>Ensure your backups include <strong>files, databases, email and DNS\/config<\/strong> where relevant.<\/li>\n<li><strong>Encrypt backups<\/strong>, especially when stored off\u2011site; manage keys securely.<\/li>\n<li>Set backup <strong>frequency and retention<\/strong> to match your RPO\/RTO needs.<\/li>\n<li>Test <strong>full restores<\/strong> to a staging environment at least every 3\u20136 months.<\/li>\n<\/ol>\n<h3><span id=\"Applicationlevel_basics\">Application\u2011level basics<\/span><\/h3>\n<ol start=\"21\">\n<li>Keep your CMS, plugins, themes and libraries <strong>regularly updated<\/strong>.<\/li>\n<li>Harden admin logins with strong passwords, 2FA and IP restrictions where possible.<\/li>\n<li>Serve your site over <strong>HTTPS<\/strong> and configure basic <strong>HTTP security headers<\/strong>.<\/li>\n<\/ol>\n<p>You do not need to complete every item in one day. Start with the highest\u2011impact ones \u2013 panel 2FA, disabling plain FTP, setting up reliable automated backups \u2013 then work down the list over the following weeks.<\/p>\n<h2><span id=\"Putting_It_All_Together_for_Your_Business\">Putting It All Together for Your Business<\/span><\/h2>\n<p>Hosting security for small businesses does not have to be complicated or expensive. What matters is being deliberate: knowing where your real risks are and putting a handful of strong, repeatable controls in place. By securing your hosting panel, moving from FTP to SFTP, tightening database access and building a backup strategy that you have actually tested, you remove the most common failure points we see in real incidents.<\/p>\n<p>As the dchost.com team, we design our shared hosting, VPS, dedicated server and colocation services to make these best practices easier, not harder: from free SSL and panel\u2011level 2FA to automated backups and off\u2011site storage options. If you are not sure where to start, you can use this checklist as a conversation map with your developer or with our support team. We are happy to review your current setup, suggest concrete changes on your existing plan or help you migrate to a more secure architecture. A few focused hours now can save days of downtime and reputation damage later.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Most small businesses already know that website security matters, but it often stays on the \u201cwhen we have time\u201d list. Meanwhile, the same shared passwords, open FTP accounts and untested backups keep running for years without anyone looking at them. The good news: you do not need an enterprise security team to make a big [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4960,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-4959","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4959","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=4959"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4959\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/4960"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=4959"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=4959"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=4959"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}