網站資安責任怎麼分？主機商合約、個資法通報與接案代管的分界

「網站被駭，這不是主機商要負責嗎？我每年都付他錢。」清理完惡意碼之後，這大概是最常被提出、也最少被認真回答的一個問題。它聽起來像在抱怨，其實是一個很硬的法律與契約問題，而答案不在任何一份技術文件裡。

答案在那份簽下去之後就再也沒打開過的主機租用合約裡。我把台灣幾家把條款完整公開的主機商合約從頭讀到尾之後才發現，它早就白紙黑字寫在上面——而且寫得比我原本以為的更絕。談網站資安的時候，大部分文章都在講「你該裝什麼、該設定什麼」，卻幾乎沒有人講「出事的那一刻，法律上和合約上，這件事到底算誰的」。

這篇文章要處理的就是後面那個問題。技術面的加固設定，站上已經有一篇寫得比我這裡更完整的WordPress 網站安全基本功：登入防護、更新策略與被入侵後的處理順序，我不重複；這裡專門處理責任、成本與法遵這三塊——主機商合約真正承諾了什麼、Cloudflare 免費方案的邊界在哪、個人資料保護法現行有效的版本要你做什麼、還沒施行的新版又會多要求什麼，以及接案代管別人的網站時，這條責任線該畫在哪裡。

所有法條我都比對過現行有效版本，所有數字都標了統計期間與查核日 2026 年 8 月 6 日。有一項特別重要：個資法的事故通報義務在 2025 年 11 月已經修正公布，但截至查核日仍未施行，網路上已經有不少文章把新舊版本混著寫，這篇會把兩者分開講清楚。

先講結論：責任分界線長什麼樣子

把整件事拆開來看，一個自架 WordPress 網站的資安責任大致落在四方身上：主機商、CDN／WAF 服務商、你自己（站台管理者），以及在接案情境下的委託客戶。絕大多數人以為的分界線，比合約上真正的分界線往你這邊偏很多。

WordPress 官方的加固文件其實把這件事講得很直白，它在談主機商時寫的是「it’s important to understand where their responsibility ends and yours begins」——重點不是主機商做了什麼，而是你要弄清楚它的責任在哪裡結束、你的責任從哪裡開始。這句話值得反覆讀，因為它暗示了一件事：這條界線本來就不是自然存在的，是被合約定義出來的。

下面這張表是我把三種常見主機型態的實際分工整理出來的結果。要注意的是，這裡的每一欄都不是「業界慣例」，而是要回到你自己那份合約去確認的項目。

層次	共享主機	VPS／雲端主機	託管型 WordPress 主機
實體機房、電力、網路	主機商	主機商	主機商
作業系統與 PHP 版本更新	主機商（你通常只能選版本，不能改設定）	你（除非另購管理服務）	主機商
Web 伺服器層的 WAF／模組	主機商（你通常無法自訂規則）	你	主機商（規則不一定可見）
WordPress 核心、外掛、佈景主題更新	你	你	依方案而定，核心多半由主機商代管
帳號、密碼、使用者角色	你	你	你
被入侵後的清理	你（主機商通常只提供停權與備份調閱）	你	依方案而定，通常另計費
對訪客／會員的法律責任	你	你	你

看得出來規律了嗎？越往下走，責任越集中在你身上；而「被入侵後的清理」與「對當事人的法律責任」這兩列，無論你用哪一種主機，答案都是你。換主機型態可以買到更多的技術代勞，但買不到法律責任的轉移。這一點是後面所有討論的基礎。

如果你還在決定要用哪一種主機，站上的WordPress 主機怎麼選？共享、VPS 與託管型主機的取捨與續約陷阱把價格與續約條件那一面拆得比較細，可以搭配這張表一起看；想直接看有哪些選項的話，WordPress 虛擬主機推薦 2026：新手架站 5 大主機商比較與選擇指南列了比較常見的幾家。

台灣主機商的合約真正寫了什麼

與其猜，不如直接讀。我挑了兩家在台灣能見度高、而且把條款完整公開在網站上的業者，把跟資安直接相關的條文原文抄下來。這一節的目的不是評價哪家好哪家壞，而是讓你知道這類條款長什麼樣子，好回去對照你自己那一份。

入侵造成的損失，合約通常直接寫「不負賠償責任」

戰國策集團在官網租用條款頁面公開的合約 PDF（檔名標示 2026-01 版，文件抬頭為「戰國策租賃合約書」，查核日 2026-08-06），第十條第（五）款是這樣寫的。先說明一件容易看錯的事：這份合約裡甲方指承租人（也就是你），乙方指戰國策，代號方向和下面第二家業者剛好相反。

甲方之系統如發生遭第三人經由網際網路入侵、破壞或擷取其資料等侵害情形，因此所生直接或間接之損失，乙方不負賠償責任。

同一份合約的第六條第（三）款，把「可以暫停或中斷服務、而且你不能要求補償」的情況列成六項，其中第 3 項是「系統遭第三人以非法行為入侵和破壞時」，第 4 項是「乙方客戶網站運作影響主機系統穩定時」。換句話說，網站被入侵不只是你自己要收拾，主機商還保留了在那個當下把你停掉的權利。

SLA 補償條款會把駭客攻擊排除在外

同一份合約第六條第（六）款是補償機制：中斷累計超過一小時延長使用期限七日，超過二十四小時可選擇延長一個月或折抵新臺幣 2,000 元的網路行銷抵用金。看起來還算大方，但補充說明那一段才是重點：

前述補償僅適用於因本公司責任造成之系統無法運作，不包含因第三方供應商、天災、戰爭、駭客攻擊或不可抗力因素。

駭客攻擊被與天災、戰爭並列為補償範圍之外。這代表如果你的站被打到掛，就算連續中斷超過二十四小時，SLA 補償也不會啟動。我看過不少人在選主機時把 SLA 數字當成資安保障的一部分，這是一個很常見的誤讀——SLA 保障的是「主機商自己搞砸」的情況，不是「有人來攻擊你」的情況。

備份的責任被明確推回給你

同一份合約第六條第（七）款：

為了安全起見，甲方租用本服務，務必定期自行做任何程式資料備份工作。如:資料庫、電子郵件、留言版、webbase 格式等，為保障自身權益，須視自身需求為資料資訊等備份或投保相關保險，以填補或減輕可能遭受之損害。

同條第（八）款的前半段講的是「甲方提出減少租用硬碟空間或更換主機（平台）之異動申請」這個特定情境，但它的後半句寫得比情境本身寬：

