Scoping Your Compliance Universe

Mary Hain · 42m ago

What is Scoping Your Compliance Universe?

Scoping your compliance universe is the process of defining which assets, systems, departments, and processes your compliance obligations apply to — and connecting those obligations to testable controls in ServiceNow. Every organization already has a compliance universe. The problem is usually that it lives across spreadsheets, tribal knowledge, and disconnected documents with no reliable answer to the question an auditor will always ask: which controls apply to which systems, and how do you prove it?

This Speed Learning covers the full scope: the compliance chain from regulation to control, the entity framework that structures the real world for compliance purposes, how Entity Types, Classes, Filters, and Hierarchies work and when to use each, how compliance scores are calculated across six levels and two independent paths, the implementation sequence that makes automation do the heavy lifting, and how the same framework applies across BFSI, Manufacturing, Oil & Gas, and Food & Beverage.

Two principles run throughout. First: entity modeling is the foundation — nothing in P&C computes correctly until the right things are modeled as entities. Second: get the sequence right — building entity classes before entity types, and assigning roles top-down, saves weeks of troubleshooting later.

How it Works

The Compliance Chain

The compliance universe starts with a five-step chain: Authority Document → Citation → Control Objective → Control Objective Requirements → Control. An Authority Document (GDPR, HIPAA, ISO 27001) is the external regulatory source. Citations are the specific clauses extracted from it — “Article 32: Encryption of personal data.” The Citation defines a Control Objective: what the organization must achieve. The Control Objective breaks down into Control Objective Requirements — the itemized “what needs to be true.” And the Control Objective, when mapped to an Entity Type, auto-generates one Control per entity in scope.

Internal Policies run a parallel path. A Policy feeds the same Control Objective that a Citation feeds. Both inputs — external regulation and internal policy — converge at the Control Objective, producing one set of Requirements and one set of Controls. You are not creating separate controls for GDPR and your own policy. One Control Objective, one control per entity, satisfying both. This dual-feed mechanism is what prevents duplication at scale.

One critical distinction: Requirements define the ‘what’; entity mapping creates the controls. Control Objective Requirements are never scored on their own and do not auto-generate controls — that job belongs entirely to the Control Objective’s assignment to an Entity Type. The ‘Create control requirements’ flag on the Control Objective must be enabled for requirement records to generate; without it, controls still auto-create, but requirements do not attach.

The Entity Framework

Every organization has thousands of real things — people, applications, servers, vendors, production lines, facilities. Without structure, compliance ends up in spreadsheets with no auditable answer to which controls apply to which systems. Entity modeling fixes that. Once something is modeled as an Entity, everything else in P&C — risks, controls, assessments, audits, indicators, and issues — can attach to it precisely.

Four components build the entity framework:

Entity is the individual real-world thing — a specific database, department, application, or vendor. It is the scored, controlled atom of the compliance universe.
Entity Type groups similar entities under shared ownership and controls. All ‘Critical Business Applications’ share the same controls because they share the same Entity Type. Assigning a Control Objective to an Entity Type auto-generates one Control for every entity of that type.
Entity Class is a cross-cutting reporting tag — ‘Database,’ ‘Business Unit,’ ‘Vendor’ — that groups entities across types for dashboards and reporting. Entity Classes are mandatory for all entities and are managed in GRC Workbench. One class per table via class rule; a type/filter assignment overrides the rule.
Entity Tier positions an entity in the reporting hierarchy from asset level to enterprise level. Tiers are optional and used for organizing the class hierarchy, not for scoring.

The key distinction that causes the most configuration mistakes: there are two separate hierarchies in the entity framework, and they each do different jobs.

Entity Class hierarchy (Company → Business Unit → Department → Process) is a reporting structure managed in GRC Workbench. It does not affect compliance scoring.
Entity hierarchy (built on each entity’s Hierarchy tab, parent-to-child) drives compliance score roll-up via the entity_hierarchy_based_scoring system property. This is the one that matters for scores.

Confusing them is the most common configuration mistake teams make. Class hierarchy is for grouping and reporting. Entity hierarchy is for scoring.

Scoping with Entity Filters

Scoping is the mechanism that populates Entity Types dynamically from source tables. It has three inputs: source table (CMDB, Company, Business Unit, HR records), conditions (filter logic — ‘criticality = 1’), and owner. Together these define an Entity Filter that auto-generates entities matching those conditions.

Three properties govern auto-generation. First, no duplicates — the platform detects overlap and never creates the same entity twice even if it matches multiple types. Second, self-maintaining — change the filter conditions and all linked entities update automatically; a new application that hits criticality 1 in CMDB joins the ‘Critical Assets’ type and inherits all its controls without manual action. Third, one-way sync — edits made in GRC do not affect the source table, keeping CMDB intact.

