2026年8月6日
引言
電子簽名是一個廣義概念：透過電子操作表明某人有意簽署一份記錄。數碼簽名則是一種具體的技術機制。它利用密碼學，並在許多企業簽署流程中結合數碼證書，把簽署人或簽署憑證與文件關聯起來，同時讓後續改動能夠被發現。簡而言之，數碼簽名是形成電子簽署證據的一種特定方式，並非所有電子簽名都會使用數碼簽名。
這一區別很重要，但不能據此認定某一種方式普遍“更好”。在一種流程中，是否適合採用輸入姓名並配合身分認證、同意步驟、路由和詳細審計記錄的方式，取決於具體要求；在另一種流程中，能夠透過密碼學驗證來檢查的證書型數碼簽名可能更合適。真正需要問的不是哪個名稱聽起來更有分量，而是簽署完成後，覆核人員必須驗證甚麼、能使用哪些系統，以及覆核時還能夠取得哪些證據。
本文只用於知識說明，不構成法律判斷。文件類型、司法管轄區、行業規則、交易對方要求、保證目標和留存政策都可能影響簽署方式的選擇。團隊在統一採用某條路徑前，應先確認這些要求。
先問清楚要驗證甚麼，不要先看名稱
第一步是寫明接收方覆核人員必須作出甚麼判斷。一個簽署流程通常需要回答以下五類問題中的若干項：
- 是否存在能夠可靠記錄簽署意圖的操作？ 覆核人員可能需要檢視已簽署記錄，以及同意、披露、欄位填寫或主動簽署操作的證據。
- 該操作歸屬於誰或甚麼憑證？ 歸屬判斷可能依靠郵件路由、存取碼、帳戶會話、身分驗證、證書主體、組織憑證，也可能同時使用多項控制措施。
- 這是否就是當時簽署的文件？ 流程需要在參與人的操作與最終文件之間建立可靠關聯。某些路徑還會提供密碼學完整性檢查，用於發現後續改動。
- 是否需要覆核證書資訊？ 如果必須採用證書型簽署，覆核人員可能需要使用能夠同時顯示證書資訊和簽名結果的工具。團隊應先界定覆核人員必須看見哪些內容。
- 哪些事件必須保持可覆核？ 僅有已簽署文件可能還不夠。時間戳、身分認證事件、路由歷史、完成狀態和異常情況可能需要隨文件一起移交，或繼續保存在受控系統中。
先從驗證任務出發，可以避免一種常見的採購錯誤：團隊根據功能名稱選定方式，最後才發現下游覆核人員無法解釋產生的證據。這樣做也能把經常混在一起的三個問題分開：簽署意圖、身分保證和文件完整性。
電子簽名和數碼簽名流程如何形成證據？
電子簽名流程可以組合多種證據來源。讀者看到的簽名可能是輸入的姓名、手繪標記、點擊操作或其他電子操作；與此同時，系統會記錄文件如何呈現、使用了哪條收件人路徑、進行了甚麼身分認證、各項操作在何時發生，以及最終產生了哪一份文件。證據價值來自整套流程，不只取決於簽名的外觀。
因此，看起來簡單的電子簽名也可能有充分的營運證據支援。覆核人員可以檢視參與人操作記錄、電郵或手機驗證、帳戶身分認證、文件識別碼、時間戳、完成記錄和審計記錄。具體組合應與交易風險和要求相匹配。
數碼簽名流程還會增加密碼學簽署操作。簡單來說，簽署軟件使用私鑰，根據文件產生一個值；驗證時則使用對應的公鑰檢查該值。在基於證書的企業流程中，數碼證書有助於把公鑰與某個人或組織關聯起來。數碼證書和密碼學簽署結果不能取代對周邊流程的檢查，但會增加一層機器可檢查的完整性與憑證證據。
美國國家標準與技術研究院數碼簽名項目說明了兩項核心保證：聲稱的簽署人是否簽署了相關資訊，以及資訊在產生簽名後是否被修改。這些是技術保證目標，不能直接推導出普遍的法律效力、身分核驗強度，也不能說明某種方式適用於所有文件。
證書型流程也會給覆核帶來額外工作。移交時，應讓覆核人員能夠看懂簽名結果、所選工具顯示的證書資訊，以及檢測到的簽署後改動。如果還需要作出超出這些項目的判斷，應在正式推行前記錄額外的判斷依據和覆核規則。
兩者在實際使用中的區別
電子簽名描述的是更廣泛的簽署概念，可以由流程記錄提供支援。數碼簽名描述的是範圍更窄的密碼學技術，可以增加文件完整性和憑證證據。數碼簽名可以成為電子簽名流程的一部分，而電子簽名流程不一定使用數碼簽名密碼學。
按驗證任務比較電子簽名與數碼簽名證據
下方的覆核人員、系統與證據驗證交接矩陣用於支援具體的營運決策。在確定預設方式前，應與未來的覆核人員共同填寫，而不能只讓發起人填寫。
這張矩陣特意不把“證據更多”等同於“證據更好”。如果接收方無法檢視簽名結果或證書顯示，這些內容在實際操作中就沒有用。反過來，即使原來的簽署體驗很順暢，只有發起人才能存取的審計記錄也會造成交接保障不足。證據必須以對方系統能夠評估的形式送到負責作出判斷的人手中。
根據覆核人員和系統能力選擇簽署方式
選擇簽署路徑時，應以簽署後的判斷任務為準。下面的順序有助於把討論落到具體事項上。
1. 明確依賴證據作出判斷的覆核人員
先確定誰會在流程完成後評估記錄：內部審批人員、合約管理員、安全團隊、外部審計人員、監管機構、法院、檔案負責人、客戶或其他交易對方。“業務部門”太含糊。不同覆核人員擁有的存取權限、信任設定、技術工具和證據要求並不相同。
2. 明確要得到甚麼驗證結論
寫清楚覆核人員最終必須得出甚麼結論。例如，確認預期收件人主動執行了簽署操作，檢查已簽署資訊之後是否被修改，檢視隨簽名呈現的證書資訊，或還原一次異常。不要用簽署方式的名稱代替驗證結果。
3. 盤點覆核人員可用的系統
確認覆核人員實際能夠使用哪些文件格式、簽名驗證工具、審計匯出文件、身分記錄和長期檔案。如果驗證必須依賴發起人帳戶、接收方沒有的專用檢視工具，或未寫入文件的人工協助，應在正式推行前記錄這項依賴。
4. 設計證據包
明確哪些內容需要與最終文件一起移交。根據簽署路徑，證據包可以包含最終文件、審計記錄、身分認證結果、工具顯示的證書資訊、簽名驗證結果和異常備註。為證據包設定穩定的識別碼，方便覆核人員確認每一項都屬於同一筆交易。
5. 規劃例外處理與記錄留存
團隊應事先決定：身分驗證失敗、無法產生簽名結果、文件報告改動，或覆核人員無法存取時，該如何處理。還要明確已簽署文件、審計記錄、驗證結果和適用的覆核規則需要保持可用多久。缺失的留存流程無法靠密碼學補救。
如果所需的保證主要來自簽署意圖、身分認證、路由和審計歷史，而且覆核人員能夠穩定取得這些記錄，日常電子簽名路徑可能適用。如果覆核人員需要密碼學修改檢查，或需要檢視與簽名關聯的證書資訊，證書型數碼簽名路徑可能帶來額外價值。這些只是決策模式，並非普遍規則。
在 Nota Sign 中測試一次驗證交接
確定政策前，先測試證據交接。Nota Sign 支援包含路由、追蹤、身分認證選項和審計記錄的電子簽名流程，以及能夠形成密碼學完整性和證書證據的證書型數碼簽名流程。具體可用性和適當設定可能取決於市場、信任服務設定、文件和流程。
選一份有代表性且已經獲准用於測試的文件，按照團隊考慮採用的路徑操作。應使用測試資料，不要使用敏感的正式環境資料。流程完成後，由發起人把已簽署文件和計劃中的證據包交給一位未參與設定的覆核人員。
請這位覆核人員在沒有發起人指導的情況下完成矩陣：
- 找到簽署意圖和簽署人歸屬的證據。
- 確認證據包與那一份最終文件準確關聯。
- 如果存在數碼簽名，使用覆核人員平時使用的工具檢查簽名結果、工具顯示的證書資訊，以及任何報告的文件改動。
- 記錄哪些內容結論明確、存在歧義、無法存取或依賴發起人。
- 如果長期覆核很重要，可在允許的軟件更新、檔案移交或有代表性的異常發生後重複測試。
只有當覆核人員使用已記錄的證據包、系統和政策就能得出所需結論，測試才算通過。如果結論依賴口頭說明、隱藏設定或發起人的臨時存取權限，應修改流程並重新進行交接測試。
在確定統一的簽署方式前，先在 Nota Sign 中完成一次獨立覆核交接測試。