……甲方應自行保存網站及資料庫之備份，乙方在任何情況下都不應被要求賠償客戶資料毀損或遺失而造成的損失。

注意「投保相關保險」那五個字，這是合約自己寫進去的建議。至於主機商提供的備份，第六條第（十二）款寫得更具體：

乙方應維持本服務系統設備之正常運作，遇有障礙應儘速修復，本服務每日壹次定期操作客戶資料備份，乙方採差異備份，僅保留近七日之備份資料，其中一日為完整備份。但當日資料因系統設備障礙、阻斷，以致發生錯誤或毀損，本公司不負損害賠償責任。若客戶需調閱備份資料，本公司得依客戶要求，提供備份資料，此備份資料處理費另行報價。

只保留近七日，而且調閱要另外報價。這一條的實務殺傷力比看起來大得多：網站被植入後門後，站長通常不會在七天內發現。等到你發現前台開始跳出陌生的外連、或是搜尋結果裡出現你沒發過的頁面，主機端那七份備份很可能每一份都已經是被感染後的狀態。這也是為什麼WordPress 備份怎麼做才真的救得回來？外掛、主機端與異地備份的三層策略會強調異地與長保留期——只靠主機端備份，在資安事故的情境下往往是無效的。

共享主機還有一條你可能沒注意的條款

同一份合約第七條的開頭：

為保持所有用戶使用權益及系統各項功能正常運作，甲方應確實遵守下列各項規定：本服務為共享式資源，若甲方有下列任一情事，造成乙方系統之障礙、主機效能大量耗損或影響其他客戶使用權益，如經發現或檢舉，將立即暫停甲方主機使用權直至改善為止，甲方拒不改善者，乙方有權取消甲方主機使用權利!一切法律責任及造成之損害由甲方自行負責，甲方並不得向乙方提出損害賠償要求。

被入侵的網站往往會變成大量耗用資源的來源——被拿去發垃圾信、被當成跳板、或是被灌爆流量。在共享主機上，這會直接觸發上面這條：你不但要處理入侵，還要處理「站被停掉」這件事。我遇過的實際狀況是，站長被停權之後才知道自己被入侵，而且因為站被停了，連進後台看發生什麼事都做不到，只能靠 FTP 或主機管理面板慢慢摸。

另一家的條款用不同寫法達成同一件事

智邦生活館要分兩份文件看。全站適用的會員條款（查核日 2026-08-06）第 7 條寫的是系統中斷或故障「或許將造成您使用上的不便、資料喪失、錯誤、遭人篡改或其他經濟上損失」，接著明確表示「智邦生活館對於您因使用（或無法使用）本服務而造成的損害，不負任何賠償責任」；第 12 條免責聲明則寫「智邦生活館對本服務不提供任何明示或默示的擔保」。

但真正管到主機租用的是另一份企業加值服務租用契約條款（立契約書人為易達網股份有限公司，這份契約裡甲方是智邦、乙方是用戶，和戰國策那份剛好相反）。它的第 58 條後段幾乎是戰國策第十條第（五）款的同義句：

乙方之系統如發生遭第三人經由網際網路入侵、破壞或擷取其資料等任何侵害情形，因此所生直接或間接之損失，甲方概不負責。

第 57 條末句還多寫了一件戰國策沒明寫的事——責任上限：

如因法令或其他事由，甲方就其個別或所有可能衍生之賠償責任，以甲方向乙方所收取之總金額為賠償責任上限。

換句話說，就算真的賠，天花板也只是你付過的主機費。一份年繳三千元的虛擬主機，賠償上限就是那三千元的量級，和個資事故可能產生的賠償完全不在同一個級距。

公平起見也要提另一面：智邦第 30 條把「系統遭第三人以非法行為入侵和破壞」列在不得要求補償的八種情形之一，但同條但書寫了「因下列情形導致用戶連續二十四小時以上無法連線使用時，本公司將延長所有受影響用戶之使用期限一天作為補償」——這一點比戰國策把駭客攻擊完全排除在補償外要寬一些，不過補償形式一樣是延長使用期限，不是賠償損失。

用字不同，方向一致。我到目前為止沒有看過任何一家台灣主機商，在標準條款裡承諾為客戶網站遭入侵所生的損失負賠償責任。如果你看到有，那多半是額外付費的資安加值方案，而且會有自己的責任上限條款，簽之前要看清楚上限是多少。

「主機商應該會擋下來吧」是一個很貴的假設

合約上不負責是一回事，實際上擋不擋得住是另一回事。這一塊剛好有比較新的公開數據可以參考。

Patchstack 的《State of WordPress Security in 2026》白皮書（統計期間為 2025 年整年，頁面自載「Data updated 25.02.2026」，查核日 2026-08-06）裡有一節專門講主機商的防禦力，他們寫的是：

In 2025 we conducted two separate pentesting studies where we tested the effectiveness of common security solutions (internal WAFs, Cloudflare etc.) against vulnerability exploits.

第一項研究針對已知被實際利用的漏洞，結論是「traditional defences only blocked 12% of WordPress-specific vulnerability attacks」；第二項研究把範圍擴大到包含比較通用的漏洞類型，結果也只有「only 26% of total attacks were blocked」。換句話說，即使把主機端 WAF 與 CDN 都算進去，針對 WordPress 特定漏洞的攻擊，被擋下來的比例大約在一到三成之間。

這裡我必須誠實揭露一件事：Patchstack 本身就是賣 WordPress 漏洞防護產品的公司，這份數據對他們的商業利益有利。把它當成「業界唯一真相」是不對的，我的建議是把它當成一個方向性的參考——它至少證明了「主機商的 WAF 會幫我擋掉大部分漏洞攻擊」這個假設沒有堅實的證據支撐，而不是證明了確切的數字就是 12%。

漏洞的來源分布，決定了你的力氣該花在哪

同一份報告的其他數據對「責任分配」也很有參考價值。以下每一個數字我都標了它對應的統計年度：

指標	2024 年（2025 年報）	2025 年（2026 年報）
WordPress 生態系新增漏洞總數	7,966 個	11,334 個（年增 42%）
外掛佔比	96%	91%
佈景主題佔比	4%	9%
WordPress 核心	7 個	6 個（皆為低優先級）
公開揭露時仍未修補的比例	33%	46%
高風險漏洞	11.6%（約 924 個，報告稱 high Patchstack Priority）	1,966 個（17%，報告稱 high severity score）；報告另載「Highly exploitable vulnerabilities increased 113% YoY」