Entity state changes cascade downstream. Deactivate an entity and its controls, risks, indicators, and test plans retire. Reactivate and they revert to Draft. When a control retires, its indicators stop and open attestations cancel. The GRC Profile Generation job refreshes entities hourly to prevent drift and can be triggered on demand.

Anatomy of a Control Objective

A Control Objective has two distinct outputs, and understanding them prevents the most common data model mistake.

Output 1: Control Objective Requirements (sn_compliance_policy_stmt_requirement). These are the itemized breakdown of what the objective demands — R1, R2, R3. They define ‘what needs to be true.’ They are never scored on their own. They inform controls but do not create them.

Output 2: Controls (sn_compliance_control). Generated automatically — one per entity in scope — when the Control Objective is assigned to an Entity Type. Each control is individually owned, individually tested, and scored against the Requirements that came from the objective.

The multiplication effect: one Control Objective ‘Encrypt PII at rest’ mapped to Entity Type ‘Databases’ with 50 databases in scope auto-creates 50 controls — one per database, each individually owned and tested. That is how one governance decision becomes hundreds of trackable controls without manual creation.

Scoring and Roll-ups

The compliance score is calculated by Compliance Score V2, which runs every two minutes. It processes six levels sequentially — each level must complete before the next begins. One control feeds both scoring paths simultaneously on every run.

The Compliance Library path (steps 1–4) answers: “How compliant are we with this rule?”

Step 1 — Control Objectives: Weighted by default (cal_score_by_weighted_control = TRUE). Compliant control weights summed and divided by total control weights, multiplied by 100. When a Control Objective has only child Control Objectives, it averages those. When it has both child Control Objectives and direct controls, it blends the two averages equally (divides by 2). Weight assignments should reflect actual business risk — a high-weight non-compliant control moves a CO score more than a low-weight one.
Step 2 — Policies: Simple average of directly-associated Control Objective scores — no Control Objective-level weighting in the platform. A CO with two controls and a CO with twenty controls count equally at the policy level; only the CO score matters, not the control count beneath it. When a Policy also has child Policies, those are averaged and blended equally with the CO average.
Step 3 — Citations: Governed by the enable_association_of_citations_to_controls system property. When FALSE (default), a Citation averages the scores of its associated Control Objectives, using the same blending pattern for child Citations. When TRUE, Citations bypass Control Objective scores and score directly against their linked controls using the weighted formula — creating a tighter, more direct line from the regulatory clause to evidence.
Step 4 — Authority Documents: Simple average of all Citation scores. No weighting at this level — each Citation contributes equally regardless of importance. Weight differentiation for higher-risk clauses must be applied at the control level, not Citation or Authority Document level.

The Entity Hierarchy path (steps 5–6) answers: “How compliant is this asset?”

Step 5 — Entities: Governed by the entity_hierarchy_based_scoring property. When FALSE (default), an entity scores as a simple average of its directly-assigned controls only — upstream and downstream entity relationships do not factor in. When TRUE, a parent entity blends the average of its child entity scores with the average of its direct controls, equally. After switching this property to TRUE, the on-demand ‘Update compliance scores for hierarchy entities’ job must be run to recalculate all entity scores immediately.
Step 6 — Entity Types: Simple average of all entity instance scores belonging to that type. No blending, no weighting at this level. The Entity Type score rises or falls as individual entity scores update every two minutes.

The summary rule: the control is the foundation. Every time a control’s status changes, Compliance Score V2 picks it up in the next two-minute cycle and propagates the change up both paths simultaneously — moving Control Objective, Policy, Citation, Authority Document, and Entity scores in the same run. Draft, Retired, and Not-applicable controls are excluded from both paths by default.

Implementation Sequence and Best Practices

Role assignment: top-down, in five phases. Getting the sequence wrong creates governance gaps that take weeks to untangle.

Phase 1 — Governance: Assign sn_compliance.admin first — one to two people only. They establish system properties, create the compliance framework, and design the structure everyone else inherits.
Phase 2 — Domain Leadership: Assign domain admins (policy_admin, control_framework_admin, library_admin). They establish each domain’s framework and standards.
Phase 3 — Management: Assign managers (policy_manager, control_framework_manager, library_manager). Day-to-day operators who create policies, manage controls, and curate the library.
Phase 4 — Execution: Assign users (policy_user, control_framework_user, library_user) plus business users and readers. They execute policy tasks, respond to attestations, and report compliance status.
Phase 5 — Employee Access: Deploy employee readers last. Zero create permissions. The broadest group and the last to go live.

