[安全需求] 003 SSDLC 安全需求實戰：台灣法規遵循指南：個資法、資安法與產業規範
你的程式碼寫得再安全，如果不符合法規，公司照樣被罰。
法規遵循不是法務的事，而是每一行程式碼的責任。
一、為什麼開發者要懂法規？因為「不知道」不能當藉口
想像你蓋了一棟房子，結構堅固、防盜完善、消防設備齊全。但有一天政府來稽查，發現你的建築執照過期、消防通道寬度不合規、而且沒有無障礙設施——罰單直接開下去，不管你的房子蓋得多漂亮。
軟體開發也是一樣。你可以用 Argon2 加密密碼、做好 CSRF 防護、甚至通過滲透測試零漏洞，但如果你在蒐集使用者資料時沒有取得同意、沒有在隱私政策中告知使用目的、或者在資安事件發生後沒有依法通報——這些都是違法的。
在台灣，跟軟體開發最相關的兩部法律是個人資料保護法（個資法）和資通安全管理法（資安法）。此外，如果你的公司屬於特定產業（如金融業、醫療業），還有更嚴格的產業規範要遵守。
在 SSDLC 的七大階段中，法規遵循屬於第一階段：安全需求定義。因為如果你在需求階段就搞清楚「法律要求我做什麼」，後面的設計、實作、測試就能對齊法規要求，而不是上線後才手忙腳亂地補。
飛飛觀點：
很多開發者覺得法規是法務的事，跟寫程式無關。但事實上，法規裡的每一條要求，最終都會變成一行行的程式碼。你越早理解法規，就越能寫出合規又安全的系統。
二、台灣法規全景圖：開發者該認識的三個層次
在深入個別法規之前，先讓我們用一張全景圖理解台灣的資安與個資法規架構：
| 層次 | 法規 / 規範 | 適用對象 | 主管機關 |
|---|---|---|---|
| 通用法規 | 個人資料保護法（個資法） | 所有蒐集、處理、利用個資的組織 | 個人資料保護委員會（籌備中） |
| 通用法規 | 資通安全管理法（資安法） | 公務機關 + 特定非公務機關 | 數位發展部 |
| 產業規範 | 金融資安行動方案 | 金融業（銀行、保險、證券等） | 金融監督管理委員會（金管會） |
| 產業規範 | 上市櫃公司資通安全管控指引 | 上市櫃公司 | 金管會 / 證交所 / 櫃買中心 |
| 產業規範 | 醫療機構電子病歷製作及管理辦法 | 醫療機構 | 衛生福利部 |
| 國際接軌 | GDPR（歐盟一般資料保護規則） | 處理歐盟居民資料的組織 | 歐盟資料保護機構 |
對開發者來說，個資法和資安法是基本功，產業規範則視你所在的公司而定。
三、個人資料保護法：開發者必知的核心要求
3.1 個資法跟開發者有什麼關係？
個資法規範的是「個人資料的蒐集、處理及利用」。只要你的系統會碰到使用者的個資，你就在個資法的管轄範圍內。
什麼是「個人資料」？根據個資法第 2 條，只要能直接或間接識別特定個人的資料都算，包括但不限於：
| 類別 | 範例 | 開發者常碰到的場景 |
|---|---|---|
| 基本識別資訊 | 姓名、身分證字號、出生年月日 | 會員註冊表單 |
| 聯絡資訊 | Email、手機號碼、地址 | 寄送通知、行銷信件 |
| 財務資訊 | 信用卡號、銀行帳號 | 線上支付功能 |
| 特種個資 | 醫療紀錄、犯罪前科、性生活 | 健康管理 App、背景查核系統 |
| 數位足跡 | IP 位址、Cookie、裝置 ID | 網站分析、廣告追蹤 |
3.2 個資法對開發者的八大要求
以下是從個資法中提煉出，跟軟體開發直接相關的八大要求：
要求一：蒐集前要告知並取得同意
你不能偷偷蒐集使用者資料。系統必須在蒐集前明確告知：蒐集的目的、資料類別、使用期間、對象、地區、方式，以及當事人的權利（如查詢、更正、刪除等）。
// ❌ 不好的做法：註冊時沒有任何告知，直接存資料
app.post('/register', (req, res) => {
db.users.insert(req.body); // 直接存，沒告知
});
// ✅ 好的做法：註冊前展示隱私聲明，取得明確同意
app.post('/register', (req, res) => {
if (!req.body.privacyConsent) {
return res.status(400).json({
error: '請先同意隱私權政策'
});
}
// 記錄同意時間與版本
const user = {
...req.body,
consentTimestamp: new Date().toISOString(),
consentVersion: 'privacy-policy-v2.1',
consentIP: req.ip
};
db.users.insert(user);
});要求二：不能超出蒐集目的使用
你蒐集 Email 是為了寄訂單通知，就不能拿來發行銷信——除非使用者另外同意。
// ❌ 不好的做法：用訂單通知的 Email 名單直接發促銷
await sendEmail(user.email, '限時優惠！全館 5 折');
// ✅ 好的做法：檢查使用者是否有同意行銷用途
if (user.marketingConsent) {
await sendEmail(user.email, '限時優惠！全館 5 折');
}要求三：當事人有權查詢、更正、刪除自己的資料
系統必須提供機制讓使用者可以查詢自己被蒐集了哪些資料、要求更正錯誤、甚至要求刪除。
// API 設計應包含這些端點
// GET /api/me/data → 查詢個人資料
// PATCH /api/me/data → 更正個人資料
// DELETE /api/me/data → 刪除個人資料（帳號刪除）
// GET /api/me/data/export → 匯出個人資料副本要求四：要制定「個人資料檔案安全維護計畫」
非公務機關（也就是一般公司）必須制定安全維護計畫，包含：管理措施、技術措施、認知宣導訓練，以及事故應變機制。
要求五：資安事件發生後要通知當事人
如果發生個資外洩，你必須在查明後通知當事人，告知外洩的事實、個資類別、應變措施等。
要求六：特種個資需要特別處理
醫療、基因、性生活、健康檢查、犯罪前科等「特種個資」，原則上不得蒐集、處理或利用，除非符合法定例外情形（如法律明文規定、當事人書面同意等）。
要求七：委外處理個資要監督受託者
如果你把資料處理委外（例如用第三方雲端服務、委託行銷公司發信），委託方仍然要負監督責任。
要求八：跨境傳輸有限制
個資傳輸到台灣境外時，需要確保接收方的個資保護水準足夠。
3.3 2025-2026 年個資法重大修正：開發者需注意的變化
2025 年 11 月 11 日，總統公布了個資法修正案（施行日期由行政院另定）。這次修正是個資法自施行以來最大規模的修正，由個資會籌備處採「兩階段」推動修法。以下是對開發者的重要影響：
| 修正重點 | 對開發者的影響 |
|---|---|
| 成立「個人資料保護委員會」作為獨立監管機關 | 未來有專責機關統一監管，稽查力度預期增強 |
| 明訂個資事故通報義務 | 發生個資外洩時，須向個資會通報，系統必須有事故偵測與通報機制 |
| 公務機關須設置「個人資料保護長」 | 政府專案開發需配合資料保護長的要求（目前尚未要求民間企業設置） |
| 事故發生後須即時通知當事人 | 企業不得以「尚未查明」為由遲誤通知，系統需預備當事人通知機制 |
| 個資會可逕行處罰，毋庸先令限期改正 | 違規風險大幅提高，不再有「先被警告再改」的緩衝空間 |
目前進度（截至 2026 年 2 月）：
值得注意的是，個資保護委員會的正式成立，仍須等待「個人資料保護委員會組織法」完成立法程序。目前組織法草案已在立法院「司法及法制委員會」初審完竣，尚待院會完成三讀。行政院將配合組織法的立法進度，再行指定個資法新法的施行日期。
此外，個資會籌備處已在 2026 年初預告多項子法草案，包括「個人資料檔案安全維護管理辦法」、事故通報相關辦法、檢查非公務機關落實個資法情形作業辦法等，正在公開徵求意見階段。這些子法一旦定案，將直接影響你的系統需要符合的具體技術規格。
飛飛觀點：
個資保護委員會的成立，代表台灣的個資保護即將進入新時代。雖然組織法尚在立法程序中，但子法草案已經在預告了——這代表一切都在加速推進。對開發者來說，現在就把合規做好，遠比之後被罰再來改要划算得多。
四、資通安全管理法：你的公司在管轄範圍嗎？
4.1 資安法是什麼？
如果說個資法保護的是「個人的資料」，那資安法保護的就是「國家的資通安全」。資安法在 2019 年正式施行，2025 年 9 月 24 日公布了施行以來首次重大修正（施行日期由行政院另定）。
資安法管的是兩類對象：
第一類：公務機關
各級政府機關。如果你的公司承接政府專案，雖然你不是公務機關，但你的系統需要符合機關的資安要求。
第二類：特定非公務機關
這包括三種：
| 特定非公務機關類型 | 範例 |
|---|---|
| 關鍵基礎設施提供者 | 電力、電信、交通、金融、醫療等關鍵服務的營運者 |
| 公營事業 | 台電、中華郵政等 |
| 特定財團法人或政府捐助的機構 | 政府持有一定比例的財團法人 |
4.2 資安法對開發者的重點要求
要求一：建立資通安全維護計畫
受規範的機關與組織必須制定資安維護計畫，包含資通系統的安全管理、防護、稽核及事件應變等。
要求二：事件通報義務
發生資安事件時，必須在規定時間內向主管機關通報。
| 事件等級 | 通報時限 | 範例 |
|---|---|---|
| 第一級（輕微） | 72 小時內 | 非核心系統異常 |
| 第二級（一般） | 36 小時內 | 核心系統效能降低 |
| 第三級（重大） | 24 小時內 | 核心系統服務中斷 |
| 第四級（嚴重） | 1 小時內 | 機密資料大量外洩 |
開發者的責任：系統必須有完善的日誌記錄、異常偵測與告警機制，才能在事件發生時快速判斷等級並通報。
要求三：資通系統分級與防護基準
依據系統處理資料的機密性、完整性及可用性，系統被分為不同安全等級，每個等級有對應的防護基準。
資通系統防護基準等級：
普級 → 基本防護（輸入驗證、存取控制、日誌記錄）
中級 → 強化防護（加密傳輸、弱點掃描、定期稽核）
高級 → 最高防護（滲透測試、多因素認證、即時監控）要求四：委外管理
修正後的資安法明確要求，機關委外辦理資通安全業務時，應與受託者簽訂書面契約，載明權利義務及違約責任。如果你是政府專案的受託廠商，這一點格外重要。
要求五：禁止使用危害國家資通安全產品
2025 年修正將「禁用危害國安產品」提升至法律位階。公務機關不得使用被認定為危害國家資通安全的產品（如特定國家製造的設備或軟體）。
4.3 2025-2026 年資安法修正重點
資安法自 2019 年施行以來，本次（2025 年 8 月 29 日三讀、9 月 24 日公布）是首次重大修正。資安署將在公布後六個月內完成 8 項子法修訂，預計 2026 年上半年與母法同步施行。
| 修正重點 | 說明 |
|---|---|
| 主管機關變更 | 由行政院改為數位發展部，資安業務由資安署執行 |
| 擴大稽核範圍 | 總統府及五院均納入稽核範圍 |
| 禁用危害國安產品 | 公務機關不得下載、安裝或使用危害國家資通安全產品（提升至法律位階） |
| 特定非公務機關須設資安長與專職人員 | 比照公務機關要求，確保資安防護量能 |
| 提高罰則 | 未通報資安事件罰鍰上限提高至 NT$1,000 萬；未改正罰鍰上限提高至 NT$500 萬 |
| 強化稽查權限 | 主管機關可要求到場說明、提出第三方報告或派員檢查 |
| 委外管理法制化 | 委外辦理資安業務須簽訂書面契約，載明權利義務及違約責任 |
| 資安人員適任性查核 | 專職資安人員須進行適任性查核，未通過者不得處理涉及國家機密之業務 |
| 資安演練 | 明確要求機關配合數位發展部辦理資安演練 |
飛飛觀點：
即使你的公司不是資安法的直接管轄對象，但如果你承接政府專案、為關鍵基礎設施提供軟體服務，或者是上市櫃公司的供應商，資安法的要求都會間接影響到你。了解它，是保護自己也保護客戶。
五、產業規範：金融業與上市櫃公司的特別要求
除了通用的個資法和資安法，特定產業還有更嚴格的要求。以下是兩個對軟體開發影響最大的產業規範：
5.1 金融業：金融資安行動方案
金管會在 2020 年發布「金融資安行動方案」，2022 年推出 2.0 版，對金融機構的資安防護提出全面要求。
對開發者的關鍵要求：
| 要求 | 開發實務 |
|---|---|
| 核心系統上線前須做安全測試 | 導入 SAST、DAST、滲透測試 |
| 定期弱點掃描與修補 | 建立持續性的弱點管理流程 |
| 電子交易安全 | 實作多因素認證、交易簽章、防MITM |
| 資安事件通報（30 分鐘 ～ 24 小時） | 完善的日誌與即時告警機制 |
| 導入 ISO 27001 等國際標準 | 系統開發需符合 ISMS 要求 |
5.2 上市櫃公司：資通安全管控指引
金管會要求所有上市櫃公司依照規模分三級，逐步設置資安長、資安專責單位與人員：
| 級別 | 條件 | 要求 |
|---|---|---|
| 第一級 | 資本額 ≥ NT$100 億或台灣 50 成分股 | 資安長 + 資安專責單位 + 主管 + ≥ 2 名專責人員 |
| 第二級 | 其餘未連續虧損的上市櫃公司 | 資安專責主管 + ≥ 1 名專責人員 |
| 第三級 | 連續虧損或每股淨值低於面額 | 鼓勵設置 ≥ 1 名資安專責人員 |
資通安全管控指引同時對開發面提出要求：
✅ 系統開發需求規格須納入資安要求
✅ 用戶輸入輸出須有檢查過濾機制
✅ 上線前須執行原始碼掃描
✅ 定期辦理弱點掃描與滲透測試
✅ 委外開發須於合約載明資安要求與稽核權六、實戰案例：台灣電商平台的法規遵循需求
讓我們用一個完整的案例，把前面的法規知識串起來。
場景
你的團隊正在為一家台灣電商平台開發新版會員系統。這個系統會處理：會員註冊、登入、訂單管理、信用卡支付、行銷推播、退貨退款。公司是上市公司（第二級）。
法規遵循需求分析
Step 1：盤點會碰到的個資
| 資料類別 | 具體內容 | 蒐集目的 | 法規依據 |
|---|---|---|---|
| 基本身分 | 姓名、Email、手機 | 會員管理、訂單通知 | 個資法 §19 |
| 財務資料 | 信用卡號、銀行帳號 | 支付處理 | 個資法 §19 + PCI DSS |
| 交易紀錄 | 訂單內容、金額、時間 | 訂單管理、退貨退款 | 個資法 §19 |
| 行銷相關 | 瀏覽紀錄、偏好標籤 | 個人化推薦 | 個資法 §19（需另取同意） |
| 日誌資料 | IP 位址、裝置資訊 | 資安監控、異常偵測 | 資安法 + 個資法 |
Step 2：轉化為安全需求規格
## 會員系統安全需求規格（法規遵循）
### 1. 個資蒐集告知與同意（個資法 §8）
- 註冊頁面須顯示隱私權政策全文
- 使用者須勾選同意後才能完成註冊
- 系統記錄同意時間、IP、政策版本
- 行銷用途須獨立取得同意（不得與服務同意綁定）
### 2. 當事人權利行使機制（個資法 §3）
- 提供「個人資料查詢」功能
- 提供「個人資料更正」功能
- 提供「帳號刪除」功能（含關聯資料清除）
- 提供「個人資料匯出」功能
- 處理期限：收到請求後 15 日內回覆
### 3. 資料安全保護（個資法 §27 + 資安管控指引）
- 信用卡號以 AES-256 加密存儲
- 密碼以 Argon2id 雜湊後存儲
- 所有 API 傳輸使用 TLS 1.2 以上
- 信用卡顯示時遮蔽為 **** **** **** 1234
### 4. 日誌與稽核（資安法 + 管控指引）
- 記錄所有登入、權限變更、資料存取行為
- 日誌中不得包含完整信用卡號或密碼
- 日誌保存至少 6 個月
- 異常行為即時告警
### 5. 資安事件通報準備（資安法 + 個資法）
- 建立資安事件分級與通報流程
- 系統具備事件偵測與告警能力
- 預備當事人通知機制（Email + 站內信）Step 3：轉化為安全驗收標準
# SAC-LC-01：個資蒐集同意驗證
Scenario: 未同意隱私政策不得完成註冊
Given 使用者在註冊頁面填寫完資料
When 使用者未勾選「同意隱私權政策」就點擊註冊
Then 系統應顯示錯誤訊息「請先同意隱私權政策」
And 不得將任何資料寫入資料庫
# SAC-LC-02：行銷同意獨立取得
Scenario: 行銷同意與服務同意分離
Given 使用者在註冊頁面
When 使用者同意服務條款但未勾選行銷同意
Then 使用者可以成功完成註冊
And 資料庫中 marketing_consent 欄位為 false
And 系統不得對該使用者發送行銷訊息
# SAC-LC-03：當事人資料刪除權
Scenario: 使用者要求刪除帳號
Given 使用者已登入並進入帳號管理頁面
When 使用者點擊「刪除帳號」並確認
Then 系統應在 15 個工作日內完成以下操作：
- 刪除個人識別資訊（姓名、Email、手機）
- 交易紀錄去識別化（保留帳務記錄但移除個資）
- 撤銷所有有效的 JWT 與 Session
- 發送確認信至使用者 Email
# SAC-LC-04：信用卡資料保護
Scenario: 信用卡號不得以明碼存儲
Given 系統資料庫中存有信用卡資訊
When 直接查詢資料庫的信用卡欄位
Then 應只能看到加密後的密文
And API 回傳的信用卡資訊必須遮蔽為 **** **** **** 末四碼
# SAC-LC-05：日誌不得記錄敏感資料
Scenario: 日誌中不包含信用卡號與密碼
Given 使用者進行登入或支付操作
When 系統記錄操作日誌
Then 日誌中不得包含完整信用卡號
And 日誌中不得包含使用者密碼（含雜湊值）
And 日誌中手機號碼須遮蔽為 09XX-XXX-567七、法規遵循 Checklist：開發者可以直接用的檢核清單
以下是一份可以直接用於專案的法規遵循檢核清單：
個資法遵循 Checklist
## 蒐集階段
- [ ] 隱私權政策已撰寫並放置於系統可見位置
- [ ] 註冊 / 蒐集流程中有明確的告知與同意機制
- [ ] 行銷用途的同意與服務同意分開取得
- [ ] 同意紀錄（時間、版本、IP）已儲存
## 處理與利用階段
- [ ] 個資使用未超出告知的蒐集目的
- [ ] 特種個資有額外的保護與同意機制
- [ ] 資料存取有權限控制（最小權限原則）
- [ ] 敏感資料已加密存儲
## 當事人權利
- [ ] 提供個資查詢功能
- [ ] 提供個資更正功能
- [ ] 提供帳號 / 個資刪除功能
- [ ] 提供個資匯出功能
- [ ] 權利行使的回覆時限在 15 日內
## 安全維護
- [ ] 已制定個人資料檔案安全維護計畫
- [ ] 傳輸使用 TLS 1.2+
- [ ] 密碼以安全雜湊演算法存儲
- [ ] 有完善的存取日誌機制
- [ ] 日誌中未記錄敏感個資明碼
## 事件應變
- [ ] 有個資外洩通知流程
- [ ] 有事件分級與通報機制
- [ ] 定期演練事件應變流程資安法遵循 Checklist（適用於承接公務機關專案或特定非公務機關）
## 系統開發階段
- [ ] 開發需求規格已納入資安要求
- [ ] 使用者輸入已做驗證與過濾
- [ ] 上線前已執行原始碼掃描（SAST）
- [ ] 上線前已執行弱點掃描（DAST）
- [ ] 未使用被列為「危害國安」的產品或套件
## 系統運維階段
- [ ] 已建立資安事件分級與通報流程
- [ ] 日誌保存符合規定期限
- [ ] 定期辦理弱點掃描與修補
- [ ] 委外廠商合約載明資安要求
## 人員與組織
- [ ] 已設置資安專責人員（依級別）
- [ ] 資安人員有定期教育訓練
- [ ] 全員完成資安意識宣導八、團隊落地建議：讓法規遵循變成開發日常
建議一：在 Spec Review 中加入「法規檢查點」
如果你已經在做 SDD（規格驅動開發），在 spec.md 的模板中加入一個「法規遵循」區塊：
## 法規遵循（Legal Compliance）
### 涉及的個資類別
- [ ] 基本識別資訊
- [ ] 聯絡資訊
- [ ] 財務資訊
- [ ] 特種個資
- [ ] 其他：___
### 個資法要求
- [ ] 已確認蒐集目的與告知方式
- [ ] 已確認同意取得機制
- [ ] 已確認當事人權利行使機制
### 產業規範
- [ ] 不適用
- [ ] 金融業規範
- [ ] 上市櫃資安管控指引
- [ ] 其他：___建議二：建立「法規需求對照表」
每個專案開始時，花 30 分鐘做一份法規需求對照表，把法規要求對應到具體的技術實作：
| 法規要求 | 技術實作 | 負責人 | 完成狀態 |
|---|---|---|---|
| 個資法 §8 告知義務 | 隱私政策頁面 + 同意 Checkbox | 前端工程師 | ⬜ |
| 個資法 §27 安全維護 | AES-256 加密 + Argon2 雜湊 | 後端工程師 | ⬜ |
| 資安管控指引 – 原始碼掃描 | CI/CD 整合 SonarQube | DevOps | ⬜ |
建議三：把法規測試納入 CI/CD
某些法規要求可以自動化驗證：
// 範例：自動化測試確認 API 回應不洩漏敏感資料
describe('法規遵循 - 個資保護', () => {
it('API 回應中信用卡號應被遮蔽', async () => {
const res = await request(app)
.get('/api/me/payment-methods')
.set('Authorization', <code class="kb-btn">Bearer ${token}</code>);
res.body.cards.forEach(card => {
// 信用卡號應被遮蔽，只顯示末四碼
expect(card.number).toMatch(/^\*{4}\s\*{4}\s\*{4}\s\d{4}$/);
});
});
it('日誌中不應包含密碼', async () => {
await request(app)
.post('/api/auth/login')
.send({ email: 'test@test.com', password: 'MyP@ssw0rd123' });
const logs = await getRecentLogs();
logs.forEach(log => {
expect(log.message).not.toContain('MyP@ssw0rd123');
});
});
});建議四：每季做一次法規更新同步
台灣的資安與個資法規正在快速演進（2025 年就有個資法和資安法的重大修正）。建議每季花一個小時，掃一下法規動態，確認你的系統是否需要調整。
九、常見問題 FAQ
Q1：我們是小公司，個資法也管得到嗎？
A：是的。個資法適用於所有蒐集、處理、利用個人資料的組織，不論規模大小。只要你的系統有使用者註冊、存了使用者的 Email 或手機號碼，就在管轄範圍內。差別在於，個資保護委員會未來可能會依組織規模制定不同程度的管理要求。
Q2：我們不是政府單位也不是關鍵基礎設施，資安法跟我無關？
A：直接管轄可能無關，但如果你承接政府專案、是上市櫃公司、或者你的客戶是受管轄的機關，資安法的要求會間接影響你。而且，上市櫃公司的「資通安全管控指引」對所有上市櫃公司都有約束力。
Q3：個資法和 GDPR 有什麼差異？如果同時要遵守兩者怎麼辦？
A：主要差異在於：GDPR 有更明確的「被遺忘權」與「資料可攜權」、更嚴格的跨境傳輸規定、以及更高的罰鍰上限（最高全球營業額 4%）。如果你的系統同時處理台灣與歐盟使用者的資料，建議以較嚴格的 GDPR 為基準設計，這樣同時能滿足個資法的要求。
Q4：違反個資法最嚴重會怎樣？
A：民事方面，依據個資法第 28 條，同一事件被害人的損害賠償總額最高 NT$2 億元（所涉利益超過 2 億元者，以該所涉利益為限），且支持團體訴訟。刑事方面，意圖營利的違法行為最重可處 5 年以下有期徒刑，併科 NT$100 萬以下罰金，且為非告訴乃論。2025 年修正後新增了個資事故通報義務，未依規定通報個資會將直接面臨行政裁罰，且個資會可毋庸先令限期改正即逕行處罰——這代表不再有「被警告一次再改」的緩衝空間。
📌 法條參考：個資法第 28 條（第四章 損害賠償及團體訴訟）
公務機關違反本法規定，致個人資料遭不法蒐集、處理、利用或其他侵害當事人權利者，負損害賠償責任。但損害因天災、事變或其他不可抗力所致者，不在此限。
被害人雖非財產上之損害，亦得請求賠償相當之金額；其名譽被侵害者，並得請求為回復名譽之適當處分。
依前二項情形，如被害人不易或不能證明其實際損害額時，得請求法院依侵害情節，以每人每一事件新臺幣五百元以上二萬元以下計算。
對於同一原因事實造成多數當事人權利受侵害之事件，經當事人請求損害賠償者，其合計最高總額以新臺幣二億元為限。但因該原因事實所涉利益超過新臺幣二億元者，以該所涉利益為限。
同一原因事實造成之損害總額逾前項金額時，被害人所受賠償金額，不受第三項所定每人每一事件最低賠償金額新臺幣五百元之限制。
第二項請求權，不得讓與或繼承。但以金額賠償之請求權已依契約承諾或已起訴者，不在此限。
十、結語：法規不是枷鎖，是信任的基石
回到 SSDLC 的核心理念——安全不是恐懼，而是創造的基礎。法規遵循也是一樣。
個資法不是來找你麻煩的，它是告訴你：使用者信任你保管他們的資料，你有責任好好保護。資安法也不是製造官僚，它是在說：當整個社會越來越依賴數位系統，你的系統安全就是公共安全的一部分。
法規合規不需要一步到位。就像蓋房子要先拿到建照才能動工，你也可以：
- 先了解：花一個下午讀完這篇文章，搞清楚你的系統碰到哪些法規
- 再盤點：用 Checklist 檢查目前的合規狀態
- 逐步補齊：從風險最高的地方開始，一個一個修
當你的系統不只技術上安全，法規上也合規，你就在告訴使用者和客戶：「我值得你信賴。」
這份信任，是任何技術都買不到的競爭力。
延伸閱讀
台灣法規原文：
主管機關資源：
系列文章：
國際參考：