兩份報告的外掛／佈景主題佔比可以直接對比，因為分母定義是一致的：兩年都是以「該年度整個 WordPress 生態系新增的漏洞總數」為分母，外掛加佈景主題就接近 100%（核心的個位數在四捨五入後幾乎不佔比例）。所以佈景主題從 4% 跳到 9% 是同一把尺量出來的真實變化，2026 年報把主因指向 Envato 這類付費元件市集的漏洞被大量挖出。至於最後一列的高風險漏洞，兩年的標籤不同（high Patchstack Priority 對 high severity score），嚴格說不是同一個欄位，這一列請當成量級參考而不是精確年增率。

連續兩年，超過九成的漏洞來自外掛。核心本身的問題少到幾乎可以忽略——2025 年整年只有 6 個，而且都被評為低優先級。這個分布告訴你一件很實際的事：你在資安上能做的最有效決定，不是買什麼防護服務，而是你決定在網站上裝哪些第三方程式碼。

這件事的另一面是速度。同一份 2026 年報告指出，高影響力漏洞「approximately half of high impact vulnerabilities get exploited within 24 hours」，而首次被利用的加權中位數時間是 5 小時。這代表「等一陣子再更新比較穩」這個直覺，在安全性更新上是錯的。當一個漏洞被公開，修補公告本身就是給攻擊者的地圖，而你在那之後只有幾個小時的緩衝。

把這兩件事合起來看，結論很清楚：控制外掛數量、只裝有在維護的外掛、安全性更新立刻套用，這三件事的投報率遠高於任何額外的防護採購。站上的WordPress 外掛太多會變慢？我把網站精簡到 11 支的取捨清單是從速度角度寫的，但那份取捨清單的邏輯拿來做資安減法一樣適用；佈景主題的來源判斷則可以參考免費 WordPress 佈景主題怎麼選？新手安全下載與評估指南。至於裝了一堆外掛之後開始互相打架的診斷方法，WordPress外掛衝突？診斷與解決方案速查有比較完整的流程。

Cloudflare 免費方案：能做什麼、做不到什麼

Cloudflare 的免費方案是台灣個人站長最常用的邊界防護，值得單獨拆一節，因為它能做的事比很多人以為的多，但它做不到的事也比很多人以為的多。以下依據 Cloudflare 官方開發者文件，查核日 2026-08-06。

免費方案確定可以用的

Free Managed Ruleset。官方文件寫的是「Users on the Free plan have access to the Cloudflare Free Managed Ruleset, a subset of the Cloudflare Managed Ruleset.」它會自動部署，不需要你做任何設定。重點在後半句：它是完整 Managed Ruleset 的一個子集，不是全部。

自訂規則（Custom rules）5 條。依官方可用性表格，Free 為 5 條、Pro 為 20 條、Business 為 100 條、Enterprise 為 1,000 條。動作方面，Free、Pro、Business 為「All except Log」，只有 Enterprise 可以用 Log。正規表達式（regex）比對只有 Business 與 Enterprise 才提供，這一點在寫比較複雜的路徑條件時會踩到。

速率限制規則（Rate limiting rules）1 條。Free 1 條、Pro 2 條、Business 5 條、Enterprise 100 條。Free 與 Pro 的計數特徵（counting characteristics）只支援 IP，Business 以上才有 IP with NAT support 等選項。要注意 Free 的計數週期與緩解逾時固定就是 10 秒、沒有其他選項（官方表格在 Free 欄只列出「10 s」，Pro 才開始是「所有支援值，最長 1 分鐘／1 小時」），所以免費方案的速率限制只能擋短時間內的密集嘗試，擋不了慢速撞庫。

對一個個人網站來說，這組配額其實夠用。把唯一那條速率限制規則放在登入端點，是免費方案最划算的一步。剩下 5 條自訂規則可以用在封鎖明顯的掃描路徑或特定國家的異常流量上。

免費方案做不到的

完整的 Cloudflare Managed Ruleset 與 OWASP 核心規則集需要 Pro 以上。依官方可用性表格，Cloudflare Managed Ruleset 與 Cloudflare OWASP Core Ruleset 都是 Pro 及以上方案才能部署。這代表免費方案擋掉的是比較廣泛、比較基礎的攻擊模式。

WAF attack score 只有 Business 與 Enterprise。官方文件寫得很明確：「WAF attack score is only available to Business customers (limited access to a single field) and Enterprise customers (full access).」

最重要的一項：Cloudflare 擋不住繞過 Cloudflare 的連線。官方在「Protect your origin server」文件裡建議的作法包括設定 proxied（橘雲）DNS 記錄來隱藏來源 IP、稽核既有的 DNS-only 記錄確保它們不含來源 IP 資訊、以及在網路層「Explicitly block all traffic that does not come from Cloudflare IP addresses」。如果攻擊者知道你的來源伺服器 IP，而你的伺服器又接受任何來源的連線，那麼 Cloudflare 上的所有規則都會被直接跳過。

這一點在共享主機上特別麻煩，因為你通常無法在伺服器層設定 IP 白名單。實務上能做的是：確認沒有任何一筆 DNS 記錄（包含 mail、ftp、cpanel 這類子網域）用灰雲直接指向來源 IP，因為那等於把地址貼在門口。順帶一提，網站的憑證與 HTTPS 設定如果你還沒收尾乾淨，WordPress SSL 憑證安裝與 HTTPS 轉換完整指南有轉換後該檢查的項目。

你自己那一塊：官方文件真正要求的三件事

技術設定的完整版在WordPress 網站安全基本功那一篇，這裡我只挑三件「責任明確在你身上、而且官方文件寫得很具體」的項目，因為這三件事在出事後會被問到。

檔案權限

WordPress 官方的 Hardening WordPress 文件寫的是自動更新後「all directories are set to 0755」與「All files are set to 0644」。文件也給了對應的指令：目錄用 find /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \;，檔案用 find /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \;。共享主機上如果你發現目錄權限是 777，那不是設定不良，那是等著被寫入。

wp-config.php 的保護

官方給了三種作法，可以疊加使用。第一是搬位置：「You can move the wp-config.php file to the directory above your WordPress install.」第二是權限：「make sure that only you (and the web server) can read this file (it generally means a 400 or 440 permission)」。第三是在 .htaccess 加上：

<Files "wp-config.php">
Require all denied
</Files>

wp-config.php 裡有資料庫帳密，它外洩的後果比後台密碼外洩嚴重得多，因為攻擊者可以直接繞過整個應用層。

停用後台檔案編輯器

在 wp-config.php 加入 define( 'DISALLOW_FILE_EDIT', true );。官方說明它「is equivalent to removing the ‘edit_themes’, ‘edit_plugins’ and ‘edit_files’ capabilities of all users」。

