전사 위험 관리에서의 IT 시나리오 분석

By Urs Fischer, CISA, CRISC, CPA Swiss

ISACA Journal Volume 2, 2011

시나리오는 위험 책임자의 병기 창고에 있는 한가지 강력한 도구이다—시나리오는 전문가들이 정상적인 질문에 답하는데 그리고 예상하지 못하는 질문을 준비하는데 도움이 된다. 시나리오 분석은 전사 위험 관리(ERM: enterprise risk management)에 있어서 ‘새롭고’ 가장 좋은 실무이다(그림 1 참조). 또한, 시나리오 분석은 ISACA의 위험 IT 프레임워크의 가장 중요한 절차이다. ¹, ²

위험 시나리오 분석은 IT 위험을 보다 구체적이고 실체적으로 만들고 그리고 적정한 위험 분석 및 평가를 할 수 있게 해주는 테크닉이다. ³ 그것은 IT 위험의 복잡한 사안에 대해 현실성, 통찰, 조직적 참여, 개선된 분석 및 구조를 낳는 핵심 접근방법이다.

시나리오 분석 흐름

IT 위험 관리에 대한 도전 가운데 하나는 잘못될 수 있는 모든 것에 걸쳐 있는 관련 위험들을 확인하는 것이다. 이러한 도전을 극복할 수 있는 테크닉은 위험 시나리오의 개발 및 이용이다. 일단 이러한 시나리오들이 개발되면, 그것들은 시나리오 발생의 빈도와 비즈니스 영향을 판단하는 위험 분석 과정에 사용된다.

그림 2는 IT 위험 시나리오가 2가지 다른 방법으로 개발될 수 있음을 보여준다:

• 하향식 접근, 이것은 전반적인 비즈니스 목적에서 출발하여 비즈니스 목적에 영향을 미치는 가장 관련있고 가능성있는 IT 위험 시나리오의 분석을 수행한다.
• 상향식 접근, 이것은 일반적인 시나리오 목록을 가지고 일련의 보다 구체적인 맞춤형 시나리오들을 정의하는데 사용된다.

이러한 접근방법들은 서로 보완적이며 함께 활용되어야 한다. 실제로 위험 시나리오들은 실질적인 비즈니스 위험들과 관련이 있으며 연계되어야만 한다. 한편, 예시적인 일반 위험 시나리오들을 이용하는 것은 어떠한 위험도 간과하지 않으면서 IT 위험에 대한 보다 종합적이고 완전한 시각을 제공하도록 보장하는데 도움이 된다.

다음은 일련의 (비즈니스 위험과) 연관된 중요한 위험 시나리오들을 개발하는데 도움이 되는 것으로 입증된 실질적인 접근방법이다:

1. 조직을 위한 위험 시나리오의 구체적인 초안을 만드는데 있어서 예시적인 일반 위험 시나리오들⁴을 이용한다.
2. 초안에 대해 조직의 비즈니스 목적에 맞춰 검증한다.
3. 검증 결과를 바탕으로 선택된 시나리오를 정제한다; 조직에 미치는 위험한 정도⁵에 따라서 시나리오들을 수준별도 분류한다.
4. 시나리오 수를 관리가능한 범위로 감소시킨다.⁶
5. 다음 주기에 재평가할 때, 관련이 있다면 상세한 분석을 할 수 있도록 목록의 모든 위험들을 보존한다.
6. 명시된 시나리오에 의해 다루어지지 않은 사고(incident)들에 대처하기 위하여 시나리오 속에 ‘미명시 사건(unspecified event)’을 포함시킨다.

일단 일련의 위험 시나리오들은 정의되고 나면 위험 분석을 위해 사용될 수 있다. 위험 분석에서는 시나리오의 빈도와 영향이 평가된다. 영향 평가에 있어서 중요한 구성요소들은 다음 장에서 설명할 위험 요인들이다.

이것은 로켓 과학이 아니다, 그렇다면 왜 조직은 위험 시나리오를 보다 자주 정기적으로 이용하질 못하는가? 사실 위험 시나리오를 개발하는 것은 보기 보다 어렵다는 점을 명심하라. 한가지 좋은 시나리오 조차도 구축하는데 시간이 걸리고 전사적인 많은 영역들에서 좋은 입력(input)을 필요로 한다. 하물며, 모든 (시나리오) 세트에 대해서는 많은 시간 및 에너지의 투자가 필요한 것은 당연하다.

위험 요소들

위험 요소들은 위험 시나리오의 빈도 그리고/또는 비즈니스 영향을 좌우하는 요소들이다. 그들은 서로 다른 성질을 지닐 수 있으며, 다음 2가지 주요 범주로 분류될 수 있다.

• 환경적 요소들, 이것은 내부 및 외부 요소로 나뉠 수 있다—기업이 그들에 대해서 갖는 통제 정도의 차이에 따라서:
• 내부 환경 요소들은 대부분 기업의 통제하에 있다.
• 외부 환경 요소들은 대부분 기업의 통제밖에 있다.
• 역량, 예를 들어, 많은 IT-관련 활동들로 인해 기업이 얼마나 좋은가. 이것들은 ISACA의 3가지 주요 프레임워크에 따라서 구분될 수 있다:
• IT 위험 관리 역량—기업이 ‘Risk IT’에 정의된 위험 관리 프로세스를 이행하는데 있어서의 성숙 수준
• IT 역량—COBIT에서 정의된 IT 프로세스들이 얼마나 바람직한가
• IT-관련 비즈니스 역량(혹은 가치 관리) —‘Val IT’ 프로세스들을 관통하여 표현된

