[USG]위험 관리를 위한 일반적인 접근법 #1, 2

[1주차] 위험 관리 서론

이제 사이버 보안 위험 관리 프레임워크에 대한 전문화를 시작한다. 이 과정은 위험 관리에 대한 일반적인 접근 방식이다. 모든 조직은 비즈니스 운영을 지원하기 위해 정보를 사용한다.

[2주차] 위험 관리 노력 구축

학습목표

1. 위험 선호도를 정의하고 조직이 허용 가능한 위험 수준을 식별하는 방법을 설명한다.
2. 일반적인 위험 관리 계획 팀의 구조를 설명한다.
3. 조직이 어떻게 위험 관리 계획을 수립하는지 설명한다.
4. 위험 관리 정책을 개발하는 데 사용되는 프로세스를 설명한다.

[2-1] 위험 관리 기획팀의 구성

위험 관리 개발 프로젝트에는 두 팀이 참여한다. ① 프레임워크 팀은 전반적인 위험 관리 노력을 계획하는 역할을 하며 ②프로세스 팀은 리스크 관리 평가를 수행한다. 위험 관리 개발 프로세스는 노력의 분위기와 방향을 설정하는 데 필요한 상부 경영진의 지침으로 시작된다. 위험 관리 노력은 보통 책임자에게 할당되어 노력을 지원하고 팀과 상부 경영진 간의 연락 담당자 역할을 한다. 책임자는 부서 간 문제를 원만히 해결하는 데도 도움을 준다. 위험 관리 계획 또는 프레임워크 팀은 전체 리스크 관리 프로그램을 구축하는 데 관련된 여러 활동을 담당한다. 이전에 공식적으로 위험 관리가 수행된 적이 없는 조직에서 이 팀은 다음 단계를 맡는다. 다음은 적절한 위험 관리 방법론 선택한다. 그리고는 선택한 방법론을 기반으로 위험 관리 프로세스를 설계한다. 위험 관리 프로세스 팀의 구조화 및 인력 배치를 진행한다. 전체 위험 관리 프로세스에 대한 전반적인 감독. 초기 위험 관리 주기 후 위험 관리 보고서 수집 및 검토 작업이 완료되고, 운영되고, 진행됨에 따라, 프레임워크와 프로세스가 지속적으로 개선되어 회사의 위험이 감소하는 것이다. 조직에 현재 위험 관리 노력이 있는 경우, 팀은 프로세스의 이전 구현을 검토한 다음 개선에 대한 권장 사항을 만든다.

 

어느 시점에서든 프레임워크 팀은 현재 방법론을 폐기하기로 결정한 다음, 대체 작업을 찾기 시작할 수 있다. 그 경우 전체 작업 목록이 처음부터 다시 시작된다. 좋은 소식은 위험 관리 팀이 처음부터 위험 관리 프로그램을 설계할 필요가 없다는 것이다. NIST 또는 ISO와 관련된 방법론을 포함하여 비용이 거의 들지 않거나, 혹은 전혀 들지 않고 이용할 수 있는 몇 가지 잘 정립된 방법론이 있기 때문이다. 그렇다면 방법론이란 무엇인가? 방법론은 단순히 형식적이고 문서화된 작업 수행 방법이다. 작업이 복잡할수록 방법론을 갖추는 것이 중요하다. 체크리스트를 생각하여 모든 단계가 올바르게 수행되고 어떤 단계도 생략되지 않는지 확인한다. 따를 방법론이 없다면 조직은 직원들의 지식에 완전히 의존할 수밖에 없다. 조직이 위험 관리를 처음 시작하는 경우 조직의 정보 보안이 위험을 적절하게 식별하고 관리하는 능력에 달려 있기 때문에 이는 매우 위험할 수 있다. 조직이 방법론을 선택하면 실제 작업이 시작된다. ISO 접근 방식과 같은 일부 방법론은 단순히 어떻게 접근해야 하는지가 아니라 무엇을 처리하는 방법을 가지고 있다. ISO 표준은 위험 관리 프로그램을 평가하여 어떤 것이 좋고 어떤 것이 좋지 않은지 확인하기 위해 설계된 평가 문서이기 때문이다. 좋은 프로그램은 특정 요소를 포함해야 하며, 특정 작업을 수행해야 한다. 이러한 작업을 수행하는 방식은 조직마다 다를 수 있다. 따라서 조직이 처음부터 위험 관리 프로그램을 구축하려고 하면, 이러한 표준의 목적을 충족하는 방법에 대한 세부 정보를 찾는 데 어려움을 겪을 수 있다. NIST와 같은 정부 기관에는 해당 방법론에 대해 더 자세히 알 수 있는 여러 출판물이 무료로 제공되기도 한다. 국내 기준으로는 키사가 그 역할을 해줄 것이다. ISO와 같은 표준 기관은 필요한 출판물에 대해 문서당 충분히 감당할 만한 수수료를 부과한다.

 