但官方緊接著寫了一句很誠實的話：「This will not prevent an attacker from uploading malicious files to your site, but might stop some attacks.」它擋的是「已經拿到後台權限之後、順手改佈景主題檔案」這條路，不是擋入侵本身。我把這句話特別抄出來，是因為它示範了一種很好的資安敘述方式——講清楚一個措施擋什麼、不擋什麼，比宣稱「做了就安全」有用得多。

出事的那一刻，法律上你是誰

這一節是整篇最需要小心的部分，因為個資法在 2025 年 11 月有一次大幅修正，而修正條文截至查核日 2026-08-06 仍未施行。我把現行有效的規定與尚未施行的新規定分開講，兩者不要混用。

先確認你是不是「非公務機關」

個資法第 2 條第 8 款定義：「非公務機關：指前款以外之自然人、法人或其他團體。」自然人也算——你個人名義經營的網站，只要不落在排除規定裡，就是本法的規範對象。

排除規定在第 51 條第 1 項：

有下列情形之一者，不適用本法規定：
一、自然人為單純個人或家庭活動之目的，而蒐集、處理或利用個人資料。
二、於公開場所或公開活動中所蒐集、處理或利用之未與其他個人資料結合之影音資料。

這一條要特別確認版本：114 年 11 月 11 日那次修正的清單裡沒有第 51 條（該次只增訂了另一條獨立的第 51 條之 1，處理主管機關過渡期的管轄分工），我逐字比對過修正前後兩個版本的第 51 條，文字完全相同。所以上面這段排除規定不會因為新法上路而改變。

關鍵字是「單純個人或家庭活動之目的」。一個純粹寫給自己看、沒有留言、沒有訂閱名單、沒有任何營利安排的網誌，主張這一款可能有空間；但只要你開始收電子報訂閱、放聯盟行銷連結、開接案詢問表單、或用 WooCommerce 賣東西，「單純個人或家庭活動」這個要件就很難成立。

我的建議是保守處理：只要你的網站上有任何一個欄位在收 Email、姓名或電話，就當作自己是非公務機關來準備。這個判斷的成本很低，但如果賭錯了，成本很高。有在收訂閱名單的人可以順便對照電子報訂閱名單從 0 到 1000：訂閱來源、發送節奏與退訂率控制裡的名單來源做法；有在賣東西的則會同時碰到會員與訂單資料，WooCommerce 開店完整流程：從安裝、金流到物流設定裡的資料流可以拿來當盤點起點。

現行有效的義務：第 27 條的安全維護

個資法現行第 27 條第 1 項：

非公務機關保有個人資料檔案者，應採行適當之安全措施，防止個人資料被竊取、竄改、毀損、滅失或洩漏。

「適當之安全措施」是什麼，施行細則（民國 105 年 3 月 2 日修正）第 12 條給了定義與清單。第 1 項說它「指公務機關或非公務機關為防止個人資料被竊取、竄改、毀損、滅失或洩漏，採取技術上及組織上之措施」；第 2 項列了十一款可以包括的事項，並明訂「以與所欲達成之個人資料保護目的間，具有適當比例為原則」。那十一款包括配置管理人員與資源、界定個人資料範圍、風險評估與管理機制、事故之預防通報及應變機制、內部管理程序、資料安全管理及人員管理、認知宣導與教育訓練、設備安全管理、資料安全稽核機制、使用紀錄與軌跡資料及證據保存，以及整體持續改善。

「具有適當比例為原則」這幾個字對個人站長很重要——法規沒有要求一個部落客做到跟銀行一樣的規格，但也不是零。我自己的理解是：把「你做了哪些措施、為什麼這樣做」寫下來留檔，本身就是履行這一條最務實的方式。

現行有效的義務：第 12 條的通知

這一條最容易被寫錯。現行有效的第 12 條全文是：

公務機關或非公務機關違反本法規定，致個人資料被竊取、洩漏、竄改或其他侵害者，應查明後以適當方式通知當事人。

三個要件請注意：一是「違反本法規定」，二是「查明後」，三是只要求「通知當事人」，沒有要求通報主管機關。至於什麼叫「適當方式」，施行細則第 22 條寫的是「指即時以言詞、書面、電話、簡訊、電子郵件、傳真、電子文件或其他足以使當事人知悉或可得知悉之方式為之」，需費過鉅時得以網際網路、新聞媒體或其他適當公開方式為之；通知內容「應包括個人資料被侵害之事實及已採取之因應措施」。

罰則與賠償：數字比想像中大

現行有效的第 48 條（民國 112 年 5 月 31 日修正公布、自公布日施行）分三項，三項的門檻差很多，看的時候要對準條號。第 1 項規定違反第 8、9、10、11、12、13 條或第 20 條第 2、3 項者，由中央目的事業主管機關或直轄市、縣（市）政府限期改正，屆期未改正者按次處新臺幣 2 萬元以上 20 萬元以下罰鍰。第 2 項規定違反第 27 條第 1 項或未依第 2 項訂定安全維護計畫、業務終止後個人資料處理方法者，處新臺幣 2 萬元以上 200 萬元以下罰鍰，並令限期改正，屆期未改正者按次處新臺幣 15 萬元以上 1,500 萬元以下罰鍰。第 3 項是同樣針對第 27 條那組義務，但情節重大者，直接處新臺幣 15 萬元以上 1,500 萬元以下罰鍰，並令限期改正，屆期未改正者按次處罰。

換句話說，1,500 萬那個級距綁的是安全維護措施（第 27 條），不是通知義務（第 12 條）；違反通知義務落在第 1 項的 2 萬到 20 萬。把兩者混為一談，會高估通知義務的罰鍰、低估安全維護的罰鍰。

民事賠償在第 29 條，這一條的寫法對站長非常不利：

非公務機關違反本法規定，致個人資料遭不法蒐集、處理、利用或其他侵害當事人權利者，負損害賠償責任。但能證明其無故意或過失者，不在此限。

「但能證明其無故意或過失者，不在此限」——舉證責任在你身上。當事人不需要證明你有過失，是你要證明自己沒有。這是我認為個人站長最該理解的一條，因為它把「平常有沒有留紀錄」從加分項變成了防禦手段：更新紀錄、備份紀錄、權限盤點紀錄，在這個條文底下就是證據。