Three principles apply across all phases: don’t skip phases (skipping creates isolated permissions); admin must exist before managers are assigned (ensures a proper chain of command); and each level already contains the level below it, so assigning redundant roles creates confusion when auditing access.

Entity framework build sequence: seven steps in this order.

Upload source data (CMDB, Company, Business Unit records) — the foundation everything builds on.
Create Entity Tiers — the levels in your class hierarchy.
Create Entity Classes — the reporting tags that organize entities.
Create Entity Class Rules before Entity Types. Class rules do not retroactively apply to entities that already exist.
Create Entity Types with filters. They auto-generate entities, risks, and controls in bulk — no manual wiring.
Add manual entity exceptions — things that don’t fit any filter pattern.
Wire up the entity hierarchy. Enables risk-score roll-ups and, when entity_hierarchy_based_scoring is TRUE, compliance score roll-up through the entity tree.

Ongoing maintenance. Treat the entity framework like any production configuration. Revisit regularly with three questions: Are filters and class rules still catching the right entities as source tables evolve? Is the source table still authoritative, or does data need to be refreshed from an external system of record? Are any entities orphaned — unintentionally detached from their type? Use reports and dashboards to surface orphaned entities and drift automatically rather than catching this manually.

Data Maturity Model

Entity and compliance data matures in five stages, deliberately shared across Cyber, Enterprise, Operational, and Tech Risk domains so the same framework applies consistently.

Ad-Hoc: Manual, fragmented data. Authority Documents, Citations, Control Objectives, Controls, and Entities live in disconnected spreadsheets. Compliance scoring is manual or absent.
Systemized: Entity framework and compliance chain consolidated. Source tables become Entities with Type, Class, and Tier definitions. Authority Documents, Citations, and Control Objectives are defined. Control Objectives begin auto-generating Controls via Entity Type mapping. The compliance chain begins.
Optimized: Automated entity generation. Entity Type rules auto-generate compliant entities with no duplication. State cascading keeps entities current. Domain-specific processes automate asset classification, data mapping, policy updates, control audits, and risk assessments.
Connected: Real-time compliance scoring connected across domains and entity hierarchy. Control scores roll up through both independent paths simultaneously. Stakeholders see unified compliance truth from every angle.
Integrated: Live, automated compliance universe embedded in operations. Compliance scoring runs continuously on live data. Every operational action — a new system added, a control completed, an entity reclassified, a vulnerability detected — immediately flows through the compliance universe.

One Framework, Every Industry

The same Tier → Class → Type → Entity structure holds across industries. Only the labels and filters change.

BFSI: Enterprise → Line of business → Business unit → Application. Built to aggregate risk across lines of business and jurisdictions.
Manufacturing: Site → Facility/area → System → Asset. Model only what you will test, not every asset on the floor.
Oil & Gas: Installation → Plant/unit → System → Equipment. Scope by criticality, not asset count.
Food & Beverage: Site → Production line → Process step → CCP (HACCP critical control points). Entities are the points in the production process where hazard control is mandatory.

Why it Matters

The compliance universe problem is not a process problem. It is a structural problem. Three failure patterns repeat across every organization that runs compliance outside a governed framework.

Compliance that exists on paper but can’t be proven. An organization can have every regulation mapped in a spreadsheet and still fail an audit because there is no reliable answer to “which specific control applies to which specific system, and who owns it?” Entity modeling closes that gap by anchoring every control to a real, owned thing. When an auditor asks for evidence, the trail runs from the regulatory clause through the entity to the test result — on one record, without reconstruction.

Scores that don’t reflect reality. The most common cause of misleading compliance percentages is a configuration error: the wrong hierarchy driving roll-up, the wrong system property set, or Draft controls silently excluded from scoring. Understanding the two separate hierarchies, the two system properties that gate scoring behavior (entity_hierarchy_based_scoring and enable_association_of_citations_to_controls), and the two-minute Compliance Score V2 cycle means you can explain and defend every number in a board report. Teams that do not know the scoring mechanics treat their dashboard as a black box.

Manual effort that scales badly. A compliance program built on manual control creation and manual entity assignment hits a wall somewhere between 200 and 500 controls. The automation built into the entity framework — Entity Type filters, Class Rules, auto-generated controls, cascading state changes — is specifically designed to remove that ceiling. One Entity Type filter attached to a CMDB query auto-generates entities and controls every time a new asset meets the criteria. One Control Objective mapped to that type maintains the control register from that point forward. The organizations that stay current at 10,000 controls are the ones that built the filter correctly on day one.

