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

권한 문서

정책 및 준수 관리 신청은 권한 문서를 식별하는 것으로 시작됩니다. 이러한 문서는 조직에서 준수해야 하는 법률, 규정 및 표준이 포함된 외부 규정으로, 조직에서 수행하는 비즈니스 유형과 위치에 따라 다릅니다. 규제 요구 사항은 일반적으로 법률 또는 특정 산업에 명시된 요구 사항을 제공하는 규제 기관에서 게시합니다. 이러한 요구 사항은 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, 계정 유형, 수입원 등과 같은 속성이 있으며 이러한 속성은 고객 정보 테이블에 저장되며 속성을 기반으로 쿼리할 수 있습니다.

엔터티

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

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

정책

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

정책 승인

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

정책 예외

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

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

컨트롤 목적

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

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

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

통제

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

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

제어 테스트

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

표시기

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

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

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

증명

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

문제

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

정정 작업

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