賠償金額依第 29 條第 2 項「適用前條第二項至第六項規定」。第 28 條第 3 項寫「如被害人不易或不能證明其實際損害額時，得請求法院依侵害情節，以每人每一事件新臺幣五百元以上二萬元以下計算」；第 4 項則是同一原因事實造成多數當事人受害時，「其合計最高總額以新臺幣二億元為限」，但同項還有一段但書很少被引用：「但因該原因事實所涉利益超過新臺幣二億元者，以該所涉利益為限。」也就是說二億元不是絕對天花板，涉及利益更大時上限跟著往上走。用最低的每人 500 元去算，一份三千人的訂閱名單外洩就是 150 萬元的量級。這也是為什麼合約裡會出現「投保相關保險」那句話——關於接案者的保險缺口，自由工作者要不要保商業保險？接案者的職災與收入中斷風險缺口怎麼補有比較完整的討論。

一個常被誤引的法：資通安全管理法

常有人拿資通安全管理法來嚇人。這部法在民國 114 年 9 月 24 日修正公布全文 35 條，並由行政院令定自 114 年 12 月 1 日施行，所以它和個資法修正案不同，是已經上路的現行版本，引用時要用新版而不是 107 年那版。適用對象在新版第 3 條的定義裡就限縮了：公務機關「指依法行使公權力之中央、地方機關（構）或公法人。但不包括軍事機關及情報機關」；特定非公務機關「指關鍵基礎設施提供者、公營事業、特定財團法人或受政府控制之事業、團體或機構」。

一般個人網站與小型公司不在適用範圍內，除非被指定為關鍵基礎設施提供者。你會被個資法管，但不會被資安法管。這個區分值得記住，因為市面上有些資安服務的行銷素材會把兩者混在一起講。

還沒上路、但已經看得到的 72 小時

個人資料保護法部分條文於民國 114 年 11 月 11 日經總統修正公布，個人資料保護委員會籌備處的公告內文寫的是「修正條文施行日期，將另由行政院依同法第 56 條第 1 項定之」。全國法規資料庫上該版本的沿革記載「施行日期，由行政院定之」，生效狀態欄則是「※本法規部分或全部條文尚未生效，最後生效日期：未定」。查核日 2026-08-06，行政院尚未發布指定施行日期的命令，主管機關的官方網站也仍名為「個人資料保護委員會籌備處」。

怎麼確認「真的沒有」？法規資料庫的沿革在每一次修正之後，都會把行政院發布施行日的令接著列出來——例如 104 年 12 月 30 日那次修正，後面就緊接著「中華民國一百零五年二月二十五日行政院院臺法字第 1050154280 號令發布定自一百零五年三月十五日施行」。114 年 11 月 11 日那一條後面是空的。我另外查了行政院公報從 2025 年 11 月 12 日到查核日之間所有與個人資料保護相關的公告，全部都是籌備處的草案預告，沒有任何一則行政院令。

還沒定施行日是有原因的：籌備處在三讀後的說明寫得很清楚，個資會的正式成立要等組織法完成立法，行政院會配合組織法的審議進度「另行指定個資法新法之施行日期」。換句話說，這件事的時程不由個資法本身決定，追蹤點應該放在個人資料保護委員會組織法。

這件事還有個容易踩的坑：全國法規資料庫的條文頁面直接顯示修正後的文字，不會特別標示哪幾條還沒生效。最明顯的例子是第 27 條，那一頁現在顯示的是「（刪除）」——但那是新法的狀態，現行有效的第 27 條還在。如果你只看那個頁面，很容易把還沒上路的義務當成現在就要做的事，或反過來以為現行義務已經消失。要確認現行條文，有兩個可靠作法：一是看官方公布的修正對照表，那份文件會把「修正條文」與「現行條文」並排；二是在法規資料庫點「連結舊法規內容」，叫出 112 年 5 月 31 日那個版本，那才是目前真正有效的全文。本文的第 12、27、28、29、48、51 條原文都是用這兩個來源交叉比對過的。

新版第 12 條會多出什麼

修正後的第 12 條第 1 項把「違反本法規定」與「查明後」兩個要件刪掉了，改成「公務機關或非公務機關知悉所保有之個人資料被竊取、竄改、毀損、滅失或洩漏時，應通知當事人」。第 2 項新增通報義務：符合一定通報範圍者，非公務機關應向主管機關通報，主管機關受理後再轉知目的事業主管機關。第 3 項要求採取即時有效之應變措施、記載相關事實影響與已採取之因應措施並保存紀錄。第 4 項授權主管機關訂定辦法。

從「查明後通知」變成「知悉即通知」，這個差別在實務上非常大。舊版你可以先調查清楚再說；新版一旦知悉就開始起算。

同一次修正還做了一件容易被忽略的事：第 27 條被刪除，安全維護義務移到新增的第 20 條之 1——「非公務機關保有個人資料檔案者，應辦理安全維護事項，防止個人資料被竊取、竄改、毀損、滅失或洩漏」，並授權主管機關訂定管理辦法。義務本身沒有消失，只是換了條號、而且未來的細節會由主管機關的辦法來定。相對應地，新版第 48 條的罰鍰條號也整組重寫了。這代表新法上路那一天，網路上所有寫「個資法第 27 條」的文章都會同時過期，包括這一篇的那一節，屆時要回來改。

子法草案已經預告，時限是 72 小時

個人資料保護委員會籌備處於民國 115 年 1 月 22 日以個資籌查字第 1140500549 號公告，預告訂定「個人資料事故通知通報及應變辦法」草案，依行政程序法第 154 條第 1 項辦理，訂定依據為個資法第 12 條第 4 項，預告期間為公告刊登公報次日起 60 日。公告事項第一點就把時程講死了：「訂定機關：個人資料保護委員會。（俟該會成立後訂定發布）」——也就是說這份辦法要等個資會正式成立才會發布。查核日 2026-08-06，預告期已於 2026 年 3 月 23 日屆滿，籌備處的主管法規查詢系統顯示「尚無預告中法規草案」，現行法規清單裡也還沒有這部辦法。以下是草案條文的重點，請注意這是草案、還沒發布施行，內容還可能改。

草案條次	要求	門檻或期限
第 2 條	通知當事人	知悉時起 72 小時內以適當方式個別通知；符合三種例外情形時得以網際網路、新聞媒體或其他適當公開方式為之，並應至少連續公開 30 日
第 3 條	通報主管機關	知悉時起 72 小時內，限於三種通報範圍之一：涉有本法第 6 條第 1 項所規定之個人資料、所涉資通系統保有個人資料筆數達一萬筆以上、所影響之個人資料筆數達一百筆以上
第 4 條	應變措施	檢查洩漏途徑並隔離或封鎖、檢查存取權限阻止異常存取路徑、收回誤送檔案、請求搜尋引擎業者刪除已公開之個人資料、其他即時有效措施
第 5 條	委託關係	受託者知悉個資事故視為委託機關知悉；受託者應於知悉時立即通知事故機關並保存通知紀錄
第 6 條	紀錄保存	相關紀錄應於知悉個資事故之翌日起至少保存 5 年
第 7 條	施行日期	由主管機關定之

