客製軟體專案交接要準備什麼
客製軟體上線之後，交接要寫明誰接手哪一項、程式庫和權限在哪、文件與操作手冊交到誰、訓練留下了什麼紀錄、殘餘缺陷列在哪張表，以及保固期內的修復和變更請求怎樣分開。切換手冊管的是上線當晚的順序；交接管的是上線之後誰持有系統、出了問題找誰。
交接和上線切換分開寫
切換手冊回答的是當晚先停哪一項、誰簽可否上線、什麼情況退回舊環境。交接表回答的是使用者已經在正式環境之後，日常由誰接、程式放在哪、文件在哪、還沒修完的缺陷誰跟。兩份可以互相指到版本，不要把切換步驟改寫成交接清單。上線當晚的順序，見 客製軟體上線切換怎麼做。
驗收標準寫的是什麼算完成，使用者驗收寫的是誰按清單把結果做出來。交接不重做這兩份。交接封面寫規格版本、正式環境啟用的日期，以及交接表自己的版本。範圍若在交接前還要改，另開變更請求，不在交接會議上把新畫面寫進殘餘缺陷表。變更怎樣留紀錄，見 客製軟體範圍變更怎麼管。交付仍走 客製軟件、網站與應用程式。
上線之後誰負責哪一件
交接表用名字寫四個角色：系統負責人、事故第一個接聽的人、可以改正式環境的人、對外找供應者時的聯絡人。一個名字可以兼兩欄，欄位仍分開。只寫「專案組」或「資訊部」，下一次故障就不知道該打給誰。人當天不在，表上預先寫代理人，不在群組裡臨時改口。
系統負責人對的是這套軟體上線之後的日常，不是切換當晚的簽核人。簽核人可以同時是系統負責人，兩欄仍各寫一次，並寫從哪一天起生效。供應者的聯絡方式寫姓名、管道和可聯絡的時段；合約裡的到場時限留在合約，不抄進這張表，也不改寫成表上的狀態。
帳戶管理人寫在交接表上
2026年10月21日閱讀的 NIST SP 800-53 Rev. 5 目錄頁把出版日期寫成 2020年9月（含截至 2020年12月10日的更新）。下列控制項正文依該出版物的最終版，DOI 為 10.6028/NIST.SP.800-53r5。AC-2「帳戶管理」要求：寫明系統允許和明文禁止的帳戶類型；指定帳戶管理人；寫明每位帳戶的授權使用者、群組與角色、以及存取授權（權限）；建立帳戶前由指定的人核准；依組織自己的規定建立、啟用、修改、停用和移除帳戶。通知時限由組織指定，控制項沒有給出小時數。
交接表因此寫：正式環境允許哪些帳戶、明文不允許共用帳戶還是允許、帳戶管理人是誰、誰核准新建。若仍用群組帳戶，AC-2 還要求在有人離開該群組時，更換共用或群組帳戶的鑑別資訊。交接當天把離開專案的人從清單移除，並寫上停用日期。憑證本身不寫進交接表，只寫憑證存放處的名稱和誰可以開。
管理員文件和每日操作手冊分開
SA-5「系統文件」要求取得或編寫管理員文件，說明系統、組件或服務的安全組態、安裝與操作，安全與私隱功能如何有效使用和維護，以及管理或特權功能在組態和使用上的已知弱點。同一控制項要求使用者文件說明使用者碰得到的安全與私隱功能、能使使用更安全並保護個人私隱的互動方式，以及使用者在維護系統安全與個人私隱上的責任。文件要分發給組織指定的人員或角色。文件無法取得時，要記錄曾經如何索取，並採取組織指定的行動。討論寫明，安全操作包括初次啟動，以及運作中斷之後恢復安全運作。
每日操作手冊是專案自己的文件：每天誰跑哪一項、失敗時先看哪一頁、正式環境怎樣啟動、中斷之後怎樣恢復業務。它和 SA-5 的安全文件分兩行放。兩行都寫存放路徑、版本和日期。路徑寫到資料夾和檔名。只寫「在群裡」，下一個值班的人找不到。討論裡點名需要文件的角色包括系統負責人、系統安全負責人和系統管理員；交接表的分發名單對上這些角色，再加上每日操作手冊的值班人。
訓練紀錄寫誰出席、教了什麼
業務訓練紀錄是專案自己的一頁：日期、出席姓名、教了哪幾項操作、誰在紀錄上簽名。沒有簽名的一頁，不當成已經教過。教材版本寫在同一頁，事後才知道當天教的是哪一版畫面。人缺席，另約時間補同一份教材，不在交接表上把缺席寫成已完成。
AT-3「角色為本訓練」要求對組織指定的角色，在授權其存取系統或資訊、或執行所指派職務之前，提供安全與私隱的角色訓練；系統變更而有需要時亦然。內容按組織指定的頻率和事件更新，並把內外部安全事件的教訓寫進訓練。AT-4「訓練紀錄」要求記錄並監督這些安全與私隱訓練活動，個人紀錄保留多久由組織指定。討論寫明，專門訓練的紀錄可以由個別主管保存。業務訓練的簽名頁不能代替 AT-4 的安全訓練紀錄，AT-4 的紀錄也不能代替「這個人看過正式環境的畫面」。兩頁都留，並在交接表上各列一行。
殘餘缺陷另列一張表
上線之後仍開放的缺陷，每項一行：現象、出現在哪一個畫面或哪一筆資料、誰發現、發現日期、使用者能否繼續工作、修復負責人。沒有修復負責人的一行，留在表上，並在交接封面寫明還有未指定負責人的項。不要把驗收時已經關閉的項再抄進來充數。
嚴重度沿用團隊已經在用的詞，不在交接會議上另起一套。使用者仍可工作的項，寫明暫時怎麼做，以及這句暫時做法寫在哪一頁操作手冊。暫時做法沒有寫進手冊，值班的人只會在聊天裡口傳。口傳的句子不寫進殘餘表的「暫時做法」欄。
保固期內的修復和變更請求分開
保固期的起迄寫合約上的日期，交接表只記這兩個日期和合約編號。天數、到場時限和金額留在合約裡。殘餘表上已經列明、而且偏離的是原先同意的結果，在保固期內按修復跟進。原先規格沒有的新願望，另開變更請求，不寫進殘餘表充當成未完成的缺陷。
CM-3「組態變更控制」要求先寫明哪些類型的變更受組態控制，再覆核並核准或否決，且明文考慮安全與私隱影響，把決定記錄下來，實作已核准的變更，並把紀錄保留一段由組織指定的時間。保固期內的修復若改到系統，而該類型已被列為受控變更，仍走這條紀錄，不因為合約寫了保固就跳過核准。殘餘表說明「要修什麼」；變更紀錄說明「誰核准這次改動」。兩張表用同一個缺陷編號互相指到。
交接表沒寫完，封面仍是原負責人
系統負責人、帳戶管理人、文件路徑、殘餘表、保固與變更的分界，這幾欄有一欄還空着，封面的聯絡人仍寫實施期間的負責人，交接日不填。空着的欄寫上名稱，補上之後才填交接日。代理人沒有名字，不把群組裡最後發言的人寫成接手的人。
時限、缺陷數和支援時數留在公司自己的規則和合約裡，並註明日期。AC-2、AT-4 和 CM-3 裡的時間都寫成由組織指定，沒有給客製專案一個天數。交接表寫完之前，用三件事看有沒有交出去：每個角色是否有名字、文件和程式庫是否有路徑、殘餘缺陷是否有負責人或被標成尚未指定。三件事都在表上，才把交接日寫進通知。