의 정책 및 준수 관리 구조적 개요를 통해 애플리케이션을 ServiceNow 구성하는 다양한 모듈이 어떻게 통합되고 상호 작용하는지 이해할 수 정책 및 준수 관리 있습니다.

권한 문서

정책 및 준수 관리 애플리케이션은 권한 문서를 식별하는 것으로 시작됩니다. 이러한 문서는 조직에서 준수해야 하는 법률, 규정 및 표준을 포함하는 외부 규정으로, 조직에서 수행하는 비즈니스 유형과 위치에 따라 다릅니다. 규제 요구 사항은 일반적으로 법률 또는 특정 산업에 명시된 요구 사항을 제공하는 규제 기관에서 게시합니다. 이러한 요구 사항은 HIPAA(Health Insurance Portability and Accountability Act), GDPR(General Data Protection Regulation)과 같은 국제 규정 또는 PCI(Payment Card Industry)와 같은 산업 규정과 같은 연방 또는 주 규정에서 따를 수 있습니다. HIPAA, GDPR 및 PCI와 같은 각 문서는 권한 문서입니다.

예를 들어, PCI DSS(Payment Card Industry Data Security Standards)는 결제 카드 사기를 줄이기 위한 정보 보안 표준이자 권한 문서입니다. 신용 카드 결제를 허용하는 모든 조직에 대한 일련의 보안 표준을 제공합니다. 금융 서비스 제공업체는 사기를 방지하고 카드 소지자 데이터를 보호하며 비즈니스 서비스가 안전하고 합법적인지 확인하기 위해 PCI 표준을 준수해야 합니다.

인용

인용은 기업이 특별히 준수해야 하는 권한 문서(예: UCF(Unified Compliance Framework))의 구절 또는 표현입니다. 권한 문서 내의 개별 요구 사항입니다. 예를 들어, 공용 네트워크를 통한 카드 소지자 데이터 전송을 암호화하는 것은 결제 카드 거래를 통한 소비자의 개인 금융 정보 도난을 방지하기 위한 PCI DSS의 요구 사항 중 하나입니다.

인용은 수동으로 생성하거나 UCF를 통해 임포트할 수 있습니다.

엔터티 유형

엔터티 유형은 일련의 필터 조건과 일치하는 엔터티를 그룹화한 것입니다. 인스턴스 내의 모든 테이블에 대한 조건부 쿼리를 기반으로 엔터티를 자동으로 생성할 수 있습니다. 예를 들어, 은행 계좌를 보유한 고객을 엔터티 유형으로 간주합니다. 고객에게는 이름, 고객 ID, 계정 유형, 소득원 등의 속성이 있으며, 이러한 속성은 고객 정보 테이블에 저장되며 해당 속성을 기반으로 쿼리할 수 있습니다.

엔터티

엔터티는 사람, 부서, 애플리케이션, 개체, 서버, 외부 네트워크 장비, 다양한 위치, 데이터 서버, 데이터 웨어하우스 등 기본적으로 제어 테스트를 수행하려는 모든 것이 될 수 있으며 본질적으로 정책 및 규정 준수에 속합니다. 예를 들어, 이름과 관련 재무 정보가 있는 은행 계좌를 보유한 사람이 있습니다.

엔터티 유형이 생성되면 엔터티가 자동으로 생성됩니다.

정책

권한 문서가 식별되면 회사는 비즈니스 단위가 권한 문서를 준수하는 방법을 지정하는 정책을 개발합니다. 상위 수준에서 정책 설명은 비즈니스가 해야 할 일과 하지 말아야 할 일을 정의합니다. 예를 들어 조직은 중요한 고객 정보를 보호하기 위한 요구 사항을 정의하는 데이터 보호 정책을 설정할 수 있습니다. 정책은 조직의 내부 문서이며 방화벽 정책, 네트워킹 정책, 허용되는 사용 정책, 정보 보안, 네트워크 보안, 환경 보호 등과 같을 수 있습니다. 이는 비즈니스의 특정 측면을 다루는 다양한 통제 및 통제 목표의 집합체입니다.

정책 승인

정책 승인 모듈을 사용하면 정책 소유자 또는 준수 팀이 준수 요구 사항을 충족하기 위해 직원의 검토 및 승인을 위해 정책을 보낼 수 있습니다.

정책 예외

이렇게 하면 정책에 예외를 지정할 수 있습니다. 어떤 이유로 정책 또는 제어를 준수할 수 없는 경우 예외를 기록할 수 있습니다.

정책 예외 모듈은 조직이 문서화된 제어를 따를 수 없는 모든 상황을 문서화합니다. 정책 예외에는 자체 수명주기와 승인이 있습니다.

컨트롤 목적