草案第 2 條第 2 項也規定了通知內容應包括哪些事項：發生個資事故時間及事實、受影響之個人資料類別、依第 4 條採取之應變措施、事故機關聯絡方式與救濟或諮詢管道。草案第 3 條第 2 項則列了通報內容的八個項目，包含事故發生原因及類型、所涉個人資料類別與估計數量、以及通知當事人的方式與內容。

特別留意草案第 3 條第 1 項第 2 款「所涉之資通系統保有個人資料筆數達一萬筆以上」——門檻是系統裡「保有」的筆數，不是實際外洩的筆數。一個累積了一萬筆訂閱者的電子報系統，只要發生事故就落入通報範圍，即使真正被拿走的只有一百筆。

另外，本法第 6 條第 1 項所規定的個人資料指的是「病歷、醫療、基因、性生活、健康檢查及犯罪前科」，這類特種個資只要一涉及，就沒有筆數門檻可言。

接案代管：責任怎麼切才切得乾淨

如果你幫客戶架站、還順便幫忙維護，這一節是你最需要的。問題的核心在於個資法第 4 條：「受公務機關或非公務機關委託蒐集、處理或利用個人資料者，於本法適用範圍內，視同委託機關。」你以受託者身分碰到客戶的會員資料時，在本法適用範圍內是被視同委託機關的。

而前面提到的草案第 5 條，把這件事往前推了一步：受託者知悉個資事故，視為委託機關知悉；受託者應於知悉時立即通知事故機關並保存通知紀錄。草案的逐條說明還寫了一段很值得看的話——受託者違反第 2 項通知事故機關的義務時，本法無法對受託者裁罰；此時事故機關（也就是你的客戶）「除有行政罰法所定不予處罰之規定外（例如無故意或過失）」，以其違反通知或通報義務之行為論處。至於受託者疏未通知導致客戶被行政裁罰，「雙方關係應回歸委託契約或民法規定處理」。

翻成白話：你沒通知客戶，主管機關罰的對象是客戶而不是你（客戶還有機會主張自己無故意過失而不罰）；客戶回頭要不要向你求償，看你們的合約怎麼寫。所以合約才是這件事真正的戰場。

代管合約裡我會堅持寫進去的幾件事

下面這份清單是我自己在用的，不是法律意見，但每一項都對應到前面某個具體條文或條款：

一、服務範圍的正面表列與負面表列。寫清楚你負責更新哪些東西、監控什麼、多久一次；同時明確寫出你不負責的部分，例如「主機層之作業系統與網頁伺服器設定由主機商負責」「客戶自行安裝之外掛不在維護範圍」。沒有負面表列，出事時所有東西都會被算成你的。

二、事故通知的內部時限。既然草案要求受託者「立即通知」，合約裡就把它具體化成一個小時數，並寫明通知方式與保存紀錄的做法。這條同時保護雙方。

三、備份的責任歸屬與保留期。寫明備份由誰做、放在哪裡、保留幾份、多久做一次還原演練。前面提過主機端備份可能只保留七日，如果合約沒寫，客戶預設會以為你有做。

四、權限的最小化與離場條款。寫明你在專案期間取得哪些權限、專案結束後多久內撤銷、以及交接的方式。這一塊的操作細節可以參考密碼管理器怎麼選？接案者的客戶帳密交接與離場撤銷實戰，那篇把撤銷流程寫得比合約條款具體。

五、責任上限。個資法第 28 條那個「合計最高總額二億元」是團體求償對事故機關的上限（而且還有所涉利益更高時從高認定的但書），你和客戶之間的求償則回歸契約。沒有寫上限，等於沒有上限。順帶一提，主機商很清楚這一點——前面引的智邦第 57 條就把自己的賠償上限寫成「向乙方所收取之總金額」，你的合約也可以這樣寫。

六、客戶端資料的最小化原則。能不收的欄位就不要收。你的網站上少存一種個人資料，事故發生時的通報門檻與賠償基數就少一塊。接案者的客戶管理怎麼建？跟進節奏、最小可用 CRM 與個資責任那篇談的最小可用原則，套在客戶網站的欄位設計上同樣成立。

條款的寫法與驗收、著作權歸屬怎麼搭在一起，接案合約怎麼簽？必備條款、驗收與著作權歸屬完整指南有完整的條款結構；如果你的報價單本身就要當成合約的一部分，網頁設計報價單怎麼寫？欄位結構、著作權歸屬與代墊費用的實務條款裡的欄位結構可以直接沿用。簽署方式的效力問題則在接案合約用電子簽名有效嗎？台灣電子簽章法、工具比較與跨國簽約實務。

順帶一提：你自己的身分

個資法把自然人也納入非公務機關，跟你有沒有辦稅籍登記無關。不要以為「我只是個人接案、沒有公司」就不在管轄範圍內。要不要辦登記是另一個層次的問題，一個人接案要辦營業登記嗎？稅籍登記與起徵點判斷有判斷標準，但那跟個資法責任是兩條平行線。

誠實評估：哪些常見建議的效益其實很低

這一節可能會不受歡迎，但我認為比多列十個「你該做的事」有價值。下面每一項我都會說明它擋什麼、為什麼效益有限、以及該用什麼取代。

常見建議	實際擋得住什麼	為什麼效益有限	更值得做的事
把後台登入網址改掉	只掃固定路徑的低階機器人	屬於隱藏而非防護；一旦路徑被記錄或外洩就完全失效，還可能把自己鎖在外面	長密碼加兩階段驗證，再用 Cloudflare 那一條速率限制規則擋登入端點
隱藏 WordPress 版本號	幾乎沒有	掃描器是直接嘗試漏洞而不是先讀版本號；2025 年核心漏洞只有 6 個且皆為低優先級	把力氣放在外掛更新，那裡佔了 91% 的漏洞
更改資料庫前綴	少數寫死前綴的自動化攻擊	對已經拿到資料庫連線資訊的攻擊者毫無作用；在既有站上改動風險高	保護 wp-config.php（400 或 440 權限＋.htaccess 阻擋）
裝一支「全能安全外掛」就收工	提供掃描與部分規則	它本身也是外掛，也在那 91% 的統計母體裡；且無法涵蓋主機層與邊界層	先做外掛減法，再補監控；把「這一層擋不住什麼」寫下來
只依賴主機商的每日備份	硬體故障造成的資料遺失	保留天數可能只有 7 天，且調閱可能要另外報價；被感染的備份還原回去等於白做	異地備份加長保留期，並實際做過一次還原演練
用 SLA 數字當資安保障	主機商自身疏失造成的中斷	合約可能明文把駭客攻擊排除在補償範圍外	讀合約的免責條款，而不是讀行銷頁面的可用率數字
相信「我的站太小沒人要攻擊」	什麼都擋不住	掃描是無差別的；2025 年新增 11,334 個漏洞，攻擊者要找的是未更新的站不是有名的站	把更新節奏固定下來，讓「小站」也在幾小時內完成安全性更新

