ServiceNow Governance, Risk and Compliance: Security and Access Design

Role-Based Access Control and Data Compartmentalization

Governance, Risk and Compliance modules often contain sensitive information—audit findings, control weaknesses, pending investigations. Access control must prevent unauthorized exposure while enabling necessary visibility. A core role model includes risk owners (track risks and manage remediation), compliance officers (manage controls and compliance evidence), internal auditors (test controls and document findings), and executives (review risk and compliance dashboards). Some organizations add audit committee roles (board-level oversight) or external auditor roles (view findings and evidence).

Risk and compliance data is often compartmentalized. Certain business units or functions manage their own risks and controls—finance owns financial controls, IT owns security controls, operations owns process controls. Access control should enforce compartmentalization—a business unit manager sees their unit’s risks, internal audit sees all risks, executives see only risks above a threshold. This requires thoughtful role and data scope design.

Least Privilege Access and Segregation of Duties

Least privilege means each role gets exactly the permissions needed. Risk owners document risks and management plans; they shouldn’t be able to approve risk acceptance or close findings without review. Compliance officers configure controls and track evidence; they shouldn’t approve control testing without independent validation. Internal auditors test controls and document findings; they shouldn’t modify findings based on management feedback without audit independence.

Segregation of duties prevents conflicts of interest. Separate the person who identifies a risk from the person who approves accepting it. Separate the person who runs a control from the person who tests it. Separate the person who proposes a remediation from the person who approves it. This ensures review and accountability. Document segregation rules clearly—who can do what actions, and who must review before action is final.

Internal Audit Independence and Evidence Protection

Internal audit must be independent to be credible. Auditors should not approve risks, accept risk tolerances or approve remediation plans—doing so creates appearance of conflict. However, auditors need full read access to risks, controls, evidence and testing results across the organization. Access control must enable this independence—broad read access, limited write access, no ability to change findings after testing.

Evidence protection is critical. Audit findings and control testing evidence may be reviewed by external auditors or regulators. Protect evidence from modification—ideally, evidence is immutable once recorded. If changes must be made, maintain audit trails showing what changed, when and by whom. Some organizations use digital signatures or tamper detection to ensure evidence hasn’t been altered.

Executive and Board-Level Reporting Access

Executives and board audit committees need visibility into enterprise risk and compliance status without detailed operational data. Access control typically restricts executives to summary dashboards—top risks, open findings, remediation status. Details are available on demand but not default. Board members (often external) need read-only access to findings, evidence and testing results relevant to board oversight—usually financial controls, data security and compliance with major regulations.

Carefully scope board access. Board members shouldn’t have access to sensitive operational findings or employee investigations. They need evidence of control testing and audit independence—did independent auditors test controls? Were findings reported accurately? Scope access by audit topic or risk category if possible.

External Auditor and Regulator Access

External auditors need access to controls, evidence and findings in scope of their audit. This is usually read-only and time-limited—access expires when the audit ends. Scope access carefully: financial auditors get financial controls and evidence; security auditors get security controls and evidence. Most external auditors access via a dedicated login, not shared accounts. Maintain audit logs of who accessed what and when.

Regulatory access is trickier. Some regulations require regulators to access findings and evidence during inspections. Others require annual reporting of control assessments. Determine what data is required by regulation and plan access accordingly. Some organizations use a separate, read-only compliance portal for external access rather than giving direct system access.

Control Access and Configuration Management

Control configuration (what controls exist, how they’re tested, what evidence is required) should be restricted to compliance officers or control owners. Changes to control configuration may affect audit scope—if you change how a control is tested, prior testing results may not be comparable. Document configuration changes and maintain change history. Some organizations require approval for control configuration changes.

Control evidence (test results, audit logs) should be protected from modification. Ideally it’s immutable, or if changes are needed, tracked with audit trail. Restrict write access to control evidence to authorized testers and auditors only. Managers shouldn’t be able to modify control test results.

Audit Evidence and Review Cycle

Maintain quarterly access reviews: list active users by role, verify role matches job function, revoke stale accounts, document the review. This catches role creep and unauthorized access. For sensitive roles (auditors, compliance officers), consider more frequent reviews (monthly). Track access changes—who got access when, who lost access, why. Some organizations require multi-level approval for access to sensitive data (risk findings, audit evidence).

Test access control regularly. Try accessing findings as a business unit user—verify you see only your unit’s risks. Try as an external auditor—verify time limits are enforced. Try modifying evidence—verify it’s protected. Document test results and fix any issues found.

