애플리케이션의 위험을 평가할 때 애플리케이션은 다양한 단계 의 위험 식별 및 평가를 거칩니다. 요구 사항에 따라 식별 및 평가 워크플로우를 정의할 수 있습니다.
애플리케이션의 위험을 평가하기 전에 비즈니스 애플리케이션 테이블에서 애플리케이션을 생성하고 가져와 GRC야 합니다. 애플리케이션 GRC이 오면 위험 식별 기록이 생성됩니다. 애플리케이션 소유자는 IT 위험 관리자에게 애플리케이션에 대한 정보를 제공합니다. 그런 다음 IT 위험 관리자는 권장되는 위험, 인용 및 정책을 매핑합니다.
비즈니스 애플리케이션의 위험 식별 및 평가 워크플로우를 이해하려면 다음 예를 생각해 보십시오. 새 비즈니스 애플리케이션이 조직에 도입됩니다. 이 새 애플리케이션은 비즈니스 애플리케이션 테이블의 일부입니다. 새 애플리케이션에는 두 명의 소유자가 있습니다.
IT 애플리케이션 소유자
비즈니스 소유자: 이 사용자에게는 sn_grc.business_user 역할이 있어야 합니다.
주:
조직에서 다양한 역할을 사용할 수 있습니다.
이 시점에서 애플리케이션은 의 일부 GRC가 아닙니다. 위험을 평가하기 전에 하나의 엔터티로 가져와 GRC 야 합니다. 또한 새 애플리케이션에는 정보 객체가 연결되어 있어야 합니다.
애플리케이션 위험 평가의 워크플로우 및 승인자는 위험 식별 구성 양식의 설정에 따라 결정됩니다. 워크플로우를 정의하는 프로세스를 이해하려면 을 위험 식별 통합 설정 참조하십시오. 위험 식별을 다시 시작하기 위해 플로우 디자이너 작업이 제공됩니다.
새로운 비즈니스 애플리케이션을 평가할 때 위험 식별 워크플로우는 다음과 같습니다.
비즈니스 애플리케이션은 자동으로 또는 비즈니스 애플리케이션 테이블의 애플리케이션 소유자에 의해 만들어집니다.
GRC 새 비즈니스 애플리케이션을 탐지합니다. 새 애플리케이션에 대한 엔터티가 GRC 생성됩니다. 탐지는 백그라운드에서 실행되는 프로필 생성 예약된 작업에 의해 GRC 처리됩니다.
애플리케이션에 대한 새 위험 식별 기록이 생성됩니다.
주:
위험 관리자는 구성 기록을 수정하고 평가 워크플로우를 결정할 수 있습니다. 위험 식별 구성이 게시된 후 위험 관리자는 구성 기록의 일부 필드만 수정할 수 있습니다.
질문서가 시작되어 애플리케이션에 대한 세부 정보를 수집하기 위해 애플리케이션 소유자에게 전송됩니다.
애플리케이션 소유자가 질문서에 응답합니다.
IT 위험 관리자가 응답을 검토합니다. 응답이 만족스럽지 않으면 관리자는 질문서를 애플리케이션 소유자에게 다시 보냅니다.
주:
질문서가 반송되면 새 응답은 원래 양식으로 되돌아갑니다.
구성에 따라 IT 위험 관리자가 응답에 만족하면 시스템은 고유 평가를 시작합니다.
GRC 은 엔터티 유형을 기반으로 위험 및 준수 객체를 매핑합니다.
IT 위험 관리자는 정보 객체 매핑을 검토합니다.
시스템은 구성에서 선택한 알고리즘에 따라 권장 엔진을 실행합니다.
IT 위험 관리자는 관련 정보 객체를 기반으로 권장되는 위험, 정책 및 인용을 검토하고 매핑합니다.
IT 위험 관리자는 관련 인용, 정책 및 위험을 기반으로 권장 통제를 매핑합니다.
애플리케이션 소유자는 통제 수명주기를 관리하고 통제를 증명합니다.
다음 그림은 솔루션의 워크플로우를 나타냅니다.그림 1. GRC 및 APM 통합의 솔루션 워크플로우
위험 식별 기록의 상태
위험 식별 구성이 게시됨 상태로 이동하면 관련 엔터티에 대한 위험 식별 기록이 생성됩니다.
위험 식별 기록은 다음 상태를 통해 이동합니다.
신규: 새 기록이 생성됩니다.
정보 수집: 애플리케이션에 대한 정보가 수집됩니다.
검토: 위험 관리자가 정보를 검토합니다.
고유 평가: 위험 관리자는 고유 위험 평가를 수행합니다.
위험 매핑: 위험 관리자는 필요한 위험, 인용 및 정책을 매핑합니다.
모니터링: 위험을 모니터링합니다.
폐기됨: 필요에 따라 위험이 폐기됩니다.
위험 식별 구성이 폐기됨 상태로 이동하면 구성이 잘못되고 관련 엔터티에 대한 위험 식별 기록이 생성되지 않습니다.
