CIS-RC Study Guide — ServiceNow Certified Implementation Specialist: Risk and Compliance

Trademark disclaimer: ServiceNow, Now Platform, Integrated Risk Management (IRM), Governance Risk and Compliance (GRC), and all related product and feature names are trademarks of ServiceNow, Inc. This is independent, original exam-preparation material and is not affiliated with, endorsed by, or sponsored by ServiceNow, Inc. All explanations below are written in original prose and grounded in publicly available official ServiceNow documentation (docs.servicenow.com), ServiceNow Learning, and Now Create / best-practice guidance.

Product naming note. ServiceNow rebranded the GRC product family as Integrated Risk Management (IRM). The CIS-RC exam blueprint and many docs still use "GRC," so you will see both. Treat GRC = IRM for this exam. The shared platform layer (Profiles, Entities, Indicators, common workflow) is still commonly called the GRC framework / common core. Study guide is organized by exam weight, heaviest domains first.

Domain: Entity Scoping (25%) — heaviest, study first

Entity scoping is the practice of defining what in the organization is subject to risk, control, and compliance activity, and how broadly GRC content applies. It is the backbone shared by every IRM application.

Profiles, Entities, and the common core. The GRC/IRM common framework supplies a shared data model used by Policy & Compliance, Risk, and Audit. The central record is the Profile — a GRC representation of something you want to govern (a business unit, application, vendor, facility, process, control set owner, etc.). Profiles connect organizational objects (often CMDB CIs, departments, or other tables) into the GRC world so that controls, risks, and audits can attach to them.

Entity. An entity is any object that GRC content can be applied to or scoped against — typically a record in a table that represents a real-world item (a server CI, a department, a vendor record). Entities are the instances.

Entity type. An entity type defines a class of entities by pointing to a specific table and (optionally) a condition/filter. It tells GRC "entities of this type live in this table and match these criteria." Entity types let you bulk-create profiles from records in any table. Example: an entity type "Critical Applications" sourced from cmdb_ci_appl with a condition business_criticality = 1.

Entity class. An entity class is a grouping/categorization layer used to organize entity types and profiles for scoping and reporting (e.g., classes such as Organization, Process, Asset, Vendor). Classes help you structure the profile hierarchy and drive how content is inherited and rolled up.

Profile types and profile classes. Profiles are categorized by profile type (which maps to an entity type) and grouped using profile classes, enabling hierarchical scoping — content applied at a parent level can cascade to children.

Scoping = applying GRC content to the right entities. When you attach an authoritative source, control objective, risk statement, or indicator to profiles/entities, you are scoping. Scoping can be done:

Manually (attach a profile directly), or
Dynamically via entity-type conditions so newly matching records automatically come into scope.

Implementation flow (typical): create entity classes/types → point them at source tables with conditions → generate profiles → organize profiles into hierarchy → attach content (citations, control objectives, risk statements, indicators) to scope it.

Key gotchas for the exam:

Distinguish entity (instance) vs entity type (definition/table+filter) vs entity class (grouping).
Profiles are the join point between org objects and GRC content; they are what controls/risks/indicators ultimately attach to.
Dynamic scoping via entity-type conditions keeps scope current as data changes.

Domain: Policy and Compliance Implementation (25%)

Policy & Compliance Management (PCM) lets an organization create and manage policies, map them to external/internal mandates, define what "good" looks like, and continuously test that controls operate effectively.

The PCM content chain (memorize the order): Authoritative Source → Citation → Control Objective → Control → Control Test (and results).

Authoritative Source. The mandate or document of authority — a regulation, standard, framework, law, or internal policy library (e.g., PCI DSS, ISO 27001, SOX, NIST). It is the "where the requirement comes from."
Citation. A specific requirement/clause within an authoritative source (e.g., "PCI DSS Requirement 8.2"). Citations break a source into discrete, testable obligations.
Control Objective. A statement of intent describing the desired outcome to satisfy one or more citations (the "what we want to achieve," e.g., "Access to cardholder data is restricted"). Control objectives map to citations.
Control. The actual implemented safeguard/activity that satisfies a control objective for a given profile/entity (the "how, here"). Controls are generated when a control objective is scoped to profiles. A control is the testable, owned instance.
Control Test. The procedure used to evaluate whether a control is operating effectively; produces control test results (pass/fail, with attestation, evidence, or automated indicator data). Failed/ineffective controls can spawn issues and remediation tasks.

Policies and policy exceptions. Organizations store corporate policies and procedures; users can request policy exceptions that route through approval workflow and carry expiration.

Compliance scoping. Control objectives are attached to profiles/entities (via Entity Scoping), which generates controls per in-scope entity. This is where Entity Scoping and PCM intersect — heavily tested.

Attestation and indicators. Compliance can be evidenced through attestations (manual sign-off) or indicators (automated tests against platform data / configuration). Continuous configuration monitoring lets controls be evaluated automatically and on a schedule.

Content packs / Common Controls. Pre-built citation and control-objective content (e.g., via the Unified Compliance Framework (UCF) Common Controls Hub) accelerates mapping many regulations to a deduplicated set of common controls.

Exam gotchas:

Control = scoped instance; Control Objective = reusable definition. Don't swap them.
Citation lives inside an authoritative source; control objectives map to citations.
Scoping a control objective to profiles is what creates controls.

Domain: Risk Implementation (25%)

Risk Management identifies, assesses, monitors, and responds to risk across the scoped enterprise.

Risk framework. A risk framework groups risk statements into manageable categories/methodologies so large risk libraries stay organized, and it defines the scoring methodology (qualitative vs quantitative, scales, calculation). You associate risk statements to a framework.

Risk statement. A reusable definition of a potential risk ("the thing that could happen"), independent of where it applies. Risk statements are scoped to profiles/entities, which generates risks (instances) in the risk register.