這張表最重要的一欄是第三欄。我不是說前面那些事情都不要做——改登入路徑在某些情境下確實會減少雜訊、降低主機負載。我要說的是：如果你把有限的時間花在這些項目上，而沒有處理外掛更新與備份還原，你的整體風險幾乎沒有下降。資安的資源分配是零和的，做了低效益的事，就是沒做高效益的事。

一份可以照著跑的責任清冊

把前面所有內容收斂成一份可以在半小時內做完的自我盤點。建議把答案寫成文字檔留存，因為在第 29 條的舉證責任結構下，這份紀錄本身就有價值。

合約層（一次性，之後續約再看）。找出主機商的服務條款或租用合約，搜尋「備份」「入侵」「賠償」「暫停」四個關鍵字，把找到的條文抄進你的文字檔。確認三件事：備份保留幾天、遭入侵時業者是否免責、是否有你可能觸發的停權條款。

資料層（每季一次）。列出你的網站目前收集哪些個人資料欄位、存在哪裡、保留多久。包含 WordPress 使用者表、留言、聯絡表單外掛的資料庫紀錄、電子報名單、電商訂單。清點完之後問自己：哪些欄位可以直接停收？哪些舊資料可以刪掉？草案的通報門檻是以「保有筆數」計算的，資料減量會直接降低你未來的合規負擔。

技術層（每週一次，十分鐘）。套用外掛與佈景主題的安全性更新（更新前確認備份存在）；看一眼是否出現非預期的新使用者或角色變動。這兩件事對應的是那 91% 的漏洞來源與最常見的入侵後動作。

邊界層（一次性設定，半年複查）。確認 Cloudflare 那一條速率限制規則有掛在登入端點；確認沒有任何 DNS 記錄以灰雲直接暴露來源 IP；確認自訂規則沒有超過 5 條的配額。

還原層（每季一次，一小時）。把最近一份備份還原到測試環境，實際打開看一次。沒有做過還原演練的備份，在事故當下只能算是一個未經驗證的假設。

紀錄層（持續）。維護一份簡單的紀錄：每次更新的日期與版本、每次權限異動、每次事故與處理過程。草案第 6 條要求相關紀錄自知悉事故之翌日起至少保存五年，即使那條還沒施行，養成習慣的成本也很低。

至於這些工作要花多少錢才合理，可以把它放進整體的網站維運預算裡一起看——自架站新手的六個決策：網域、主機、佈景主題與上線後維護該怎麼取捨把上線後的維護成本拆得比較清楚。如果你經常在外面用公共網路連後台，在咖啡廳與共享空間工作：選點、設備、公共 Wi-Fi 資安與禮儀全指南那篇的連線習慣值得一併檢查，因為管理者裝置本身也是責任鏈的一環。

常見問題

網站被駭之後，我可以要求主機商賠償嗎？

要回到你那份合約。以我查核到的台灣主機商公開條款來看，遭第三人入侵造成的損失通常被明文列為業者不負賠償責任的情形，SLA 補償條款也可能把駭客攻擊排除在外。如果損害是由主機商自身的疏失造成（例如它的系統被入侵導致所有客戶受影響），那是另一種情況，但舉證會很困難。務實的作法是事前就假設拿不到賠償，並據此決定備份與保險的投入。

我的部落格只有留言功能，也要遵守個資法嗎？

留言通常會收 Email，很難主張第 51 條第 1 項第 1 款的「單純個人或家庭活動之目的」，尤其當網站帶有任何營利安排時。比較安全的假設是：只要有欄位在收個人資料，就當作自己是非公務機關。實際做法不必複雜——依施行細則第 12 條，安全維護措施要「與所欲達成之個人資料保護目的間，具有適當比例」，一個小型部落格的合理比例本來就低於一家電商。

72 小時通報是現在就要做的嗎？

截至查核日 2026 年 8 月 6 日，不是。72 小時的規定來自「個人資料事故通知通報及應變辦法」草案，而該辦法的母法（個資法修正條文，114 年 11 月 11 日修正公布）施行日期由行政院定之，尚未公告；辦法本身也還在草案階段，其第 7 條寫明施行日期由主管機關定之，而預告公告更直接載明訂定機關是「個人資料保護委員會（俟該會成立後訂定發布）」。現行有效的仍是第 12 條的「應查明後以適當方式通知當事人」，沒有通報主管機關的義務，也沒有法定時限。要判斷什麼時候會變，追蹤點是個人資料保護委員會組織法的立法進度：組織法通過、個資會成立，行政院才會指定個資法新法的施行日。不過我建議現在就照 72 小時的節奏演練，因為新制上路後不會有緩衝期給你重建流程。

用 Cloudflare 免費方案夠嗎？

對一個沒有交易功能的內容網站，免費方案加上正確的設定通常是合理的起點：Free Managed Ruleset 會自動部署，你還有 5 條自訂規則與 1 條速率限制規則可以用。但要清楚它的兩個邊界：完整 Managed Ruleset 與 OWASP 核心規則集需要 Pro 以上方案；而且如果來源 IP 外洩、伺服器又接受任意來源連線，所有規則都會被繞過。有金流或會員資料的站，值得把升級費用與潛在賠償金額放在一起評估。

我幫客戶維護網站，客戶的站出事會不會罰到我？

依現行個資法第 4 條，受託處理個人資料者於本法適用範圍內視同委託機關。而依尚未施行的通報辦法草案第 5 條的逐條說明，受託者違反通知義務時本法無法對受託者裁罰，是以事故機關（委託方）違反通知或通報義務論處，受託者疏未通知導致委託方受罰的部分「應回歸委託契約或民法規定處理」。行政罰的對象通常是客戶，你面對的是客戶依合約或民法向你求償。所以代管合約裡的責任範圍與責任上限條款，才是你真正的防線。

