企業信息系統應用控制設計工作程序

曲傳祥

摘要

隨著企業信息化的深入和與業務深度融合，信息系統風險逐漸轉化成了業務風險和企業的經營風險，對企業的經營活動有重大影響。也就要求企業有適當的控制手段，降低信息化所帶來的風險，這就需要信息系統應用控制。信息系統應用控制可以提高企業管理水平，減少人為操縱因素；增強信息系統的安全性、可靠性和合理性以及相關信息的保密性、完整性和可用性。

【關鍵詞】企業信息系統 應用控制 設計

信息系統應用控制（Application Controls）包括企業信息系統中的程序化步驟以及用以控制不同種類處理的相關的手工操作程序。這些控制結合一起可以保證信息系統的安全性、完整性、準確性和有效性。結合企業信息系統建設與控制設計的工作實踐，信息系統應用控制設計工作程序主要包括以下五個環節：

1系統功能調研

系統功能調研的目的是為了確認應用系統是否納入應用控制設計范圍。在調研過程中，要從信息系統需求分析報告出發，根據原則和標準將信息系統劃分為財務關聯信息系統和非財務關聯信息系統，信息系統應用控制的重點就在財務關聯信息系統。以下前三項條件全部滿足者為重要關聯信息系統，若三項條件不全部滿足，則考慮與外圍系統的接口情況。

1.1業務重要性判斷

按照企業內部管控規范，并結合與財務的關聯程度，在各業務領域建立的信息系統開展業務重要性認定。

1.2對財務數據影響程度的判斷

對財務數據的影響根據會計科目和財務報告所披露的內容進行判斷，分為直接影響和間接影響。直接影響為該系統直接對會計科目產生影響，間接影響為該系統的數據會間接對會計科目產生影響

1.3對系統依賴程度的判斷

判斷信息系統是否涉及復雜計算、檢查及處理過程。在信息系統同時符合以下標準和條件的屬于信息系統復雜的計算和處理過程，且無法全部依賴人工操作：

（1）信息系統涉及多個崗位及人員，需多崗位協同操作才能完成一項業務的處理；

（2）信息系統本身含有復雜的計算公式，最終輸出結果依賴固化在信息系統中的公式計算獲得，如依靠人工計算，則無法應付日常業務操作，且結果不準確的風險非常高。

1.4考慮與已有外圍系統接口情況

在判斷信息系統是否為財務關聯系統時，盡管有部分系統不完全滿足上述三條標準，但還應考慮與外圍系統接口的影響。信息系統集成度的提高，該條判斷標準將會越來越受到關注。

2差異分析

通過分析、討論，比對分析系統設計（藍圖）和原企業業務流程圖業務處理范圍、控制要求等，確定控制設計的流程范圍、完善系統藍圖控制設計，最終給出系統設計（藍圖）與業務流程對照表、差異分析報告等。對原有業務流程和系統系統設計（藍圖）進行對比，對比的內容包括：處理業務環節是否一致、對財務數據影響（科目）是否一致、業務流程負責部門是否相同。

（1）根據信息系統需求分析說明書或項目設計說明書，逐級建立系統設計（藍圖）與己有業務流程的對應關系。

（2）在己建立系統業務流程與企業業務流程對照關系的基礎上，對系統業務流程設計的合理性進行審閱，并出具審閱調整意見。考慮因素包括系統流程信息是否完整、要環節是否缺失、實施證據是否規范完整、系統可否實現審批環節、復核環節、復雜計算環節、指標控制、權限控制環節、相關業務關聯環節、權限控制環節等的自動化。

（3）根據系統流程設計及功能設計，完善現有業務流程，將系統設計（藍圖）以業務對照關系為依據融入本單位的業務流程中，從而形成一套完整的適用于信息系統上線單位的業務流程。

3風險分析

風險分析主要從信息處理流程角度進行分析，并將應用控制層面信息系統相關風險分為四類：

3.1輸入環節

未有嚴格的系統錄入控制、數據源頭、接口數據控制，可能導致進入系統中的數據不準確和不完整。包括錄入錯誤、重復錄入、漏記、網絡或系統故障導致數據傳輸失敗（包括未傳輸、傳輸數據錯誤、重復傳輸）、系統間對照關系維護錯誤導致數據傳輸失敗等情況，導致相關業務數據、財務數據不完整不準確。

