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 (entities, entity types, 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.

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 entity: a GRC representation of something you want to govern (a business unit, application, vendor, facility, process, etc.). Entities connect organizational objects (often CMDB CIs, departments, or other table records) into the GRC world so that controls, risks, and audits can attach to them. Before the New York release this record was called a profile; profile type, profile class, and policy statement are the old names for entity type, entity class, and control objective.

Entity. An entity is the GRC record that content is applied to or scoped against. It usually refers to a source record that represents a real-world item (a server CI, a department, a vendor record), and it can also be created manually as an independent entity. 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." Its entity filters generate entities in bulk from records in any table, and the control objectives and risk statements associated with the entity type generate controls and risks for those entities. Example: an entity type "Critical Applications" sourced from cmdb_ci_appl with a condition business_criticality = 1.

Entity class. An entity class is a tag that classifies entities (e.g., Department, Business Application, Business Service) for grouping, aggregation, and reporting. Entity class rules assign a class automatically by source table, and entity tiers apply a level to classes (for example, tier 1 for the most critical). An entity class does not choose source records; the entity type's entity filters do.

Entity relationships. Upstream and downstream relationships between entities show how controls and risks affect each other and support roll-up reporting. Inheriting a parent's control results is done with common controls and reliant entities.

Scoping = applying GRC content to the right entities. When you associate control objectives (or policies) and risk statements (or risk frameworks) with an entity type, a control or risk is generated for each entity in it; that is scoping. Scoping can be done:

Manually (create an independent entity or add content to one entity), or
Dynamically via entity-type conditions so newly matching records automatically come into scope.

Implementation flow (typical): create entity classes (and class rules) and entity types → add entity filters on source tables with conditions → generate entities → relate entities (upstream/downstream) → associate control objectives and risk statements with entity types to generate controls and risks.

Key gotchas for the exam:

Distinguish entity (instance) vs entity type (definition/table+filter) vs entity class (tag for grouping and reporting).
Entities are the join point between org objects and GRC content; they are what controls and risks (and, through them, 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): Authority Document → Citation → Control Objective → Control → Control Test (and results).

Authority Document. The external mandate: a regulation, standard, framework, or law (e.g., PCI DSS, ISO 27001, SOX, NIST). It is the "where the requirement comes from." Internal rules are policies, which group control objectives.
Citation. A specific requirement/clause within an authority document (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 entity (the "how, here"). Controls are generated when a control objective (or its policy) is associated with an entity type, one control per entity. A control is the testable, owned instance.
Control Test. The procedure used to evaluate whether a control is operating effectively, generated from a test plan (often from a reusable test template). It is closed with the control effectiveness set to Effective or Ineffective, and an Ineffective result creates an issue with remediation tasks. Attestations and indicators are separate ways to evidence control status, and their failures also create issues.

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 associated with entity types (via entity scoping), which generates controls per in-scope entity. This is where Entity Scoping and PCM intersect, and it is 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.

UCF and GRC content packs. The Unified Compliance Framework (UCF) Common Controls Hub supplies authority documents, citations, and control objectives as shared lists, mapping many regulations to a deduplicated set of common controls. UCF-imported records are read-only; extend them with your own content and mappings. GRC content packs are separate Store apps with prebuilt content (for example dashboards and frameworks). Shared testing of one control for many entities is the separate common control feature (a common control with reliant entities).

Exam gotchas:

Control = scoped instance; Control Objective = reusable definition. Don't swap them.
Citation lives inside an authority document; control objectives map to citations.
Associating a control objective with an entity type 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 so large risk libraries stay organized. You associate risk statements to a framework. It does not define scoring: scales and thresholds come from risk criteria in classic risk, or from a risk assessment methodology (RAM) in Advanced Risk.

Risk statement. A reusable definition of a potential risk ("the thing that could happen"), independent of where it applies. Associating risk statements (or a risk framework) with an entity type generates risks (instances), one per risk statement per entity, in the risk register.

Risk (register). A risk is the scoped instance of a risk statement tied to an 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. Classic risk assessments use questionnaires built in the Risk Assessment Designer. Advanced Risk Assessment uses a risk assessment methodology (RAM) that defines the assessment types (inherent, control effectiveness, residual, target), the factors (manual, automated, scripted, group), scoring logic, and rating criteria; residual risk can be calculated from inherent risk and control effectiveness. Indicator results can also update risk scores. Reassessment can be scheduled (reassessment frequency, risk assessment scheduler).

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 Advanced Risk Assessment (RAMs; qualitative, semi-quantitative, and quantitative scoring such as ALE; score roll-up across risk statement and entity hierarchies), risk appetite and tolerance, and target risk assessment. Continuous monitoring for risks is a separate integration between Risk Management and Security Operations Vulnerability Response that uses indicators to flag high-impact vulnerabilities between formal assessments.

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, Third-party Risk) the customer needs, phasing, data sources (CMDB, HR, vendor data) feeding 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 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 (entities, entity types, indicators, common workflow/data model). Core apps: Policy & Compliance Management, Risk Management (with Advanced Risk), Audit Management, Third-party Risk Management (TPRM; legacy name 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: Third-party Risk Management (TPRM) (third-party/supplier risk and assessments; formerly Vendor Risk Management, renamed in Vancouver), 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.
Observations and issues: results of testing, interviews, and walkthroughs are recorded as audit observations; an observation confirmed as an issue (or a control test closed as Ineffective) drives 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, 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 (entities, entity types, indicators).
Entity = instance; Entity type = table + condition (definition); Entity class = tag for grouping/reporting. Profile = old (pre-New York) name for entity.
Scoping = associating control objectives and risk statements with entity types so controls and risks generate per entity; dynamic via entity filters.
PCM chain: Authority Document → Citation → Control Objective → Control → Control Test → results/issues.
Control Objective = reusable definition; Control = scoped, owned, testable instance (generated when the objective is associated with an entity type).
Risk chain: Risk Framework → Risk Statement (definition) → Risk (instance in register, one per entity) → 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 = Advanced Risk Assessment (RAMs: inherent, control effectiveness, residual, target) + risk appetite and tolerance. Continuous monitoring for risks = Risk + Vulnerability Response integration.
UCF Common Controls Hub = imported, read-only authority documents, citations, and control objectives (shared lists); GRC content packs = separate Store apps; common controls = test once, results inherited by reliant entities.
Audit: Engagement → plan/universe → fieldwork/tasks → observations/issues → remediation; reuses GRC controls & entities.
Extended: TPRM, BCM, Operational Resilience, Privacy, integrations (CMDB/SecOps), PA dashboards.
Roles: GRC Admin / Manager, Risk Manager, Compliance Manager, Audit Manager (least privilege).