방법론을 조직에 적응시키는 것은 방법론의 각 단계를 살펴봄으로써 각 작업 단계의 누가, 무엇을, 어디서, 언제, 어떻게 수행할 것인가를 결정하는 것을 의미한다. 각 작업은 누가 수행하고, 작업이 완료되면 누가 감독할 것인가? 각 작업 단계 중에 무엇이 수행될 것인가? 이러한 작업은 어디에서 수행될 것인가? 이 작업을 완료하는 데 필요한 정보와 리소스는 어디에서 나올 것인가? 각 작업은 언제 수행되고 얼마나 오래 걸릴 것인가? 각 작업이 완료되면 조직은 어떻게 알 것인가? 등에 대한 답을 함으로써 말이다. 그렇게 조직에서 위험 관리를 위해 방법론을 적용시킬 때의 대답해야 할 몇가지 질문 목록은 조직마다 다를 수밖에 없다. 각 조직이 동일하지 않으므로, 완벽히 일원화된 것이란 존재할 수 없다. 각 조직의 요구에 맞게 조정할 수 있는 견고하고 일반화된 방법론만 있다. 프레임워크 팀의 경우, 사이버 보안, 정보 기술 및 비즈니스 운영을 포함한 조직의 모든 측면의 개인이 필요하다. 프로세스 팀의 경우, 프레임워크 팀의 연속성과 준수를 보장하기 위해 프레임워크 팀의 담당자가 필요하다. 또한, 회사 또는 기관의 다양한 비즈니스 및 기술 부서의 담당자가 필요하고, 사이버 보안 분석가가 평가, 위험을 계산하고 솔루션을 추천해야 한다. 또한, 팀이 생산적으로 작업하고 원하는 제품을 예산 내에서 제때 제공하며 모든 사양을 충족할 수 있도록, 인력은 아니더라도 프로젝트 관리 기술이 필요하다. 앞서 언급했듯, 위험 관리 프로세스의 각 단계에 대한 감독을 제공할 고위 관리자가 필요하다. 이는 프레임워크 개발과 프로세스 구현 모두에서 중요한 역할을 한다.

 

프레임워크 개발을 위해서는 고위 임원이 책임자이자 리더 역할을 할 것으로 예상된다. 팀에 직원을 배치하고 보고하고 시작하는 것이다. 해당 임원은 정기적인 프레임워크 회의에 참여하지 않을 수도 있지만, 팀이 정해진 일정에 따라 이를 브리핑하기를 기대할 수도 있다. 프레임워크 문제는 이 임원에게 확대될 수 있으며, 이 임원은 프로젝트를 계속 진행하기 위해 필요한 중점 사항을 적용할 수 있다. 프로세스 팀의 경우, 계획과 실행 간의 연속성을 보장하기 위해 프레임워크 팀의 고위 관리자를 임명할 수 있다. 프레임워크 자체가 위험 관리 성과의 청사진 역할을 할 것이다. 하지만 작업이 진행됨에 따라 해결해야 할 세부 사항은 여전히 남아 있을 것이다. 프로세스 팀에 할당된 프레임워크 팀 구성원은 필요에 따라 추가 지침을 제공할 수 있다. 완벽한 세상에서 위험 관리 계획은 완벽하게 작동한다. 그러나 실제 세상에서는 모든 방향에서 어려움이 있을 것이다. 프로세스의 각 단계에서 무엇이 작동하는지, 무엇이 아닌지 정보를 수집하고 향후 개선을 위해 프레임워크 팀에 보고하는 것이 중요하다. 지속적인 개선의 기본 원칙은 좋은 위험 관리 프레임워크와 프로세스로 구축된다. 이를 올바르게 따르면, 조직은 주기를 반복할 때마다 더 나은 작업을 수행할 수 있다. 일반적인 조직은 정보 자산의 중요도와 어쩌면 감독 요구 사항에 따라 1~3년마다 위험 관리 노력을 거친다.