3.2處理環節

信息系統處理不正確，例如匯總、過濾、排序、應計、分攤、自動核對、標準應用等處理計算錯誤，可能導致企業業務不能正常運轉，對企業造成重大損失。

處理環節比較復雜，按照風險與信息系統及業務的關聯度不同可將風險再細分為信息系統自身引入的風險、信息系統上線導致業務流程變化而引入的新風險或導致原有風險發生變化，以及原有業務未發生變化的風險等三類。

3.3輸出環節

信息輸出的內容、方式、時間、頻度、接收者缺乏控制，可能導致信息重復輸出、信息缺乏決策相關性或信息泄密。

輸出環節可以是系統本身的報表展示，也可以是通過接口傳輸，作為其他系統的輸入信息。其輸出的信息可以是一項業務的最終結果，也可以成為是中間結果，后續還需進行加工處理，但無論是上述哪種情況，輸出環節的風險均可劃分為信息輸出的內容不完整、不準確，存在遺漏或重復輸出，以及對信息輸出的接收者缺乏控制，可能導致信息泄密。

3.4系統處理授權環節

未執行合理、有效的業務處理環節授權管理，影響數據確性、保密性，并可能導致舞弊行為出現，進而造成企業損失。該環節面臨非授權訪問、修改系統信息的風險、同時擁有同一業務鏈條上的多個權限，且利用這些權限可進行舞弊等多種風險。

對上述環節識別出的信息系統相關風險，根據風險評估標準，從風險發生可能性和影響程度兩個維度進行分析，確定風險的重要性水平。對于風險評估結果為中高的風險，其對應業務流程為也確認為重要或一般流程，需要進行控制設計；對于風險評估結果為低的風險，不進行應用控制設計，僅根據系統設計（藍圖）完善相應業務流程。endprint

4控制設計

根據風險評估結果開展控制設計，通過系統跟單測試確認控制措施的可行性，整理形成系統風險控制文檔。

4.1輸入環節控制設計

當采用手工輸入方式，一般采取獨立于信息錄入人員的崗位依據原始單據對系統錄入信息進行復核，并簽字確認的控制措施，其為依賴于系統的手工控制。該控制措施廣泛應用于系統錄入環節。當采用系統接口從其他系統自動讀取的方式進行信息錄入時，需要重點關注系統間數據映射表維護的準確性，該環節主要采取的控制方式為固有控制、自動控制、職責分離控制以及訪問控制。對于系統接口應單獨進行控制設計，具體應涵蓋自動控制、依賴系統的手工控制、職責分離控制、訪問控制五個方面。在不同的業務場景下，控制措施應該根據實務進行細化。

4.2處理環節控制設計

處理環節較輸入環節更為復雜，其隨不同的系統和業務而由較太差異。控制方式與輸入環節的設計在原理上是一致的，但是處理環節需要考慮信息系統上線以后，業務處理發生了變化，其控制措施如何更改的情況。新上線系統的控制設計應建立在原有流程和控制的基礎上，對系統上線對業務流程和控制的影響進行分析，最終形成整合后的系統控制文檔。

4.3輸出環節控制設計

輸出環節控制一般依賴于系統的固有控制，不單獨進行控制設計，在此不做詳細的介紹。

4.4系統處理與授權環節控制設計

系統處理與授權環節的控制即信息系統的權限管理，在實際應用中，權限一般分為關鍵權限和非關鍵權限，權限管理主要集中在關鍵權限。

信息系統權限控制設計及管理因遵循以下原則：需求導向及最小授權原則，未明確允許即禁止，職責分離原則。

需求導向及最小授權原則：對于用戶的權限，應當以其實際工作需求為依據，且僅應當授予能夠完成其工作任務的最小權限。

未明確允許即禁止：除非用戶有對于權限的需求得到了相關領導的明確批準，否則不應當授予任何權限。

職責分離原則：對于同一組不相容權限，任何用戶不能同時具有兩種（或兩種以上）的權限。

在對系統處理授權環節進行控制設計時，應首先了解該信息系統權限的設計及分配情況，不同的信息系統在權限設置和管理上可能會形成基于用戶、角色、任務的不同分類。