資安要花多少錢才夠？

沒有官方標準可以引用，我也不會給你一個看起來精確的數字。但有一個可以自己算的參考基準：把你網站上個人資料的筆數乘以新臺幣 500 元（個資法第 28 條第 3 項法定最低賠償額），得到的數字就是最樂觀情況下的潛在賠償量級。如果你的年度資安投入遠低於這個數字的百分之一，那可能值得重新檢視資源分配。這只是一個思考工具，不是任何形式的財務建議。

資料來源

• 全國法規資料庫：個人資料保護法——此頁顯示的是 114 年 11 月 11 日修正後、尚未生效的條文（第 27 條顯示「（刪除）」、第 12 條為新版），本文據此說明新法內容與第 20 條之 1、第 51 條之 1。查核日 2026-08-06。
• 全國法規資料庫：個人資料保護法歷史法規（民國 112 年 5 月 31 日版）——目前真正有效的全文，本文第 2、4、12、27、28、29、48、51 條的現行條文以此版為準，並與修正對照表交叉比對。
• 全國法規資料庫：個人資料保護法沿革——證明 114 年 11 月 11 日修正版狀態為尚未生效、施行日期由行政院定之，且該次修正清單只增訂第 51 條之 1、未修正第 51 條，並刪除第 27 條。
• 行政院公報資訊網——查核日以標題與全文兩種方式檢索 2025 年 11 月 12 日至 2026 年 8 月 6 日之間「個人資料保護」相關公告，結果全為籌備處的草案預告，查無行政院發布個資法修正條文施行日期之命令。
• 個人資料保護委員會籌備處：個人資料保護法部分條文修正對照表——並排列出修正條文與現行條文，本文據此確認現行有效的第 12 條、第 27 條與第 48 條原文。
• 個人資料保護委員會籌備處公告（114 年 11 月 11 日）——標題為「⋯⋯本次修正條文施行日期將另由行政院定之」，內文則載明「修正條文施行日期，將另由行政院依同法第 56 條第 1 項定之」，並列出該次增訂、刪除與修正的完整條號。
• 全國法規資料庫：個人資料保護法施行細則——第 12 條的安全維護措施定義與十一款清單、第 22 條的適當方式通知定義，最新修正民國 105 年 3 月 2 日。
• 行政院公報第 032 卷第 015 期：預告訂定「個人資料事故通知通報及應變辦法」草案——個資籌查字第 1140500549 號公告全文與草案逐條，本文的 72 小時時限、通報三門檻、五年紀錄保存期均出自此。
• 公共政策網路參與平臺：該辦法草案預告頁——確認公告日期 115 年 1 月 22 日、預告期間 60 日（已於 115 年 3 月 23 日屆滿）、公告事項載明訂定機關為「個人資料保護委員會（俟該會成立後訂定發布）」，以及查核日仍為草案階段。
• 全國法規資料庫：資通安全管理法——現行版本為民國 114 年 9 月 24 日修正公布全文 35 條、經行政院令定自 114 年 12 月 1 日施行；本文引用其第 3 條的公務機關與特定非公務機關定義，證明一般個人網站不在適用範圍內。
• 戰國策集團：租用條款頁（所連結之合約 PDF 抬頭為「戰國策租賃合約書」，檔名標示 2026-01）——第六條第（三）（六）（七）（八）（十二）款的入侵免責、SLA 排除駭客攻擊、備份僅保留近七日且調閱另行報價、第七條共享資源停權、第十條第（五）款入侵損失不負賠償責任等條文原文，均自 PDF 逐字比對；該合約中甲方為承租人、乙方為戰國策。
• 智邦生活館：會員條款——第 7 條系統中斷不負任何賠償責任、第 12 條不提供任何明示或默示擔保。
• 智邦生活館：企業加值服務租用契約條款——實際規範主機租用的契約（立契約書人為易達網股份有限公司，甲方為智邦、乙方為用戶）；本文引用其第 30 條暫停服務不得請求補償之八款情形與連續二十四小時延長一天的但書、第 57 條以已收取總金額為賠償責任上限、第 58 條入侵所生損失概不負責。
• Patchstack：State of WordPress Security in 2026——統計 2025 年，11,334 個新增漏洞（年增 42%）、外掛佔 91%／佈景主題 9%、核心僅 6 個且皆為低優先級、46% 揭露時未修補、1,966 個（17%）高嚴重度且報告載明「Highly exploitable vulnerabilities increased 113% YoY」、「approximately half of high impact vulnerabilities get exploited within 24 hours」與首次利用加權中位數 5 小時，以及兩項滲透測試中傳統防禦僅擋下 12%／26% 的數據。
• Patchstack：State of WordPress Security in 2025——統計 2024 年，7,966 個新增漏洞、外掛佔 96%／佈景主題 4%、核心 7 個、11.6% 獲高 Patchstack Priority 評分、33% 揭露時未修補，作為前一年度的對照基準。兩份報告的外掛與佈景主題佔比同以該年度新增漏洞總數為分母，可直接對比。
• WordPress 官方：Hardening WordPress——目錄 0755 與檔案 0644 的建議值、wp-config.php 的 400／440 權限與 .htaccess 寫法、DISALLOW_FILE_EDIT 的作用與其局限，以及主機商責任邊界那句話。
• Cloudflare 官方文件：WAF Managed Rules——Free 方案僅能使用 Free Managed Ruleset，Cloudflare Managed Ruleset 與 OWASP Core Ruleset 需 Pro 以上。
• Cloudflare 官方文件：Custom rules——各方案自訂規則配額 5／20／100／1,000 與 regex 僅 Business 以上。
• Cloudflare 官方文件：Rate limiting rules——各方案速率限制規則數 1／2／5／100 與 Free 方案僅支援以 IP 計數。
• Cloudflare 官方文件：WAF get started——WAF attack score 僅 Business 與 Enterprise 可用的原文敘述。
• Cloudflare 官方文件：Protect your origin server——隱藏來源 IP、稽核 DNS-only 記錄、封鎖非 Cloudflare IP 流量的官方建議。

免責聲明：本文整理自公開的法規條文、政府公報、廠商官方文件與公開合約條款，內容為個人研究與實務經驗的整理，不構成法律意見，也不能取代律師針對個案的評估。個人資料保護法及其子法的施行狀態可能隨行政院與主管機關的公告而改變，本文所述狀態以查核日 2026 年 8 月 6 日為準；文中引用的主機商條款為當日公開版本，業者保留隨時修改的權利。涉及具體爭議、行政裁罰或損害賠償時，請諮詢專業法律人員。