[2-2] 위험 선호도 구축

사이버 보안에는 근본적인 전제가 있다. 위험이 0이 될 수는 없다는 것이다. 자산을 보호하기 위해 합리적으로 할 수 있는 모든 일을 하고 나면 항상 남는 것이 있다. 이는 보안에 더 투자할수록 조직의 위험이 계속 0에 가까워질 수 있지만, 결코 0에 도달하지 못하기 때문에 발생하는 것이다. 이는 보안과 접근성의 균형을 맞추는 문제로 인해 더욱 복잡해진다. 정보 자산이 완전히 안전하다면 그 자산에 접근하기가 쉽지 않을 가능성이 크다. 쉽게 접근할 수 있다면 그 자산은 그다지 안전하지 않을 것이다. 이것이 바로 보안과 비즈니스 트레이드오프다. 핵심은 조직이 가지고 살 수 있는 균형을 찾는 것이다. 자산이 비즈니스에 중요한 목적을 위해 사용될 수 있도록 오용 및 무단 액세스와 접근성으로부터 자산을 합리적으로 보호할 수 있는 충분한 보안은 잔여 위험이다. 언제 충분한지 어떻게 알 수 있을까? 여기서 조직은 자체적인 위험 선호도를 확립해야 한다. 위험 선호도는 완벽한 보안과 무제한 액세스 간의 트레이드오프를 평가하면서 조직이 기꺼이 받아들이는 위험의 양과 성격이다. 고위 경영진이 위험 관리 개발 팀에 의사를 전달함에 따라 어떤 수준의 위험을 수용할 수 있는지, 어떤 식으로든 위험을 줄이거나 해결해야 하는지에 대한 일반적인 시각도 전달해야 한다. 즉, 위험 관리 프레임워크 팀은 위험 프로세스의 마지막에 확인된 통제 수준이 기업의 경영진이 수용할 만한 수준의 위험으로 귀결되는지 이해하고 판단할 수 있어야 한다. 현재의 모든 통제가 실행된 후에도 남아 있는 위험의 양은 잔여 위험이다. 보호되지 않는 시스템에 직면한 전체 위험에서 시작하여 구현한 기술적 및 관리적 통제를 더하면 그 수준의 위험이 감소한다. 조직이 현재 구현한 모든 통제를 고려했을 때 남은 것은 잔여 위험이다. 보안 전문가들이 밤을 새우는 이유는 다음과 같다. 우리의 잔여 위험이 너무 큰가? 우리는 그 잔여 위험을 줄일 수 있는 이제 자산을 보호하기 위해 더 많은 일을 해야 할까? 위험이 결코 0이 아닐 것이고, 위험을 줄이기 위해 실제 비용이 든다는 것을 감안할 때, 조직은 특정 시점에서 "그 정도면 충분하다. 우리는 자산을 보호하기 위해 충분한 비용을 지출했고 우리는 남아있는 잔여 위험을 기꺼이 감수할 것이다."라고 말해야 한다. 이것은 우리를 사이버 보안의 또 다른 근본적인 전제로 이끌게 한다. 우리는 정보 자산을 보호하기 위해 가치보다 더 많은 비용을 지출하지 않는다. 5만 달러의 가치밖에 없을 수도 있는 자동차를 보호하기 위해 60만 달러를 보험에 지출할 이유는 없으니 말이다.

 

