Control Management: From Compliance Requirements to Entity-Level Controls & Scoring

Mary Hain · Monday

Effective control management begins by defining which assets, systems, departments, and processes are subject to compliance obligations—and connecting those obligations to testable controls in ServiceNow. Every organization already has a compliance universe, but it often lives across spreadsheets, institutional knowledge, and disconnected documents. The result is no reliable answer to the question auditors consistently ask: Which controls apply to which systems, and how can you prove it?

This Speed Learning explains:

The compliance chain from regulation to control
The entity framework used to structure the real world for compliance
How and when to use Entity Types, Classes, Filters, and Hierarchies
How compliance scores are calculated across six levels and two independent paths
The implementation sequence that enables automation to do the heavy lifting
How the framework applies across BFSI, Manufacturing, Oil & Gas, and Food & Beverage

Two principles guide the entire approach:

Entity modeling is the foundation. Nothing in P&C calculates correctly until the right objects are modeled as entities.
Sequence matters. Creating entity classes before entity types—and assigning roles from the top down—can prevent weeks of troubleshooting.

How it Works

The Compliance Chain

The compliance universe begins with a five-step chain: Authority Document → Citation → Control Objective → Control Objective Requirement → Control.

Authority Document: The external regulatory source, such as GDPR, HIPAA, or ISO 27001.
Citation: A specific clause extracted from the source, such as “Article 32: Encryption of personal data.”
Control Objective: What the organization must achieve.
Control Objective Requirement: An itemized statement of what must be true.
Control: A testable record generated for each in-scope entity when the Control Objective is mapped to an Entity Type.

Internal Policies follow a parallel path. A Policy and a Citation can both feed the same Control Objective, where external regulation and internal policy converge into one set of Requirements and Controls. Instead of creating separate controls for GDPR and an internal policy, the platform creates one control per entity from a shared Control Objective. This dual-feed model prevents duplication at scale.

Key distinction: Requirements define the what; entity mapping creates the controls. Control Objective Requirements are not scored independently and do not generate controls. Controls are generated when the Control Objective is assigned to an Entity Type. Enable the Create control requirements flag on the Control Objective to generate and attach requirement records; controls are still created if the flag is disabled.

The Entity Framework

Organizations manage thousands of real-world objects—people, applications, servers, vendors, production lines, and facilities. Without a common structure, compliance falls back to spreadsheets and cannot reliably show which controls apply to which systems. Entity modeling provides that structure. Once an object is modeled as an Entity, risks, controls, assessments, audits, indicators, and issues can be attached 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.

Do not confuse the two hierarchies: they serve different purposes.

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.

In short: use the Entity Class hierarchy for grouping and reporting; use the Entity hierarchy for compliance-score roll-up.

Scoping with Entity Filters

Scoping dynamically populates Entity Types from source tables. An Entity Filter combines three inputs:

Source table: CMDB, Company, Business Unit, HR records, or another authoritative source
Conditions: Filter logic, such as criticality = 1
Owner: The person or team responsible for the resulting entities

Entity auto-generation follows three rules:

No duplicates: The platform detects overlap and does not create the same entity twice, even when it matches multiple types.
Self-maintaining scope: When filter conditions or source records change, linked entities update automatically. For example, an application that becomes criticality 1 can join the Critical Assets type and inherit its controls without manual intervention.
One-way synchronization: Changes made in GRC do not modify the source table, preserving CMDB integrity.

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 itemized statements—R1, R2, R3—that define what must be true. They inform controls but are not scored independently and do not create controls.

Output 2 — Controls (sn_compliance_control records generated automatically—one per in-scope entity—when the Control Objective is assigned to an Entity Type. Each control has its own owner, tests, and score against the Requirements inherited from the objective.

The multiplication effect: Mapping one Control Objective—“Encrypt PII at rest”—to an Entity Type containing 50 databases automatically creates 50 controls, one for each database. Each control can then be owned and tested independently. This is how one governance decision becomes hundreds of trackable controls without manual creation.

Scoring and Roll-Ups

Compliance Score V2 recalculates scores every two minutes. It processes six levels in sequence, with each level completing before the next begins. Every control contributes to two scoring paths during the same run.

Compliance Library Path: “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.

Entity Hierarchy Path: “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.

Summary: The control is the foundation. When a control’s status changes, Compliance Score V2 picks it up in the next two-minute cycle and propagates the update through both paths—changing Control Objective, Policy, Citation, Authority Document, and Entity scores in the same run. Draft, Retired, and Not-applicable controls are excluded by default.

Implementation Sequence and Best Practices

Role Assignment: Five Top-Down Phases

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.

Principles for every phase:

Do not skip phases. Skipping creates isolated permissions and governance gaps.
Assign administrators before managers. This establishes a clear chain of command.

Avoid redundant roles. Each level already includes the access provided by the level below, and duplicate assignments complicate access audits.

Entity Framework Build Sequence

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 as production configuration. Review it regularly by asking:

Do filters and class rules still capture the right entities as source tables evolve?
Is each source table still authoritative, or should data be refreshed from an external system of record?
Are any entities orphaned or unintentionally detached from their type?

Use reports and dashboards to identify orphaned entities and configuration drift automatically rather than relying on manual checks.

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 Across Industries

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 challenge is primarily structural, not procedural. Three failure patterns recur when compliance operates 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: regulation-to-control and asset-to-score operate on the same platform and update together. A control attestation completed at 2:00 p.m. can update the Control Objective, Policy, Citation, Authority Document, and Entity scores before 2:02 p.m. Compliance posture becomes 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 add the weights of compliant controls, divide by the total weight of all controls, and multiply by 100. When set to FALSE, each control contributes equally. Control weights should reflect business risk, because a high-weight non-compliant control affects the Control Objective score 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.