使用單位及資訊部門皆應當分析其系統之重要性，業務方能持續營運，減少企業損失。
提到業務持續管理(Business Continuity Management)，有的人會告訴你，我們的業務持續管理早就已經完成了，還有通過ISMS的認證，有什麼問題嗎？也有人會說，那是資訊單位的事，只要資訊單位有做備份，然後每年拿磁帶做測試，這樣就好了。還有人說，我們是公務單位，公務單位又不會倒，哪需要做業務持續管理。甚至市場上有一派的說法，說是通過了ISMS的認證，就可以自動升級並換發BS 25999的證書。在ISMS帶動起台灣一波資訊安全的風潮時，業務持續管理會是資訊單位下一波工作重點嗎？如果已經導入了ISMS的單位，業務持續管理與原先條文中所定義的執行項目是否有差異？在推動業務持續管理時，實務作業又會碰到那些問題？
業務持續管理 非IT專責
在談業務持續管理時，同時也要介紹另外一個名詞，那就是IT災害復原(IT Disaster Recover)，兩者的做法相類似，但是所涵蓋的範圍卻有所差異。一般如果講資訊系統如何恢復作業，談的還是IT災害復原。而業務持續管理，談的則是整個組織，一旦遭遇到意外狀況發生時，組織要如何恢復正常運作。在BS 25999 part 2一開始談到範圍時，也很清楚的界定，那是整個組織會面對到的風險。既然如此，就可以知道業務持續管理，一定是全面性的。而不是如同ISMS一般，可以只看某一個單一的系統，或只有資訊單位而已。
如果範圍是整個組織，那麼由資訊單位來推動，經常碰到的狀況是事倍功半。資訊單位可以知道應用系統的流程如何運作，但是資訊單位絕對不會知道每一個作業流程對使用者單位的重要性為何。資訊單位也不會知道如果不幸遭遇意外狀況時，那些業務流程是可以放棄不做的。實際發生過的案例，就是國內某最高行政機構，將他們網際網路的主機，放在另外一個學術單位內，結果學術單位發生火災，為了消防的考量而把電力設備全部切斷，也因此導致該行政單位的網際網路全面停擺。就資訊單位的考量，全球資訊網也許不會是重要的系統，但是對於這個行政機關而言，全球資訊網則代表的是這個機構對外的門面，在業務功能上有著相對的重要性。
這又談到另外一個在業務持續管理中很重要的觀念，那就是業務影響分析(Business Impact Analyze)。有些單位做得更仔細，在業務影響分析之前，還會再做一個風險分析。這裡所談到的風險分析，和ISMS中的風險分析概念是類似的。先看看會有那些狀況會導致組織無法正常運作？除了傳統的火災、颱風、爆炸，這些都是屬於意外災害的項目，921地震、納莉風災，或是SARS，這些都是令人記憶深刻的例子。除了這些呢？電力、通訊、網路這些基礎設施的損壞，都會造成組織無法正常作業。還記得2、3年前，地震及後續的餘震，把台灣周遭的海底電纜幾乎全部弄斷，造成國際間電話、網際網路暫停使用的事件嗎？這也是屬於意外事件的一種。國內也曾發生過因為大樓發生火警，結果火災的灰燼將冷氣通風口堵塞，造成機房沒有空調設備而使得組織無法運作的案例。除此之外，不要忘記有組織本身行業所面對的問題，舉例來說，銀行會面對到擠兌的風險，一旦發生擠兌的狀況，也是有可能無法繼續經營下去。同時在意外事件發生時，都會有資源排擠的現象，也就是無法像平日正常作業時能夠完全充分的使用各項資源，包括設備、人力、甚至財務等。所以一定要將組織內最重要的業務首先恢復正常的運作，從法律面、財務損失、商譽影響等不同層面，藉由問卷的方式，去找出各單位中最重要的作業流程。業務影響分析，是業務持續管理中不可或缺得一個重要項目。
評估系統價值與風險快速正常運作
而業務影響分析的目的，則在找出最大可中斷時間(maximum tolerable period of disruption)。在最大可中斷時間之下，進而去定義的是恢復時間點目標(Recovery Time Objective)，這個是過去在ISMS中所沒有談論到的。在BS 25999 part 2的5.1.1有著詳細的介紹，對資訊單位而言，簡單的說，就是當意外災害發生時，資訊系統所要恢復正常運作的時間，因此恢復時間點目標，必須從意外事件一發生就開始計算，一直到系統可以開始正常運作為止。如果某一項業務是組織賴以生存的命脈，最多允許中斷時間是1個小時，資訊單位無論是任何原因，如果讓系統中斷了2天，那是絕對不被允許的，也因此每一個應用系統的恢復時間點目標是不一樣的，端看這個應用系統對組織的重要性。記住這個重要性一定要使用單位提出來，並且經過討論及高階主管核可通過。絕對不是資訊單位單方面說了就算。更進一步的說，恢復時間點目標和意外事件發生的時間也有關連性。舉例來說，證券業每天有分幾個不同的作業時段，包括交易期間、收盤後零股交易的時間、結帳作業，以及收次日預約單的階段，同樣的證券交易系統，在每一個階段的急迫性以及重要性都不同，那自然也就影響到恢復時間點目標的制定。從上一次備份作業完成後，到意外事件發生時，所遺失的資料，這些資料在系統恢復正常作業後，都要後補登錄進系統，自然而然的也就影響了整個回復到正常運作的時間。
知道每一系統所需要恢復的時間，接下來才是要訂定各種回復策略。如果是一個不重要的應用系統，我需要每天即時進行備份作業嗎？如果是我們單位的核心業務， 我允許我的備援中心設在車程7、8個小時遠的地方嗎？我的資料備份方式、備份周期，保留頻率，是不是需要有異地儲存，這些都應該是從整個組織面由上到下來考量。國內在以往談到IT災害復原，或是備援點的建立時，很多是採取自由心證的方式，或是完全沿襲以前的方式，也不管時空環境或是技術有沒有變動。而不是從組織面開始考量。如果只是談資訊系統恢復作業的話，還勉強可行。但是如果談到業務持續管理，因為涵蓋的層面太大，包括人員的編組、設備的運輸、場所的規劃，都是需要考量的。如果還是沿襲過去的思維方式，無法達成組織預期目標的狀況是很容易發生的。另外一個在國內會常碰到的問題，即便在ISMS推動多年的狀況下，許多單位還是缺乏預先規劃的能力。舉個例子來說，很多組織只想到配合新的應用系統，就要購買新的硬體設備。但整個機房就沒有在規劃範圍內，很少去看一看機房裡面機櫃的電壓是否超過附載，甚至連機櫃上的插座夠不夠都不知道。到時候發現電源插座不夠，就一條一條的延長線連出去。機房的空調設備不足，就用大電風扇來取代。業務持續管理需要的是高度規劃的能力，因為所面對的是完全未知的狀態。在未知的狀態下，要盡可能的把各項因素都考慮進去，在國外的案例中，連人員的心理諮商，都一併納入考量。所以業務持續管理，絕對不是單一一個部門可以完成的，需要的是更多專業的人員。尤其是將業務持續管理，與IT災害復原兩者混為一談，認為只要資訊單位有投入就好了，甚至資訊單位的人員，回答不出恢復時間點目標，那都是象徵著對於業務持續管理需要再教育。
防範未然 高階主管首需執行
提起業務持續管理，在台灣還有很大一段路要走，尤其是單位的高階主管，需要重新建立觀念，才能明瞭業務持續管理對組織的重要。如果還是抱持著反正事情不會發生，就算發生的也不會在我們身上，真的發生了有錢也可以解決這樣的想法，那麼業務持續管理，大概就永遠停留在學術理論的架構上了。