조직은 리스크 관리 프로세스의 요점에 매우 잘 도달하여 문서화된 잔여 위험을 검토한 후, 조직이 그것을 가지고 살 수 있으며, 다음 위험 관리 검토 주기를 위해 모든 것을 문서화할 수 있다. 어려움은 조직이 무엇을 가지고 살 수 있는지 정확히 공식화하는 프로세스에 있다. 이 프로세스가 위험 선호도 논의의 핵심이다. 위험 관리 프레임워크 개발 노력의 일환으로 위험 선호도를 문서화하는 것은 종종 모호하고 잘 이해되지 않는 명제다. KPMG에 따르면, 잘 정의된 위험 선호도는 다음과 같은 특성을 가져야 한다. 조직의 목표, 사업 계획 및 이해 관계자의 기대를 포함한 전략을 반영해야 한다. 비즈니스의 모든 핵심 측면을 반영해야 한다. 리스크를 감수할 의지와 역량을 인정해야 한다. 모두 접근에 국한된 공식적인 위험 선호도 진술로 문서화해야 한다. 리스크를 관리하고 모니터링하는 데 필요한 기술, 자원 및 기술을 고려한다. 위험 선호도의 기업 내 맥락에 대한 노출을 포함한다. 합리적으로 정량화할 수 있는 손실이나 부정적인 사건에 대한 관용을 포함하는 것이다. 진화하는 산업 및 시장 상황을 참조하여 주기적으로 검토하고 재고한다. 매우 중요한 것은 이러한 위험 선호도가 이사회 또는 조직의 다른 고위 임원급으로부터 승인을 받았다는 것이다. 위험 선호도를 정의하기 위한 이러한 KPMG 접근 방식은 조직의 전략적 목표를 이해하고, 현재 주요 조직 활동 및 향후 전략 계획별 위험 프로파일을 정의하고, 각 프로파일에 대한 위험 허용오차 또는 위험 임계값을 정의하고, 마지막으로 공식적인 위험 선호도 진술을 문서화하여 모든 사람이 이용하고 쉽게 접근할 수 있도록 해야 한다.

위험 허용 오차는 위험 선호도와 함께 작동한다. 각 이니셔티브, 각 기술, 각 계획 또는 각 활동에 대해 허용 가능한 위험의 범위를 보다 명확하게 정의하기 때문이다. 관리자가 특정 시스템에 대해 어느 수준의 공격, 성공 및 손실을 수용할 의향이 있는지 묻는 질문에 대한 답변은 해당 시스템의 위험 임계값과 시스템이 저장하고 처리하는 데이터에 대한 통찰력을 제공해야 한다. 질문에 대한 답변이 전혀 없는 경우, 관리자는 시스템에 대한 무관용 위험 노출이 있으며 가장 높은 수준의 보호가 필요하다. 보다 현실적인 허용 오차는 일반적으로 산발적인 하드웨어 소프트웨어 문제와 전체 파괴 사이 어딘가에 해당한다. 위험 임계값의 집계는 조직의 위험 선호도가 된다. 각 자산 또는 이니셔티브의 위험 임계값은 본질적으로 더 전술적이거나 운영적이며 위험 선호도는 더 전략적이다. 다양한 자산에 대한 위험 임계값을 개발한 최종 결과는 위험 선호도 진술에서 위험 선호도를 공식화하는 것이다.

[2-3] 위험 관리 정책 개발

위험 관리 프레임워크 팀의 구성원이 확인되면, 조직의 고위 경영진은 자신의 의도와 우선순위를 전달해야 한다. 그리고 전체 위험 관리 프로그램에 대한 바람직한 결과를 도출한다. 그런 다음 프로젝트 리더는 이러한 의도를 위험 관리 노력에 대한 일련의 목적과 목표로 변환한다. 그런 다음 이러한 목적과 목표는 리스크 관리 정책을 수립하는 데 사용되고, 결국 위험 관리 계획의 기초가 된다.

 

