Mary Hain
- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
2 hours ago - edited 44m ago
Most teams learn Policy and Compliance Management (P&C) by navigating the user interface. This session takes a more durable approach: start with the data model so the rest of the platform makes sense. You'll learn how three architectural layers separate policy intent, operational implementation, and governance; why Control Objectives serve as the hub connecting regulations to policies; how compliance data flows from a regulation to a scored control; and how the six-step scoring engine produces a defensible enterprise compliance percentage.
What is the P&C Architecture and Data Model?
The Policy and Compliance (P&C) Architecture and Data Model is the structural foundation for organizing, connecting, and scoring a compliance program in ServiceNow — from external regulations and internal policies to individual controls, issues and remediation tasks. Understanding it early means building it correctly the first time; teams that skip it tend to discover the gaps months into deployment, once a compliance report comes back and the numbers don't add up.
This Speed Learning covers the full foundation: the plugin ecosystem, the three-layer architecture, the four GRC base objects, and the major data entities — Control Objectives, Authority Documents, Policies, Policy Exceptions, Controls, Indicators, Issues, and the Compliance Score Rollup. Acknowledgment campaigns, Smart Assessment Engine configuration, and audit integration are covered in their own dedicated Speed Learnings.
Three principles anchor the model:
- Structure: Three layers serve distinct purposes.
- Relationships: Many-to-many connections reduce duplication.
- Scalability: Assigning one policy to an Entity Type can generate thousands of consistent controls automatically.
Watch the video tutorial in the Speed Learning playlist on YouTube to explore the full end-to-end capabilities.
How it works
The Plugin Ecosystem
P&C is a coordinated family of plugins, not a single application — a mandatory core plus optional extensions you add as program needs evolve.
Mandatory. GRC: Policy and Compliance Management (sn_compliance) is the core engine, centralizing policy and control management and mapping them to external regulations. GRC: Compliance Management Workspace (sn_compliance_ws) is where the compliance team works day to day. Knowledge
Management Advanced (sn_km_advanced) publishes approved policies to the Knowledge Base automatically. The Smart Assessment Engine (platform assessments) drives control attestations and is the recommended path for every new implementation, replacing Classic Assessments.
Optional. GRC: Unified Compliance Framework (UCF) provides pre-built Authority Documents, Citations, and Control Objectives for NIST, CIS, ISO 27001, and other standards. GRC: Risk Management and GRC: Audit Management connect compliance to the broader risk and audit ecosystem. Content Packs and Accelerators (SOX, Financial Services, Cybersecurity, NIST CSF, Technology Controls Monitoring) provide scoped pre-built frameworks. AI and Agentic capabilities (Otto for IRM, IRM Compliance GenAI, AI Risk and Compliance Management) automate routine compliance work.
Activate the mandatory core, then layer on what your program scope requires — adding a capability later never means rebuilding the foundation.
The Three Layers
The P&C system separates data into three architectural layers, each owning distinct data and supporting a different audience.
The Compliance Library (“the Framework”) is the regulatory and policy intelligence layer. Authority Documents and Policies enter here, Citations are extracted from regulations, and everything converges in Control Objectives. The Framework defines what should be done.
The Compliance Register (“the Register”) is the operational layer. It defines Entities — departments, systems, processes — generates Controls and Control Requirements for each, monitors effectiveness through Indicators, and tracks Issues as gaps emerge. The Register defines who does what and how it's validated.
The user-experience layer spans three lines of defense.
- First Line (Risk Portal / GRC Tasks): employees acknowledge policies, request exceptions, report issues, complete attestations, and submit evidence.
- Second Line (Compliance Workspace): the compliance team authors policies, manages control lifecycles, runs attestations, and remediates issues.
- Third Line: Risk Management and Audit connect Risks and Audit Control Tests to the compliance picture.
This separation keeps change manageable — a new regulation updates the Framework, a new department extends the Register, and neither requires touching the other.
The GRC Core Foundation
P&C extends four base objects from the broader GRC platform, giving Policy, Compliance, Risk, and Audit consistent attributes such as owner, status, and lifecycle state through inheritance.
- Document (sn_grc_document : the base class for authoritative sources. Authority Documents and Policies are both Documents.
- Content (sn_grc_content : material extracted from a Document. Citations, Control Objectives, and Control Objective Requirements are all Content — for example, “Article 32 — Encryption of personal data” is a Citation, “Implement encryption for sensitive data at rest and in transit” is a Control Objective, and “All databases must use AES-256 encryption” is a Control Objective Requirement.
- Base Indicator (sn_grc_base_indicator : the template defining what to measure and the pass/fail threshold; actual Indicators are created from it.
- Item (sn_grc_item : the generic container that Controls, Control Requirements, and Risks extend.
Several Register objects — Issue Triage, Evidence Request, Remediation Task, Indicator Task — also extend the Task system, inheriting workflow, assignment, and escalation automatically. That's why the Register functions as a unified operational system.
Control Objectives — the hub
Control Objectives (sn_compliance_policy_statement) are the architectural center of the data model — the point where external regulatory requirements and internal policies converge into a single, unified control requirement. Citations map many-to-many to Control Objectives on one side; Policies map many-to-many on the other. A single Control Objective can satisfy a GDPR requirement and your internal data protection policy at once — you define the requirement once, not twice.
From each Control Objective, Control Objective Requirements (sn_compliance_policy_stmt_requirement) flow down as testable obligations, connecting to Controls through the CO-to-CO-Req and CO-Req-to-Control bridge tables. Control Objectives are also assigned to Entity Types (sn_grc_profile_type) — that assignment triggers automated, asynchronous generation of one Control per Entity of that type.
The lifecycle — Draft, Review, Approved, Published, Retired — governs change; a Control Objective must be reviewed and approved before it goes live and starts generating controls. Define the standard once, assign it to the right Entity Types, and the system builds and maintains the control register for you.
Authority Documents & Citations
Authority Documents (sn_compliance_authority_document) are complete regulatory or standards sources — GDPR, HIPAA, PCI-DSS, SOX, ISO 27001. Each contains Citations (sn_compliance_citation), the specific requirements extracted from that source. The CO-to-Citation bridge table (sn_compliance_m2m_statement_citation) connects them many-to-many — one Citation can inform multiple Control Objectives, and one Control Objective can draw on Citations from multiple Authority Documents. This is how cross-framework rationalization works.
GRC: Compliance UCF provides this layer pre-built: activating a UCF content pack delivers Authority Documents, Citations, and Control Objectives already mapped for that framework. Content Packs and Accelerators extend UCF for specific domains — SOX, cybersecurity (NIST CSF, CIS), financial services, and technology controls monitoring.
Policies & Acknowledgements
A Policy (sn_compliance_policy) is a formal organizational statement with Type, Classification, and Category attributes, following its own lifecycle: Draft, Review, Awaiting Approval, Published, Retired.
Publishing a Policy triggers two things automatically: a Knowledge Base article (through Policy Templates) so employees can discover and read it in the Knowledge Base and Employee Center, and the option to launch Acknowledgment Campaigns targeting specific audiences. The system tracks who acknowledged, when, and under which version — an auditable record of communication effectiveness.
The scale mechanism is the same one Control Objectives use: attach a Policy to Entity Types, and the system generates the control registry for every entity of that type. One Finance Policy attached to the Finance Entity Type cascades control generation across every Finance entity.
Policy Exceptions
Policy Exceptions (sn_compliance_policy_exception) turn untracked violations into governed, auditable deviations — a third option beyond rigid enforcement or undocumented non-compliance.
Each exception specifies the Policy and Control Objective it applies to, the Impacted Controls being suspended, and the Mitigating Controls compensating for the residual risk. You're documenting the trade-off, not accepting unmanaged risk.
The lifecycle runs New, Analyze, Review, Awaiting Approval, Approved, Closed, with an expiration date that forces re-evaluation. Three configuration elements drive setup: the Integration Registry (how exceptions connect to Risk Management and Audit), Reason Choices (the dropdown options for why the exception was needed), and Related Records configuration (linking the exception to the Issues, Risks, and Controls that informed it).
Controls, Entities & Attestations
An Entity (sn_grc_profile) — a department, system, or process — is the target of control. Entities are instantiated from Entity Types (sn_grc_profile_type), which serve as templates. Assigning a Control Objective or Policy to an Entity Type queues one Control per Entity of that type through the item generation queue (sn_grc_item_generation_action_event_queue), populating the register automatically in the background.
A Control (sn_compliance_control) is a specific action on a specific Entity. The many-to-many Control-to-Entity bridge table (sn_compliance_m2m_control_entity_lin) lets one “User Access Review” control apply to Finance, HR, and IT simultaneously — same definition, different owners and schedules, each satisfying the same Control Objective.
Proving a control works requires Attestation: the control owner provides point-in-time verification through an Assessment Instance, ideally using the Smart Assessment Engine. The Reliant Entity mechanism lets child entities inherit a parent's testing result — test once at the parent level, eliminate duplicate effort across the hierarchy.
Indicators, Issues & Remediation
Indicators (sn_grc_indicator) provide continuous, automated monitoring — the complement to point-in-time attestation. Where attestation answers “did we test this?”, Indicators answer “does this work continuously?”
An Indicator Template (sn_compliance_indicator_template) tied to a Control Objective defines what to measure; the Indicator created from it links directly to a Control. Every execution generates an Indicator Result (sn_grc_indicator_result) — Pass or Fail — and a failed result automatically creates an Issue. Execution runs on a three-queue parallel pipeline (GRC nightly run → Batch Indicator data queue → Batch processor → Supporting data queue → Data collection job), scaling to thousands of indicators without performance loss.
Three indicator types cover different needs: Query-based (run against the database), Manual (assigned to people to verify), and Script (custom business logic). Attestations, Indicators, and Audit Control Tests (sn_audit_control_audit_test) operate as three parallel, complementary inputs — all three feed the compliance score.
Issues (sn_grc_issue) are the unified record for every compliance finding, regardless of source — failed indicators, audit findings, employee reports, policy violations, and control testing failures all land in the same table, so one event can be a policy violation, a risk manifestation, and an audit finding at once, with full traceability.
The Issue lifecycle runs New → Analyze → Respond → Review → Closed. After creation, Issue Triage (sn_grc_advanced_issue_triage) is where the compliance team classifies severity and assigns ownership; the Issue then becomes a Remediation Task assigned to an entity owner with a due date. Issues can be grouped hierarchically — a parent issue with child issues for related findings — so one remediation addresses multiple findings. Three configuration elements govern behavior: Issue Source (where issues originate), Issue Rating (how severity is classified), and Issue Group Rules (which issues group into parent-child hierarchies).
Compliance Score Rollup
The Compliance Score answers the question every program needs answered: how compliant are we? The calculation is a strict six-step, bottom-up traversal that must complete each layer before the next begins.
- Step 1 — Controls: scored on test results and attestation status; Draft, Retired, and N/A controls are excluded from the denominator.
- Step 2 — Policies: Control scores roll up to the Policies they support.
- Step 3 — Citations: Control scores also roll up to the Citations that informed their Control Objectives.
- Step 4 — Authority Documents: Citation scores aggregate up to the Authority Document level.
- Step 5 — Entities: Entity scores aggregate from direct controls. The entity_hierarchy_based_scoring property governs whether child scores propagate to parents — FALSE (default) means direct controls only, TRUE adds downstream entity scores. The two modes can report materially different numbers for the same program; choose deliberately.
- Step 6 — Entity Types: Entity scores aggregate to the Entity Type level for enterprise-level compliance posture.
The calculation runs through a scoring queue (sn_compliance_compliance_score staging table). A second property, enable_association_of_citations_to_controls, gates whether citation-control relationships are included — review both properties before any scoring configuration.
Why it matters
Architecture knowledge directly improves implementation outcomes. Teams that skip the data model tend to hit the same three failure patterns.
Configuration mistakes that surface late. The costliest errors are structural — policies mapped to the wrong objects, entity hierarchies that produce misleading scores, plugins activated in the wrong order. They surface when the first compliance report comes back and the numbers don't add up. Knowing the three layers, the four base objects, and the Control Objective hub before configuring means building it right the first time.
Troubleshooting that stops at “open a ticket.” When indicators stop producing results, scores stop updating, or controls stop generating for a new Entity Type, the answer is always in the data flow: trace the execution queue for indicators, check system properties and calculation order for scores, check the item generation queue and CO-to-Entity-Type assignment for controls. Teams that know the model resolve these in minutes instead of escalating.
Scaling programs that keep breaking. Attach a Control Objective to an Entity Type once and the system maintains the control register as entities are added. Use entity hierarchies and Reliant Entity inheritance to test once and propagate results down. Rationalize controls across systems with many-to-many relationships so one requirement doesn't produce duplicate controls everywhere. Teams that hit a wall at 500 controls are usually the teams that customized the core instead of extending it.
The platform advantage is integration. When a control fails an indicator, the failure creates an Issue linked to the Policy, the Authority Document Citation, and the Entity that owns the control — an auditor can follow the full chain without leaving the record. That traceability is built into the model; you inherit it by building correctly.
FAQ: P&C Architecture and Data Model
Architecture & Layers
What is the difference between the Compliance Library and the Compliance Register? The Library (“the Framework”) is the regulatory and policy intelligence layer, where Authority Documents, Citations, Policies, and Control Objectives live — it defines what should be done. The Register is the operational implementation layer, where Entities, Controls, Indicators, and Issues live — it defines who does what and how it's verified. The Framework is change-controlled and relatively stable; the Register is operationally active and continuously updated.
Why does P&C build on four GRC base objects instead of its own tables? Because inheritance — consistent attributes like owner, status, and lifecycle state across Policy, Compliance, Risk, and Audit — is what lets issues be shared across modules, risks appear on compliance records, and audit findings link to controls without custom integration work. The inheritance model is the integration model.
Plugins & Scoping
Which plugins are truly mandatory? Three: GRC: Policy and Compliance Management (sn_compliance) as the core engine, GRC: Compliance Management Workspace (sn_compliance_ws) as the primary interface, and Knowledge Management Advanced (sn_km_advanced) for Knowledge Base publication. UCF, Risk integration, Audit integration, AI capabilities, and Content Packs are all optional and scoped to your use case.
What is the Smart Assessment Engine, and is it required? It's the modern assessment framework built on platform assessments (sn_assessment_core), driving control attestations through intelligent questionnaires and automated analysis. It's required for all new implementations — Classic Assessments are maintained for backward compatibility only, and future attestation enhancements will build on Smart Assessment Engine.
Control Objectives & Data Model
Why are Control Objectives called “the hub”? Because every major data entity in P&C feeds into or flows out of a Control Objective: Citations and Policies map in, Policy Exceptions reference them, Control Objective Requirements flow down from them, Entity Types assigned to them trigger Control generation, Issues link back to them, and compliance scores roll through them. Understanding a Control Objective's state means understanding the compliance posture of whatever it governs.
What is the difference between a Control Objective Requirement and a Control Requirement? A Control Objective Requirement (sn_compliance_policy_stmt_requirement) is a framework-level obligation flowing from a Control Objective — it lives in the Library. A Control Requirement (sn_compliance_control_requirement) is the operational implementation of that obligation on a specific Control attached to a specific Entity — it lives in the Register. Bridge tables connect them many-to-many: one Control Objective Requirement can be satisfied by many Control Requirements across many systems.
Authority Documents & Policies
What is the difference between an Authority Document and a Policy? Both are types of Document in the GRC base model. An Authority Document is an external source — a regulation, standard, or framework (GDPR, HIPAA, ISO 27001). A Policy is an internal organizational commitment. Both map to Control Objectives, but from opposite directions: Authority Documents map through Citations, Policies map directly.
What is the difference between Impacted Controls and Mitigating Controls on a Policy Exception? Impacted Controls are the controls being suspended by the exception — the obligations the requester cannot currently meet. Mitigating Controls are the compensating controls put in place to manage the residual risk that suspension creates. Both are required in a well-governed exception.
Controls, Indicators & Scoring
What is the difference between an Attestation and an Indicator? An Attestation is manual, point-in-time control testing — a control owner responds to an assessment questionnaire to verify effectiveness. An Indicator is automated, continuous monitoring — it runs on a schedule and generates Pass/Fail results automatically. The two are complementary, not interchangeable.
Why does the Compliance Score calculation run in a strict six-step order? Because each layer's score depends on the previous layer completing first: Policy and Citation scores depend on Control scores, Authority Document scores depend on Citation scores, and Entity Type scores depend on Entity scores. If the calculation ran concurrently, a layer could score against incomplete data from the layer below. Review the two gating system properties — entity hierarchy scoring and citation-to-control association — before your first scoring run, since both change what data the calculation includes.
Some useful resources
Visit the ServiceNow product documentation or join the conversation on the ServiceNow GRC Community to discuss P&C architecture with other ServiceNow practitioners.