위험 요소들의 중요성은 그것들이 IT 위험에 미치는 영향에 달려있다. 위험 요소들은 IT 시나리오의 빈도와 영향에 매우 크게 영향을 끼치며, 빈도와 영향을 평가하는 과정에서 모든 위험 분석 동안에 고려하여야 한다. 그림 3은 위험 요소들을 나타내고 있다. ⁷

위험 시나리오의 구성요소

한가지 IT 위험 시나리오는, 그것이 발생했을 때와 발생한다면, 비즈니스 영향을 끼칠 수 있는 하나의 IT-관련 사건(event)에 대한 서술이다. 위험 분석 목적에 대한 완전하고 유용한 위험 시나리오를 위해서는, 위험 시나리오들은 그림 4에서 보여주는 분명한 구성요소들을 포함하여야 한다.

시나리오 개발

시나리오 사용은 위험 관리에 대한 비결이며, 그런 테크닉(=시나리오)은 어떠한 기업에도 적용될 수 있다. 각 기업은 위험 분석을 실시하는 시작 시점에 (앞에서 서술한 구성요소들을 포함하는) 일련의 시나리오들을 만들 필요가 있다. 한가지 시나리오를 만드는 것은 모든 구성요소의 개개의 가능한 가치가 결합된 것을 의미한다. 다음은, 개별 조합들은 관련성 및 현실성을 위해 평가되어야 하고, 그리고 관련성이 있는 것으로 판명되어지면 위험 등록부에 등재된다. 하지만 이것은 현실적으로 가능하지 않다. 왜냐하면 너무도 많은 수의 시나리오들을 양산할 수 있기 때문이다. 개발되고 분석될 시나리오의 수는 관리할 수 있는 것보다 훨씬 적은 시나리오 숫자를 유지해야 하는데, 그 이유는 (시나리오가 너무 많으면) 모든 가능한 조합이 (함께) 유지될 수 없기 때문이다. ⁸

결론

시나리오는 위험과 기회를 이해시키는데 있어서 매우 강력한 3가지 장점을 갖고 있다. ⁹

첫째, 시나리오는 사람의 사고 영역을 넓힌다. 사람은 시나리오가 많은 가능한 결과물을 개발하게 되면 (이를 바탕으로) 더욱 폭넓게 생각할 것이다. 사물이 (그토록) 빨리 좋아질 수 있고 혹은 나빠질 수 있는 상태와 이유를 보여줌으로써, 사람들은 미래에 적용할 수 있는 어느 정도의 가능성을 위해 자신들의 준비를 향상시킬 수 있다.

둘째, 시나리오는 전혀 피할 수 없는 혹은 거의 피할 수 없는 앞으로의 일들을 들춰낸다. 시나리오를 개발하는데 있어서, 사람은 미리 정의된—특히 예상치 못한 (중간) 결과물을 살필 것인데, 그것은 가끔 시나리오 개발 프로세스에서 발견하게 되는 새로운 통찰의 가장 강력한 원천(source)이다.

그리고, 마지막으로, 시나리오는 ‘집단사고(groupthink)’의 폐단을 막는다. 가끔, 조직의 상하관계는 토론의 자유로운 흐름을 막는다. 직원들은 자신의 의견을 과감히 이야기하기 전에 최고 책임자가 의견을 개진할 때까지 기다리는데(특히 회의석상에서), 그렇게 되면 그것은 종종 책임자의 의견을 놀랍도록 반영한다. 시나리오는 조직들이 상반된 사고에 대한 정치적인 안전한 피난처를 제공함으로써 이러한 덫에 걸리지 않도록 해준다.

시나리오가 모든 해답을 제공하지 않지만, 경영진이 더 좋은 질문을 하도록 그리고 예상치 못한 질문을 준비하는데 도움을 준다. 사실 그것이 시나리오를 매우 가치있는 도구로 만들어 준다.

Endnotes

¹ ISACA, The Risk IT Framework, USA, 2009
² ISACA, The Risk IT Practitioner Guide, USA, 2009
³ Risk analysis is the actual estimation of frequency and magnitude/impact of a risk scenario. Risk assessment is a slightly broader term and includes the preliminary and ancillary activities around risk analysis, i.e., identification of detailed risk scenarios and definition of responses.
⁴ The Risk IT Practitioner Guide provides a list of generic IT risk scenarios. This list can be used as a basis to build the enterprise’s own set of relevant risk scenarios.
⁵ Critical entities deserve to have risk scenarios defined at a detailed level; non-critical entities can do with quite generic scenarios that are not elaborated in too much detail. Note that the entity can be an organisational unit, but can also be something cross-organisational, e.g., a grouping of similar business processes and activities.
⁶ ‘Manageable’ does not signify a fixed number, but should be in line with the overall importance (size) and criticality of the unit. There is no general rule, but if scenarios are reasonably and realistically scoped, the enterprise should expect to develop at least a few dozen scenarios.
⁷ Risk factors are discussed in detail in The Risk IT Practitioner Guide.
⁸ Some guidance and considerations for the development and maintenance of manageable numbers of relevant scenarios can be found in The Risk IT Practitioner Guide.
⁹ Based on Roxburgh, Charles; ‘The Use and Abuse of Scenarios’, McKinsey Quarterly, November 2009

Urs Fischer, CISA, CRISC, CPA Swiss

is an independent IT governance, risk and compliance consultant. From 2003 to 2010, he was vice president and head of IT governance and risk management for the Swiss Life Group. Previously, he was head of IT audit for the SwissLife Audit Department based in Zurich, Switzerland. Since 1989, Fischer has worked in the IT governance, audit and security areas and has gained extensive IT governance, risk management and information systems compliance experience. Involved in the development of CoBIT^® 4.0 and 4.1, he is also helping with the development of CoBIT 5. A member of ISACA’s Guidance and Practice Committee, in June 2010, he received the John Lainhart IV Award from ISACA.