목적과 목표는 조직의 여러 기능과 사업부에 걸쳐 위험에 대한 공통된 이해를 발전시킬 수 있다. 따라서 우리는 전사적 차원에서 비용 효율적으로 위험을 관리하고, 경쟁 우위를 위해 위험에 대해 더 잘 이해하고, 수익과 관련된 놀라운 일들에 대비한 안전 장치를 구축할 수 있다. 그리고 낮은 확률, 심각하고 치명적인 위험에 효과적으로 대응할 수 있는 역량을 구축하고 향상시킨다. 또한, 내부 리소스를 더 잘 관리하여 비용을 절감하고, 자본 투자를 보다 효과적이고 효율적으로 할당한다. 이를 정의된 날짜까지 초기 위험 관리 프레임워크 개발을 완료하고, 정의된 주기적으로 위험 관리 프로그램 진행 상황을 거버넌스 그룹에 보고한다.

예를 들어, 위험관리 프로세스 구현을 정해진 날짜까지 완료하는 등 위험관리 프로젝트 자체를 목표로 할 수도 있다. 정의된 할당된 예산을 기반으로 전체 위험관리 프레임워크 및 프로세스를 구현한다. 정의된 날짜까지 초기 위험관리 프로세스 주기를 완료하거나 정의된 주기적으로 위험관리 프로세스 결과를 거버넌스 그룹에 보고하는 것이다

위험 관리 정책은 기업 정보 보안 정책이나 EISP와 매우 유사하다. 이는 거버넌스 그룹의 의도의 많은 부분을 공식화한 전략적 문서다. 이 정책은 리스크 관리 프로세스의 수행뿐만 아니라, 모든 위험관리 계획의 개발과 실행을 안내하는 역할을 한다. 대부분은 다음과 같은 내용을 포함할 것이다. 목적과 범위는 무엇이고 누구를 위해 사용되는 정책이며, 누구에게 적용되는가? 위험 관리의 의도와 목표는 무엇인가? 거버넌스 그룹의 위험 관리에 대한 일반적인 견해는 무엇인가? 그리고 그것이 전체 조직의 리스크 관리 목표와 목표로 어떻게 변환될 것인가? 하는 것이다.

그렇게 역할과 책임, 위험 관리 프로그램을 담당하는 각 구성 요소에 대한 할당 및 기대 목록을 작성한다. 이러한 목록은 일반적으로 직책과 관련된 사람과 그룹이 담당하는 업무가 무엇인지를 명시해야 한다. 이들은 감독 및 거버넌스 그룹의 일부인가? 이 그룹은 전체 위험 관리 프로그램을 감독하고 개발 및 구현에 대한 지침과 통찰력을 제공할 상위 경영진 그룹인가? 이들은 위험 관리 프레임워크 개발 팀의 일부가 될 것인가? 이 팀은 모델 프레임워크를 선택하고 방법론을 채택 및 조정하며 전체 위험 관리 노력의 설계를 명시할 계획 팀인가? 이들은 위험 관리 프로세스 구현 팀의 일부가 될 것인가? 이는 프레임워크 팀과 다를 수 있다. 이 팀은 실제로 위험 관리 평가를 수행할 팀이다. 프레임워크 팀의 대표자뿐만 아니라 조직의 나머지 대표자도 포함할 수 있다. 또는 최고 정보 보안 책임자는 위험 관리 프레임워크 개발 팀의 프로젝트 팀장 역할을 할 수 있다. 그리고 계획 팀이 지정한 일정 예산 또는 기타 제약 조건 내에서 프레임워크의 완료 및 프로세스 구현을 보장하는 역할을 할 수도 있다. 또는, 회사의 기타 비보안 기술 부분 중 조직 정보 기술 시스템 및 데이터에 대한 지식은 있지만 비즈니스 유닛의 일부일 수 있다. 이는 위험 관리 프로젝트의 성공에 기득권을 가진 조직, 비보안, 비IT 부서의 구성원이 될 것이다. 여기에는 위험 관리 프로젝트가 보호하기 위해 설계된 정보 자산의 많은 소유자가 포함된다.

위험 관리 정책에는 자원 요구 사항도 포함된다. 프로그램으로서 위험 관리 지원과 프레임워크 및 프로세스 팀에 할당된 자원 목록이다. 자원 목록은 앞서 지정한 역할과 책임을 지원할 수 있을 만큼 충분히 커야 한다.

