公部門專案的驗收，對照的是契約與需求書逐項列出的文件、數量與格式。維運也是同一種邏輯：機關要看的是查得到的證據，口頭保證不在驗收項目裡。
開發團隊在這個邏輯下能做的事有三件：報價前把需求書讀成清單，維運時讓檢查自己產出檔案，出事時把查到的與查不到的都寫進報告。安全測試的類型與分工，請先看弱點掃描與滲透測試的差異；磨人是開發與維運團隊，本文談的是測試之前與之後的交付與維運。
驗收看的是需求書上的文件名稱與數量
政府採購法第四章規範履約管理，第五章規範驗收與付款，是機關與廠商履約、驗收與付款的法律依據（政府採購法，2019）。驗收完成與不符項目補正的期限，以契約與現行條文為準。
政府採購法施行細則的第五章把驗收程序寫得更細：紙本驗收的適用情形、竣工通知與聯合查驗、初驗與正式驗收、驗收紀錄，以及達公告金額時的結算驗收證明書（政府採購法施行細則，2021）。施行細則與採購法是不同層級的法規，引用時要分別確認現行版本。
這些程序最後落在一張清單上：需求書列了哪些文件，各幾份，什麼格式。條目的粒度可以細到數量、單位與格式，例如「架構圖一式、PDF 格式」「影片一支、MP4 格式」。驗收時對照的就是這個字面。
還有一個反向的坑：做出真正可運作的系統，不代表文件義務就免了。報價前要先確認，客戶的硬性義務是一份文件，還是一個可運作的產品；屬於文件的項目，要獨立列項。
報價前先把需求書與查核條文逐字抄成清單
做法分兩步。第一步，報價前讀客戶對第三方負有的義務文件，以及其查核條文的原文，逐字抄下每一項的名稱、數量、單位與格式，抄成一張清單。逐字的意思是不改寫：需求書寫「資安維護記錄報告」，清單就寫「資安維護記錄報告」，不換成自己習慣的「資安報告」。
- 文件名稱：照需求書字面抄，不改寫。
- 數量與單位：一式、一支、一份，分開記。
- 格式：PDF、影片等檔案格式，或是連結，各自標明。
- 義務屬性：該項是文件，還是可運作的產品。
第二步，把這張清單和客戶的構想對照，用三個欄位：客戶構想有沒有寫、第三方文件有沒有要求、報價有沒有涵蓋。
| 客戶構想有寫 | 第三方文件有要求 | 報價有涵蓋 | 處理 |
|---|---|---|---|
| 有 | 有 | 有 | 照需求書的文件名稱與數量交付 |
| 沒有 | 有 | 沒有 | 補進報價，並獨立列項 |
| 沒有 | 沒有 | 沒有 | 移出範圍 |
三欄都沒有的功能，一律移出範圍。這張對照表是內部的工作表，不附在報價單裡。移出範圍不等於不能做：一個標案的實例是，需求書全文沒有出現開發團隊想走的某條技術路線，同一個模組卻明列了其餘項目作為合約義務，不是前期研究。因此這條路線的前期研究成果，必須用需求書上逐字存在的文件名稱交付，才過得了驗收。
依政府採購法、施行細則與資通安全法規的委外規定整理
資通安全法規對委外的要求落在契約與稽核
資通安全管理法第十條要求公務機關與指定的非公務機關，在委外建置、維運資通系統或提供資通服務時，選擇適當廠商、要求廠商維持有效的資安管理機制並加以監督，並以書面契約約定權利、義務與違約責任（資通安全管理法，2025）。對廠商而言，這條規定最先落在契約與需求書的條款上。選廠商時看哪些條件，可參考怎麼挑選軟體開發廠商。
施行細則第七條更具體：機關選任與監督受託者時，要考量人員配置、複委託、客製系統的安全測試、事件通報與契約終止時的資料處理等事項，並須定期稽核受託者，或於得知事件時查核（資通安全管理法施行細則，2026）。條文對事件通報寫「立即」，對稽核寫「定期」，沒有給具體天數，時限要看需求書與契約。對維運端的意思很直接：被稽核、被查核是預設會發生的事，證據要事先留好。其中安全測試的兩種常見做法有何不同，見弱點掃描與滲透測試的差異。
機關自己也分級。資通安全責任等級分級辦法將機關分為 A 至 E 五個責任等級，同時符合多級時取最高級，機關再依等級執行附表所列的應辦事項（資通安全責任等級分級辦法，2026）。應辦事項寫在附表，辦法的頁面沒有列出內容，所以承辦在提需求前，要先確認機關屬於哪一級，再對照該級的附表。資通安全署發布的措施（資通安全署，2026）說明，機關委外時應選擇具備適當經驗的廠商，並監督其資安作為；該頁面標示內容修訂中、將另行公布，各階段的細部要求目前只能先看契約與需求書。
維運的證據來自會自己產出檔案的唯讀腳本
需求書會把維運寫成可驗收的指標，並指定資安維護紀錄類的文件。需求書同時列有服務水準的指標，這類指標只能靠可重複產出的記錄來證明。開發團隊的做法是把要求落成腳本，讓檢查自己產出檔案：腳本跑過，就有一份帶時間的檔案留下，這份檔案就是憑證。維運服務見Polish+ 維運服務。
- 完整性每週，與上一週比對
- 日誌彙整每週，彙整近一週
- 系統月報每月 1 份
只畫來源記載週期的三項；磁碟用量警示依門檻觸發，還原演練另述於正文，均不畫入。位置僅示意頻率。
- 每週檔案完整性：對網站目錄（排除依賴套件與版控資料夾）計算 SHA-256，與上一週比對；有差異才留下差異檔，並只重算有變更的檔案。
- 每週日誌彙整：用日誌彙整工具，以高詳細度彙整近一週的日誌。
- 容量警示：磁碟用量超過 90% 就發出通知。
- 月報：逐月產出系統報告，已持續超過一年。
- 憑證更換：以文件歸檔。
這些腳本有一個共同的取捨：只用主機上既有的套件與執行環境內建的功能，不在正式主機上多裝東西。檢查本身不該成為新的變更。
還原演練另有兩支腳本。一支驗應用主機，檢查服務狀態、資料庫連線，以及上傳檔案的數量與大小。一支驗資料庫，檢查連線、資料表清單、逐表的精確筆數、資料與索引的大小、主鍵 id 的範圍。兩支都是唯讀，每一行輸出帶時間戳與 PASS、FAIL、INFO、WARN 標記，並同時寫成報告檔。正式站與備援各跑一次，兩份報告可以逐表對照筆數。本文只描述演練程序與輸出格式，不報告演練結果。
條文落地的缺口在繞過路徑
密碼政策是另一類典型。條文本身不難寫，難的是每一條登入路徑都套同一套規則。密碼規則常分批落實，例如新密碼不可與前三次相同、最短使用期限、不可與帳號相同、不可為鍵盤連續字元、三個月內需更換、最低長度等。容易補漏的是繞過路徑：一般登入先判斷是否為初始密碼或超過三個月未更新，第三方登入若沒有同步判斷，規則就留下缺口；同一條規則在後台與 API 也各要實作一次。
| 登入路徑 | 要對照的規則 |
|---|---|
| 一般登入 | 初始密碼的判斷，以及超過三個月未更新的判斷 |
| 第三方登入 | 與一般登入相同的初始密碼判斷 |
| 重設密碼 | 新密碼套用同一套強度與歷史規則 |
| 初始密碼 | 首次使用時的處理與一般登入一致 |
| 後台與 API | 兩處各自實作的規則同步修改 |
前端的提示文字與後端的判斷要同步，以後端為準。強度規則調整時，前後端各改一處，說明文字也要跟著改。磨人的做法是用檢核表逐條對應，而不是只改註冊頁。
配合主管機關的掃描與申覆
磨人參與過教育部專案，配合主管機關要求的掃描、修補中高風險、誤判申覆，並從設計標承接到工程標。專案範圍見教育部專案的案例。
這類配合的工作落在掃描之後：中高風險要修補，誤判要申覆。申覆需要可以對照的說明：哪個請求、哪個版本、哪一項設定；維運端留下的檔案，就是這些說明的材料。
事故報告先確立機制與時序，查不到的明列
事故報告的價值在於把機制與時序寫清楚。以虛擬主機停擺為例，事後蒐證分成四個階段，每階段一支腳本、一份報告。
第一階段確立機制：系統核心與既有行程仍在運作，但新程序一再建立失敗。第二與第三階段確立時序：元件依序停擺，從日誌服務、防護程式、排程到寄信，前後約六分鐘。第四階段專查最可疑元件的日誌，而且在查之前，先寫好兩種結果各怎麼處理。
- 確立機制核心與既有行程是否運作，哪一種系統呼叫失敗
- 確立時序各元件依序停擺的先後與時窗
- 專查最可疑元件的日誌查之前先寫好兩種結果的處理方式
- 日誌中有錯誤根因可指認附上錯誤內容與時間點
- 日誌中斷且沒有錯誤書面記載「已查閱，未見異常」與找到錯誤同樣有價值
- 資料不在主機內列為「只能由外部取得」防護軟體主控台、管理主控台、虛擬化平台
- 不論結果列出系統性風險寫進同一份報告
蒐證過程有兩個常見的陷阱。一是更正自己的判讀：若發現前一份報告對某項指標的倍數判讀有誤，下一份報告直接註明更正。二是時間格式：同一個目錄下，有的日誌用本地時間，有的用 UTC，依本地時間搜尋，就會漏掉故障的時窗。主機內查不到的來源有三類：防護軟體主控台、管理主控台、虛擬化平台的事件與效能，報告把這三類來源明列為「只能由外部取得」。
不論根因能否指認，報告都要列出系統性風險，例如服務存活告警、效能監控、日誌輪替，以及正式主機的變更管理。報告的價值不取決於是否找到根因。
這種寫法接近無究責的事後檢討：焦點放在促成事件的條件，不歸咎個人或團隊；怕受罰的人會傾向隱匿問題，所以事後報告是改善制度與流程的材料，不是懲罰（Lunney 與 Lueder，2017）。至於事故應變本身，NIST SP 800-61 第三版將事故應變納入組織的網路安全風險管理，涵蓋準備、偵測、回應與復原，並取代 2012 年的第二版（Nelson 等，2025）。開發團隊把系統性風險那一欄，歸在準備與偵測的缺口。
跨單位的資料如何整理成一份可檢查的總表，見跨部會共用一個活動的資料整理。
不適合的情況
履約標的完全沒有系統開發或維運時，本文的做法不適用：這些做法都建立在有系統要交付、要維護的前提上。
下一步要準備的資料
請準備以下資料，再與開發團隊聯絡，說明專案目前所處的階段。
- 需求說明書，含附件列出的文件清單
- 機關的資通安全責任等級
- 既有系統清單
- 上次資安檢測結果的摘要