The platform advantage is that both sides of the equation — regulation-to-control and asset-to-score — live on the same platform and update simultaneously. A control attestation completed at 2 pm moves the Control Objective score, the Policy score, the Citation score, the Authority Document score, and the Entity score before 2:02pm. That is what makes compliance posture a live operational signal rather than a quarterly report.

FAQ: Entity & Compliance Framework

Entity Modeling

Can one entity have multiple control owners?

Yes. The entity owner and the control owner are separate roles. The entity owner is assigned to the entity record itself; the control owner is assigned to each individual control on that entity. Each is assigned to their own designated team.

Can an entity belong to multiple entity types?

Yes. An entity links to all types whose filter it matches. No duplicates are created — the platform detects overlap. A type/filter assignment on the entity type overrides a class rule when there is a conflict.

Do entity types create controls automatically?

Yes — relate a Control Objective to an Entity Type and one control is auto-created per entity in scope. The generation is asynchronous and runs through the item generation queue. By the next job cycle, every entity of that type has a control linked to the Control Objective.

What happens when I change an entity filter?

Out-of-scope entities and all their associated controls are retired, not deleted. In-scope entities and controls update automatically. If an entity re-enters scope — because a filter condition is relaxed or the underlying source record changes — the entity is reactivated and controls revert to Draft.

Does the class hierarchy drive compliance score roll-up?

No. Only the entity hierarchy (parent-to-child links on the entity’s Hierarchy tab) drives compliance score roll-up, and only when entity_hierarchy_based_scoring is set to TRUE. The Entity Class hierarchy is for reporting and grouping only. Confusing the two is the most common configuration mistake in entity framework deployments.

Where should entity data come from?

Reuse authoritative tables — CMDB, Company, Business Unit, HR records — as your single source of truth. Avoid standalone manual data wherever possible. Manual entities require manual maintenance and drift from the source record; filter-generated entities maintain themselves automatically.

What is a Control Objective Requirement?

An itemized breakdown of what a Control Objective demands (sn_compliance_policy_stmt_requirement). One Control Objective can hold many requirements. Requirements are never scored on their own and do not auto-generate controls — that job belongs to the Control Objective’s assignment to an Entity Type. The ‘Create control requirements’ flag on the CO must be enabled for requirement records to generate.

Do we test requirements or controls?

Controls. Controls are the tested, weighted leaf node of the compliance model. Requirements define the ‘what’ and inform how the control is tested, but they are never scored independently.

Are entity tiers mandatory?

No. Tiers are optional. Entity Classes are mandatory for all entities. Tiers are organizational groupings that help structure the class hierarchy for reporting purposes — they do not affect scoring or control generation.

Compliance Scoring

Which controls count toward the score?

Only controls with Compliant or Non-compliant status. Draft controls are in active states but produce no score because they have no compliance status yet. Retired and Not-applicable controls are excluded by status. This means a control must be fully attested or tested before it contributes to any scoring path.

Is the score weighted or a simple count?

Weighted by default (cal_score_by_weighted_control = TRUE😞, compliant weights summed, divided by all control weights, multiplied by 100. When FALSE, each control contributes equally regardless of weight. Weight assignments should reflect actual business risk — a high-weight non-compliant control will move a Control Objective score significantly more than a low-weight one.

How do policies and authority documents score?

Both use simple averages of their direct child scores — Policy averages its Control Objectives; Authority Document averages its Citations. Weighting applies only at the control level. There is no Control Objective-level or Citation-level weighting in the platform. If higher-risk clauses need to carry more influence at the Authority Document level, that must be reflected in the weights assigned to the controls under those Citations.

What sets whether downstream entities factor into an entity’s score?

The entity_hierarchy_based_scoring system property. TRUE: blends downstream entity scores with direct control scores equally. FALSE (default): entity score is the average of its direct controls only, and parent-child entity relationships do not factor in. After switching to TRUE, the on-demand ‘Update compliance scores for hierarchy entities’ job must be run to recalculate all entity scores and refresh immediately.

How often does the compliance score update?

Compliance Score V2 runs automatically every two minutes. On-demand jobs for entity hierarchy recalculation and all Citations/Authority Documents can be triggered manually from Scheduled Jobs. One control attestation or test result will propagate through both scoring paths within the next two-minute cycle.

What is the scoring processing order?

Sequential and bottom-up: Control Objectives → Policies → Citations → Authority Documents → Entities → Entity Types. Each level depends on the level below being fully calculated first. Running concurrently would produce scores based on incomplete lower-level data. The strict sequential order is what makes the score trustworthy.

Some Useful Resources

Visit the ServiceNow product documentation or join the conversation on the ServiceNow GRC Community to discuss entity modeling and compliance scoping with other ServiceNow practitioners.