위험 선호도 불관용성은 일종의 요인이다. 위험 수준에 대한 경영진의 기대와 선호도를 요약한 것이다. 조직은 위험 관리 프로그램 개발 지침을 기꺼이 수용하고, 조직이 위험 관리 노력의 개발과 실행을 가이드하기 위한 구체적인 지침을 식별한다. 여기에는 특정 방법론을 따르려면 특정 규정이나 법률을 준수해야 한다는 필요성이 포함될 수 있다. 이는 위험 관리 프로젝트에 통합되거나, 또는 프로젝트 대신 통합될 수 있다. 그리고 거버넌스 팀이 알리고자 하는 다른 특별한 고려 사항도 포함된다.

정책 문서를 검토하고 수정하는 계획에 대한 지침으로 누가, 어떻게, 언제 수정할 것인지를 포함하여 특별한 지침이나 수정 정보를 제공해야 한다. 그리고 필요에 따라 다른 주요 문서에 대한 참조가 있어야 한다. 이는 주요 정책, 계획 및 표준 또는 기타 지침을 의미할 수 있다. 조직이 위험 관리 프로그램을 개발하고 시행하는 동안, 외부 기관이든 어디든 관계없이 이러한 주요 문서를 인식하고 인식해야 한다.

모든 보안 정책이 알고자 하는 모든 사람, 즉 위험 관리 노력에 참여하는 모든 사람에게 배포되어야 하는 것과 마찬가지로 위험 관리 정책이 개발되면 이를 검토해야 한다. 이 정책을 검토해야 하는데, 이는 단순히 관련된 모든 사람에게 배포될 뿐만 아니라, 학습 또는 언어 문제가 있을 수 있는 사람들을 포함하여 실제로 관련된 모든 사람이 읽고 읽을 수 있다는 것을 의미한다. 정책을 온전히 이해하려면 모든 사람이 자신이 노출된 내용을 이해했는지 확인하기 위한 일종의 평가 또는 퀴즈가 필요할 수도 있을 것이다. 정책을 준수할 의사가 있음을 확인하는 링크를 클릭하는 일종의 확인 행위, 즉 서명 페이지나 웹 페이지와 같은 행위를 통해 정책에 동의해야 한다. 그리고 모든 정책은 일관되게 시행되어야 한다. 공식적으로 발표된 정책은 특히 위험 관리 노력에 참여하는 사람들을 위해 그 회사의 경계 내에서 소위 조직의 법칙으로 생명을 유지한다.

[2-4] 위험 관리 방안 개발

위험 관리 노력의 실행과 수행에 대한 세부사항을 담은 문서를 위험 관리 계획이라고 한다. 위험 관리 계획은 위험 관리 프로세스의 제원뿐만 아니라, 위험 관리 프레임워크의 제원도 포함한다. 계획은 위험 관리 프로세스를 수행하는 데 사용되며, 위험 관리 정책과 연계되어 사용된다. 그리고 위험 관련 정보의 수집과 평가를 안내한다. 위험 관리 계획은 두 위험 관리 프레임워크의 수행을 수행하기 위한 단계의 상세한 세트를 포함한다. 그리고 각 단계를 누가 어떻게 수행하는지에 대한 지원 정보와 함께 위험 관리 프로세스를 포함한다. 위험 관리 정책은 WHO와 WHY 부분에 중점을 둔다. 계획은 WHO와 HOW 부분에 중점을 둔다. 일부 조직에서는 위험 관리 정책과 계획을 결합하여 응집력 있고 포괄적인 하나의 문서로 만들 수도 있다. 그러나 유지보수와 검토를 더 잘 지원하기 위해 별도로 보관해야 한다. 조직에서는 프레임워크 개념의 공식적인 문서화를 대표하기 때문에 일반적으로 개발된 프레임워크를 계획이라고 부른다. 위험 관리 계획을 위험 관리 노력을 설정하고 실행하기 위한 로드맵으로 생각한다. 일정, 예산과 같은 전형적인 프로젝트 관리 구성 요소가 이에 포함된다. 여기에는 인건비, 자본 비용 또는 기타 비용과 수행해야 하는 작업의 순서가 포함된다. 세부 사항은 조직마다 다르겠지만 말이다. WHO의 위험 선호도 식별에 대한 설명문을 소개하고 개요하는 것이 프레임워크 위험 관리 프레임워크 팀이다. 위험 관리 방법론의 문서화를 하는 것이다. 이는 위험 관리 일정, 위험 관리 예산 및 프로젝트를 지원하는 데 사용할 수 있는 자원의 명세서다. 그리고 이전의 위험 관리 프로젝트나 이 위험 관리 노력의 이전 주기의 결과이기도 하다. 또한, 위험 관리 계획을 지원하는 외부 문서나 내부 문서를 가리킬 때 필요한 참고 자료도 포함해야 한다. 위험 관리 계획은 위험 관리란 무엇이며, 조직에서 위험 관리를 하는 것이 왜 중요한지에 대한 설명으로 시작될 것이다.

 