통제 목표는 통제를 통해 달성하려는 특정 목표입니다. 예를 들어, 데이터 보호 정책을 보장하기 위해 회사는 보안 네트워크를 구축하고 유지 관리할 수 있습니다. 허용 가능한 사용 정책의 경우 사용자가 방문하는 웹 사이트에 대한 제어를 유지하기 위해 프록시를 갖는 제어 목표가 있을 수 있습니다. 네트워크 정책의 경우 강력한 암호를 사용해야 하는 통제 목표가 있을 수 있습니다.

통제 목표를 통해 권한 문서와 정책을 함께 연결하여 규정 준수 부담을 덜어줄 수 있습니다. 하나의 통제 목표로 여러 내부 및 외부 요구 사항을 적용할 수 있습니다. 인용은 하나 이상의 통제 목표와 연결될 수도 있습니다. 또한 통제 목표 수준에서 통제와 정책이 서로 연결됩니다. 또는 통제 목표를 보고 목표에 표시된 작업을 수행하는 이유를 보여주는 권한 문서 및 정책에 대한 매핑을 다시 볼 수 있습니다.

통제 목표 모듈은 애플리케이션의 메인 허브입니다.정책 및 준수 관리 권한 문서는 규제 목표를 명시하고 정책은 조직이 해야 할 일과 하지 말아야 할 일을 문서화하는 반면, 통제 목표는 이러한 정책과 권한 문서를 준수하는 방법을 정확하게 정의합니다.

통제

통제는 통제 목표의 특정 구현입니다. 예를 들어 데이터 보호 정책의 경우 회사는 데이터를 정기적으로 백업하거나 자동 백업 시스템을 설정할 수 있습니다.

정책을 엔터티 유형과 연결하거나 엔터티 유형을 통제 목표와 연결하면 통제가 자동으로 생성되며, 통제 목표의 엔터티 유형에 나열된 각 엔터티에 대한 통제가 생성됩니다. 그러나 통제는 수동으로 만들 수도 있습니다. 의도한 통제 목표를 성공적으로 달성하는지 확인하기 위해 통제를 테스트합니다.

제어 테스트

통제가 통제 목표를 달성하는 데 효과적인지 확인하기 위해 통제를 테스트합니다. 예를 들어, 침투 테스트는 데이터 암호화의 적절한 구현을 보장합니다.

표시기

표시기를 사용하면 통제에 대한 테스트를 수행할 수 있으며 테스트는 매일, 매주, 매월 또는 분기별로 예약할 수 있습니다. 표시기 작업이 생성되어 사용자에게 전송되어 컨트롤이 준수하는지 여부를 확인하고 표시기를 통과 또는 실패로 표시할 수 있습니다. 작업이 실패하면 통제가 준수하지 않는 것이므로 문제가 생성됩니다. 표시기가 테스트를 통과하면 다음 예약된 테스트까지 컨트롤이 준수됩니다.

표시기 템플릿을 사용하면 유사한 컨트롤에 대해 여러 표시기를 만들 수 있습니다. 표시기 템플릿은 표시기의 매개변수를 정의하고 모니터링하는 표시기 유형에 따라 위험 설명 또는 통제 목표에 매핑됩니다.

표시기 결과를 수집하기 위해 표시기가 실행될 때마다 작업이 생성됩니다. 표시기 작업은 표시기 양식에 미리 설정된 빈도에 따라 모니터링할 수 있도록 일정에 따라 생성됩니다.

증명

증명은 통제를 평가하여 준수 상태를 지속적으로 모니터링합니다. 표시기와 달리 증명은 대부분 임시이며 예약되지 않을 수 있습니다.

문제

컨트롤을 테스트하는 동안 격차가 발견되면 해당 격차를 문제라고 합니다. 문제에는 감사, 규정 준수 위반, 보안 위반 또는 기타 부정적인 결과로 인한 운영 관찰이 포함될 수 있습니다. 또는 통제 테스트가 실패하고 규정을 준수하지 않으면 문제가 생성됩니다. , 위험 관리및 감사 관리 GRC 애플리케이션 간에 정책 및 준수 관리문제를 공유할 수 있습니다. 회사 위험 관리 프로그램이 위험 및 규정 준수 문제를 얼마나 빠르고 철저하게 식별하고 대응하는지를 기준으로 회사의 위험 관리 프로그램의 효과를 측정할 수 있습니다.

정정 작업

문제가 확인되면 조직은 문제를 정정하는 데 필요한 단계를 식별합니다. 위험을 완화하기 위해 정정 작업을 생성하여 정정 작업을 추적할 수 있습니다. 분류가 수행된 경우 분류 문제는 실제 문제 또는 위험 이벤트로 변환됩니다. 문제를 권장 사항으로 추적하거나 비문제로 종결할 수도 있습니다.