Classifying GRC records by the harm an unauthorized view would cause

Not every risk record deserves the same audience. A risk about a pending regulatory penalty, a finding about a named individual’s conduct and a control gap in a commercially sensitive system carry different exposure if the wrong group sees them. The first design task is to classify records by the harm an unauthorized view would do, then set a default visibility for each class. Treat the table as a draft to argue over, not a fixed policy.

An ordered review of GRC role membership each quarter

1. Export the current members of each GRC role group, with the date each membership was granted.
2. Match every member to an active approval in the accountability matrix. Anyone without one is a candidate for removal.
3. Check group nesting, because a user added to a broad group can inherit visibility nobody intended.
4. Review any standing elevated access against the expiry date recorded when it was granted.
5. Record the outcome, the names removed and the approver, and keep that record with the evidence it supports.

Troubleshooting visibility that is too wide or too narrow

When a user reports seeing records they should not, the cause is often inherited group membership rather than a role on the record itself. When a user cannot see a record they need, check whether its class changed after they were granted access, because a reclassification can silently remove a visibility path. Exports are a separate route. A report a user can run may include fields the on-screen view hides, so test exports with a user from each group before a new report is published, and treat any export carrying restricted fields as a change request. The platform-level checks beneath these symptoms are on the access controls review page.

Delegated approvals and break-glass access

Delegation is necessary when an approver is away, but it should be time-bounded and visible. A delegated approval recorded without an end date tends to outlive the absence it was made for. Break-glass access for GRC is rarer and should exist only where a regulator or an urgent remediation needs it. Every use should leave a note on the record and get reviewed by someone outside the group that used it. Platform-wide rules for elevated roles are described in the instance security and access control governance model.

Questions teams ask about GRC access

Should internal audit have read access to every GRC record?

Internal audit needs enough access to test controls and trace evidence, which is wider than a manager’s view but not automatically every record. Set access by engagement and record class, and keep a note of what each engagement was given.

Can an executive who receives board reporting also edit the underlying risk?

That combination weakens the line between the person who decides and the person who records. Give executives reporting access and keep edit rights with the risk owner, unless the matrix says otherwise in writing.

How should external auditors be given access?

Through a time-limited, read-only grant covering the engagement scope, with the grant recorded alongside the engagement file. Avoid a shared reviewer login, because it breaks the audit trail for everyone who uses it.

What shows the access design is actually working?

A dated review record with the removals made, a sample of exports tested against each class, and a log of exception grants with expiry dates. A design that cannot produce these is an assumption rather than a control.

Next step

If access to GRC data has grown without review, comparing current memberships against the matrix is often the quickest way to measure the drift.

GRC access design: role tables, ACL rules and audit fields in ServiceNow

GRC access in ServiceNow is the sum of roles held by a user or inherited through groups, plus ACL rules on each table and field. The deciding fact is that holding a role is never the whole answer: a record is visible only when the role, the condition and any script on its rules all pass.

These are common out-of-box names, so check them on your own instance and release; labels and defaults change between releases.

ACL operations include read, write, create and delete, and a rule can sit on a table or on a single field. A field rule can hide a finding’s remediation notes while the record stays listed. A query business rule filters which rows a list returns at all, so use it when the existence of a record is itself sensitive.

Example (hypothetical): an external auditor needs finance controls for a fixed period. The platform team creates a group, gives it one read-only role, adds the auditor, and records the planned end date beside the membership request. On that date the membership is removed, and a reviewer lists the group’s members and the auditor’s effective roles to confirm nothing remains. Before access starts, the team opens a control, a finding and an export as that auditor.

Which table shows every role a person effectively holds?

Start with sys_user_has_role for direct grants, then add roles from sys_group_has_role for each group in sys_user_grmember. Roles can also contain other roles, so an inherited role may not appear as a direct row. On many releases, the roles related list on the user record also shows inherited roles.

How do you check what an auditor will actually see?

Use Impersonate User as an administrator, then open the lists, forms and reports the auditor will use, on an account that holds only the auditor’s group. Test a list view and an export as well, because list and report columns can differ from the form layout. The instance security and access control guides cover the platform checks.

Why can someone edit a record that one ACL seems to block?

Another rule for the same table or field may allow it, because within one level of specificity, access is typically granted when any matching rule passes. Check every rule for that operation, including the rules that cover all fields on the table. The governance, risk and compliance guides and enterprise use cases show where these rules matter.