Risk (register). A risk is the scoped instance of a risk statement tied to a profile/entity, tracked in the risk register with owner, scores, treatment, and lifecycle state.

Risk assessment / scoring. Risk is evaluated typically on inherent vs residual dimensions using likelihood × impact (significance) to produce a risk score. Methodologies can be qualitative (scales like Low/Med/High) or quantitative (numeric/monetary). Risk appetite and tolerance thresholds determine whether a risk is acceptable.

Risk assessment methodologies. Assessments can be driven by assessment questionnaires/surveys sent to risk owners/stakeholders, by calculated scores from indicators, or by manual scoring. Reassessment can be scheduled.

Indicators and KRIs.

Indicators are automated or manual tests/measurements attached to controls or risks; they pull data from the platform (or external sources) to evaluate effectiveness or exposure on a schedule.
Control indicators evaluate control effectiveness; risk indicators measure risk exposure.
Key Risk Indicators (KRIs) are higher-level metrics that signal changing risk levels against thresholds; breaches can trigger alerts, tasks, or risk re-scoring. (Note: ServiceNow also uses GRC Metrics in IRM for broader periodic trend tracking, distinct from real-time indicators.)

Risk response / treatment. For each risk: Accept, Avoid, Mitigate (treat), or Transfer. Mitigation links to controls and remediation; issues capture problems needing action.

Advanced Risk and continuous monitoring. GRC: Advanced Risk extends core Risk with enhanced risk assessment, continuous monitoring of risks and controls, and richer frameworks. Continuous monitoring evaluates risks/controls automatically between formal assessments using indicators.

Exam gotchas:

Risk statement = definition; Risk = scoped instance in the register (parallels objective→control).
Inherent (before controls) vs residual (after controls) risk.
KRI = threshold-based signal; indicator = the underlying automated/manual measurement.

Domain: Implementation Planning (10%)

Covers how to scope and deliver an IRM implementation: requirements gathering, identifying which applications (Policy & Compliance, Risk, Audit, Advanced Risk, Vendor Risk) the customer needs, phasing, data sources (CMDB, HR, vendor data) feeding profiles/entities, plugin activation, and roles.

Common roles: GRC Admin, GRC Manager, Risk Manager, Compliance Manager, Audit Manager, plus reader/user roles. Match the role to the application and least-privilege principle.

Now Create / best practices: scope narrowly first, use out-of-box content packs, design the profile/entity model early (it drives everything downstream), and plan integrations (CMDB, identity, ticketing) and reporting (Performance Analytics) up front.

Domain: GRC Overview (5%)

GRC = Governance, Risk, and Compliance, the umbrella for ServiceNow's integrated risk applications, now branded Integrated Risk Management (IRM). All applications run on the Now Platform and share the GRC common framework (Profiles, Entities, Indicators, common workflow/data model). Core apps: Policy & Compliance Management, Risk Management, Audit Management, Advanced Risk, Vendor Risk Management, Business Continuity Management, Operational Resilience, Privacy Management. Value: a single shared model so controls, risks, audits, and policies reference the same scoped entities and evidence.

Domain: Extended Capabilities (5%)

Beyond the core three: Vendor Risk Management (VRM) (third-party/supplier risk and assessments), Business Continuity Management (BCM), Operational Resilience, Privacy Management, integrations (CMDB, Security Operations / SecOps, identity, external GRC data, content packs/UCF), and Performance Analytics (PA) dashboards and content packs for GRC reporting and trend analysis. Continuous monitoring and metrics extend automation.

Domain: Audit Management Implementation (5%)

Audit Management plans and executes internal/external audits leveraging the same scoped entities and controls.

Key objects:

Engagement — the audit project/scope (advanced planning lets you scope by entities, risks, controls).
Audit Plan / Audit Universe — what could be audited and the planned schedule.
Audit tasks / fieldwork — execution steps and working papers / evidence.
Findings / Issues — results of testing, routed to remediation.
Risk-based auditing — audits draw on the risk register and control test results so audit, risk, and compliance reuse the same data.

Exam gotcha: Audit reuses GRC controls, profiles/entities, and indicators — it does not maintain a separate parallel control universe.

Fast-recall cheat list

GRC = IRM (rebrand). Built on the Now Platform, shared GRC common framework (Profiles, Entities, Indicators).
Entity = instance; Entity type = table + condition (definition); Entity class = grouping. Profile = governable object that content attaches to.
Scoping = attaching content (citations, control objectives, risk statements, indicators) to profiles/entities; dynamic via entity-type conditions.
PCM chain: Authoritative Source → Citation → Control Objective → Control → Control Test → results/issues.
Control Objective = reusable definition; Control = scoped, owned, testable instance (generated when objective is scoped to profiles).
Risk chain: Risk Framework → Risk Statement (definition) → Risk (instance in register, scoped to profile) → Assessment/Scoring → Treatment.
Risk scoring: likelihood × impact; inherent (pre-control) vs residual (post-control); compare to risk appetite/tolerance.
Risk responses: Accept, Avoid, Mitigate, Transfer.
Indicators = automated/manual measurements on controls/risks; KRI = threshold-based risk signal; Metrics in IRM = periodic trend tracking.
Advanced Risk = continuous monitoring + enhanced assessment.
Content packs / UCF Common Controls Hub = prebuilt citation/control content (deduplicated common controls).
Audit: Engagement → plan/universe → fieldwork/tasks → findings → remediation; reuses GRC controls & entities.
Extended: VRM, BCM, Operational Resilience, Privacy, integrations (CMDB/SecOps), PA dashboards.
Roles: GRC Admin / Manager, Risk Manager, Compliance Manager, Audit Manager (least privilege).