權限管理由訪問控制和職責分離兩個方面的內容組成：

訪問控制：是指用戶能夠訪問哪些應用系統內的資源或執行哪些任務（或功能）的范圍，從控制的角度考慮在系統中所擁有的功能權限和數據權限是否超出了其工作需要。訪問控制包括三個要素：主體、客體和控制策略。

主體（Subject）是指提出訪問資源具體請求。是某一操作動作的發起者，但不一定是動作的執行者，可能是某一用戶，也可以是用戶啟動的進程、服務和設備等。

客體（Object）是指被訪問資源的實體。所有可以被操作的信息、資源、對象都可以是客體。客體可以是信息、文件、記錄等集合體，也可以是網絡上硬件設施、無限通信中的終端，甚至可以包含另外一個客體。

控制策略（Attribution）是主體對客體的相關訪問規則集合，即屬性集合。訪問策略體現了一種授權行為，也是客體對主體某些操作行為的默認。

職責分離：職責分離是把一個業務（子）流程的工作內容分為幾個職責不相容的部分并由不同的人來完成，職責分離的兩個基本設想為：兩個或以上的人或部門無意識地犯同樣錯誤的概率很小；兩個或以上的人或部門有意識地合伙舞弊的可能性大大低于單獨一個人或部門舞弊的可能性。

職責分離是組織機構安全運作的必要條件，為了在計算信息系統中實現職責分離機制，首先需要在現實世界與計算機系統之間進行良好的映射：現實領域中的工作人員映射為信息系統中的用戶，工作人員的工作職責映射為信息系統中用戶擁有的權限集，工作人員能執行什么工作職責，用戶就執行什么權限集。因此，在給用戶分配權限、用戶執行權限時，就要注意需要分離的職責在信息系統中所映射的權限集的并集不能由同一個用戶同時擁有或執行。

職責分離的實現可以從業務流程的維度和企業組織結構的維度兩個緯度進行展開。從業務流程的維度（橫向）出發，職責分離涉及的環節包括交易的發起、復核（或授權）、記錄、實物保管、稽核檢查、主文件維護、系統管理等多個方面。

從企業組織結構的維度（縱向）出發，職責分離包括兩個方面：

（1）凡必須由企業組織結構中不同的人完成的職責，也應當視為必須分離的職^

（2）上述權限除第一個層面為錄入權限外，其他均為審批權限，各個層級的審批關注點或審批金額有所不同。否則，應考慮管理權限下發，簡化業務流程冗余環節。

在實際業務中，往往因為崗位設置、業務特殊性等原因而導致本應互斥的關鍵權限無法拆分，在此種情況下，首先應判斷是否可采取崗位交叉審核、管理權限上移等方式進行調整，如無法調整的情況下，可允許其擁有相應互斥權限，但需增加額外的控制措施（抽查、輪崗等）以降低同一人員同時擁有互斥權限而導致的舞弊風險。

為了保證系統權限分配滿足相關控制要求，需要定期進行權限的測試檢查，對發現問題及時組織整改。

4.5形成系統控制文檔

對初步完成的控制設計還需要與信息、業務相關人員進行確認，同時對于系統測試需通過系統的跟單測試確認控制設計的可行性和適用性。

在完成控制設計和確認的基礎上，整理編寫相關工作文檔，主要包括：系統業務流程目錄、系統關鍵控制文檔（含配置清單）、系統權限控制文檔。

5控制執行

通過測試檢查系統控制的執行情況，驗證系統設計的有效性，形成適用于普遍推廣應用的控制設計文檔，并組織專項培訓，確保系統控制的得到嚴格執行。

一般來說，系統控制的執行應與系統上線同步開始，在系統運行一個月后，具備測試檢查所需充足樣本量的前提下，開展控制執行情況的測試檢查。

參考資料

[1] IT Governance Institute. C0BIT5.1.

[2] 財政部，證監會，審計署，銀監會，保監 會.企業內部控制應用指引.

[3] 中國石油天然氣集團公司.信息系統內部 控制設計原理及方法研究.

[4] Tuttle B，Vandervelde SD.An empirical examination of CobiT as an internal control framework for information technology. International Journal of Accounting Information Systems. 2007.endprint