When working with Governance, Risk, and Compliance (GRC) in ServiceNow, one of the most important things to understand is how the underlying data model is structured. The slide we’re looking at provides a high-level overview of the core tables that drive GRC functionality—covering everything from regulatory compliance to risk management and policy enforcement. At first glance, it may seem complex, but once you understand the relationships between these tables, the architecture starts to make a lot more sense. Each box in this diagram represents a table in ServiceNow, and as with everything in the platform, every table stores records that power the GRC applications. In this walkthrough, we’ll break down these major tables—how they interact, what role they play, and how they support an integrated and scalable approach to managing compliance, policies, risk, and regulatory change.
Starting on the left, the Authority Documents and Citations tables are foundational. Authority Documents serve as high-level representations of external regulations or standards—think of PCI DSS, GDPR, or ISO 27001. Each authority document is a parent to numerous Citations, which represent the specific legal or regulatory requirements—the granular “must-do” items that organizations must comply with. For example, a PCI DSS authority document may contain hundreds of citations, each detailing a different compliance requirement.
Moving rightward, we find the Policy and Control Objective tables. These capture internal organizational policies and the measurable goals derived from them. Policies are the internal equivalent to Authority Documents—strategic, top-level guidance. Each policy can have multiple control objectives that define how the policy will be enforced or tested. For instance, a Facility Management policy might include control objectives like maintaining a business continuity plan or testing emergency procedures. Notably, these control objectives can be directly mapped to citations from authority documents, creating a clear bridge between external requirements and internal responses. This mapping allows organizations to reuse and align compliance efforts across multiple regulations, greatly improving efficiency.
The next major component in the architecture is Risk Management. The Risk Framework and Risk Statements tables are used to define and group various risks. While Risk Frameworks serve more as high-level categories or containers, Risk Statements describe specific risks. With Advanced Risk enabled, organizations can create hierarchical risk structures, meaning one risk can be broken down into several sub-risks, allowing for more detailed and structured risk analysis. For example, an "Information Technology Risk" might include sub-risks like IT operations, infrastructure, and performance, helping stakeholders drill down into precise risk areas.
Complementing this structure is the Entity model, which defines the scope for which risks and controls apply. Entities are grouped by Entity Types and classified by Entity Classes. When a control objective is associated with an entity type, ServiceNow automatically generates individual Control records for each entity under that type. This same principle applies to Risk Statements—each entity will have its own risk record created when associated with a risk statement. This scoping mechanism ensures controls and risks are assigned to relevant business units, applications, or departments, allowing for tailored assessments and monitoring.
At the heart of day-to-day GRC operations are the Control and Risk tables. These are the records where most of the actual management work happens. For Controls, we rely on supporting tables like Test Plans, Indicators, Issues, and Response Tasks. These help assess whether controls are effective and ensure that any problems are addressed. Similarly, the Risk table is supported by risk-specific indicators and response tasks. An important note here is that the Indicator and Issue tables serve both Compliance and Risk use cases and include a flag to differentiate the context.
Assessments also play a crucial role. In Compliance, we use Control Attestations to validate the effectiveness of controls, while Risk leverages Risk Assessments and Advanced Risk Assessments to evaluate risk posture. This dual-assessment system provides the necessary evidence for both compliance and risk mitigation efforts.
A critical connection in the GRC ecosystem is the relationship between Controls and Risks. This is more than just technical linkage—it reflects the real-world logic that we manage controls primarily to mitigate risks. This alignment allows organizations to evaluate whether their control environment is effectively addressing the risks that matter most.
Lastly, we have the Regulatory Change management layer. As regulations like PCI DSS evolve, organizations must adapt. If a new version of a regulation changes a password policy requirement from 90 to 60 days, that change must cascade from the Citation through the Control Objective and into operational controls. Regulatory Change functionality helps track, evaluate, and implement such changes, ensuring ongoing compliance.
Source: ServiceNow nowlearning course, IRM Implementation
If the above information helps you, Kindly hit a like.
Thanks and Regards,
Najmuddin.