수행할 위험 관리 작업 및 성과물에 대한 이 섹션에서는 채택된 방법론의 각 단계와 관련된 작업을 식별하고 설명한다. 방법론을 조직에 구조화한 후에는 수행할 작업에 대한 전체 설명을 제공해야 한다. 따라서 계획에는 수행할 각 작업에 대해 각 작업을 수행할 정보의 출처, 해당 작업에 관련된 활동이 무엇인지 명시되어 있다. 어떤 리소스가 필요하고 예상되며, 가용성이 있는지, 어떤 전달이 생성될 것으로 예상되는지가 명시되어 있다. 수행된 활동에 대한 구체적인 보고서 및 요약과 같은 성과물은 후속 활동을 지원하는 데 일반적으로 필요하기 때문에 매우 중요하다. 프로젝트 일정을 업데이트하고 팀의 위험 관리 노력 완료에 대한 상대적인 진행 상황에 대해 관리를 업데이트한다. 위험 관리 일정에는 프레임워크 팀과 프로세스 팀 모두의 프로젝트 일정이 요약되어 있다. 조직의 규모와 자산 수에 따라 활동이 달라질 것이다. 효과적인 위험 관리 주기는 소규모 조직의 경우 몇 달에서 대규모 조직의 경우 몇 년까지 걸릴 수 있다. 어떤 조직의 경우에는 정보 자산의 클러스터나 그룹을 다루는 네버엔딩 사이클이다.

각 위험 관리 주기가 완료되면 그 결과는 다음 주기의 위험 관리 계획에 저장된다. 팀에 현재 주기에서 검토해야 할 내용과 검토해야 할 내용에 대한 추가적인 통찰력을 제공해야 한다. 권장 사항이지만 예산 제한이나 기타 비즈니스 문제로 인해 실행되지 않은 통제 사항도 특히 관심을 끈다. 주기 후 검토를 통해 얻은 교훈도 특히 관심을 끈다. 위험 관리 팀은 권장 사항을 검토하고 이 피드백을 기반으로 수행할 방법론 또는 태스크를 변경해야 한다. 참조 섹션에는 사용되거나 위험 관리 태스크의 수행에 사용되어야 하는 참조 사항이 나열된다. 여기에는 NIST, KISA 특별 간행물과 같은 외부 리소스와 위험 관리 정책과 같은 내부 정책이 포함된다. 참조 사항의 가능한 사본이 팀에 컨텍스트를 제공하고 위험 관리 전반에 대한 이해를 높이기 위한 계획에 포함되면 위험 관리 계획이 검토되고 승인된다. 이제 완료되면 상위 경영진이 위험 관리 계획을 검토하고 승인한다. 그런 다음 위험 관리 팀이 액세스할 수 있고 사용할 수 있는 위치에 분류되어 저장되는 것이다. 이 작업에는 보통 다중 요소 인증을 통해 지원되는 네트워크의 내부 위치에서 암호로 보호되는 것이 포함된다. 그리고 각 팀 회의 및 작업 세션에서 VPN 액세스에 대한 요구 사항이 포함된다. 계획이 일정에 유지되고 선택한 방법론에 따라 작동하도록 보장하기 위해 이 계획이 참조된다.