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

권한 문서

Policy and Compliance Management 신청은 권한 문서를 확인하는 것으로 시작됩니다. 이러한 문서는 조직이 준수해야 하는 법률, 규정 및 표준을 포함하는 외부 규정으로, 조직이 수행하는 비즈니스 유형과 위치에 따라 다릅니다. 규제 요구 사항은 일반적으로 법률 또는 특정 산업에서 설명하는 요구 사항을 제공하는 규제 기관에서 게시합니다. 이러한 요구 사항은 HIPAA(Health Insurance Portability and Accountability Act)와 같은 연방 또는 주 규정, GDPR(일반 데이터 보호 규정)과 같은 국제 규정 또는 PCI(Payment Card Industry)와 같은 산업 규정에서 비롯될 수 있습니다. HIPAA, GDPR 및 PCI와 같은 각 문서는 권한 문서입니다.

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

인용

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

인용은 수동으로 만들거나 UCF를 통해 가져올 수 있습니다.

엔터티 유형

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

엔터티

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

엔터티 유형을 만들 때 엔터티가 자동으로 생성됩니다.

정책

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

정책 승인

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

정책 예외

이렇게 하면 정책에 대한 예외를 가질 수 있습니다. 어떤 이유로 정책이나 컨트롤을 준수할 수 없는 경우 예외를 기록할 수 있습니다.

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

컨트롤 목적

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

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

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

제어

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

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

제어 테스트

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

표시기

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

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

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

증명

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

문제

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

정정 작업

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