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