ServiceNow Integrated Risk Management: Security and Access Design

This guide helps a risk and compliance team decide who can view, create, change and approve records in Integrated Risk Management. The core rule is that the person who assesses a risk should not also approve it, and evidence collection stays separate from risk evaluation. The page also covers least privilege and quarterly role reviews.

Role Model for Risk Management Access

Integrated Risk Management requires access controls that enforce segregation of duties. Risk should not be assessed and approved by the same person. Evidence collection should be separate from risk evaluation. Remediation should be overseen by someone independent of risk ownership. A strong role model prevents conflicts of interest and ensures accountability.

Define roles by responsibility level. Risk viewers can read assessments. Risk authors can create and modify assessments. Risk approvers can approve assessments for acceptance. Risk owners are accountable for remediating. Auditors can view but not modify. Each role has specific permissions.

Distinguish between risk manager roles and risk owner roles. A risk manager coordinates the assessment process but may not own the risk. A risk owner is responsible for mitigating the risk. Separate these roles so risk managers remain independent of risk ownership.

Least Privilege Principles

Grant access only to the data and functions an employee needs. A business unit manager does not need to view risks from other business units. An IT risk coordinator does not need to modify security risks. A financial analyst does not need to approve operational risks. Restrict access granularly.

Table-level access controls limit who can see specific risk records. Query-based controls show each user only the risks they own or are responsible for. Field-level controls hide sensitive fields from users who do not need them. For example, risk remediation cost may be visible to finance but hidden from other roles.

Restrict create, update, and delete carefully. Most users should only read or comment on risks. Only risk managers and designated owners should create and modify risks. Only risk approvers should mark risks as accepted. Delete access should be extremely limited.

Segregation of Duties Matrix

Create a segregation matrix showing which roles cannot be combined. Risk assessor and risk approver should not be the same person. Risk owner and risk assessor should not be the same person for high-value risks. Controls coordinator and audit coordinator should not be the same person.

Implement this in ServiceNow using role assignments and access checks. Use business rules to enforce rules. For example, if a user tries to assess a risk they own, raise an error. If a user tries to approve their own assessment, raise an error.

Review actual role assignments quarterly. People often hold multiple roles. Confirm that no individual holds conflicting roles. If segregation is violated for operational reasons, document the exception and require compensating controls.

Evidence and Audit Trails

Risk assessments are valuable only if they are trustworthy. Audit trails prove that assessments were conducted properly. Maintain records of: who created the assessment, who reviewed it, who approved it, when each action occurred, and what changed between versions.

Use ServiceNow’s standard audit trails—sys_audit. Configure auditing on all risk tables so changes are tracked. Do not allow users to edit audit records. Audit trails should be immutable once created.

Evidence should also include the basis for risk assessment. If a risk is rated high impact, there should be documentation supporting that rating. This may be a linked risk assessment, a report, or a business rule. Require assessors to attach or reference evidence when creating risks.

Access Review Cycle

Schedule access reviews at least annually. Risk profile changes—new risks emerge, risks are mitigated, organizational structure changes. Access should change with the risk profile. A user who was a risk coordinator for a project should not retain risk access after the project ends.

Use the annual access review to confirm role assignments are still appropriate. Check: do users still need the roles they have? Do any users have conflicting roles? Are there users with access but no current responsibility?

Implement quarterly reviews for high-risk areas like financial risk or security risk. If these areas change frequently, annual review is too slow. Faster review cycle improves control strength.

Audit Evidence and Compliance

Risk Management is often subject to regulatory requirements. Auditors expect to see evidence that risks are assessed, evaluated for acceptability, and monitored for remediation. ServiceNow should provide audit reports showing the chain of decisions.

Maintain a report showing all risks, their assessment status, approval status, and remediation status. Include timeline and who was responsible for each step. Auditors use this report to trace decisions. Use the risk dashboard to show this visually if possible.

Retain historical risk data. Approved risks and their remediation plans should be kept as evidence that the organization was aware of risks and acted to mitigate them. Do not delete old risk records; archive them.

Implementing Access Controls in ServiceNow

Use ACLs (Access Control Lists) to implement the role model. Grant table-level access by role. Create query-based ACLs that filter records by business unit or organizational unit. For example, an ACL grants access to risks if the user’s business unit matches the risk’s business unit.

Use field-level security to hide sensitive fields. Restrict who can edit fields that have audit or control implications—status, approval fields, remediation completion. Most users should view-only these fields.

Create a review report that lists all users with risk access and their assigned roles. Run this report quarterly as part of the access review. Identify users who may no longer need access. Document decisions to add or remove access.

Access for people who are outside the organization

External parties need risk data for specific reasons: an external auditor reviewing a cycle, a regulator asking for evidence, or a vendor completing an assessment about its own services. Each of those needs a different scope and lifetime, and granting them the same role as an employee is a common access error in this area. Give each external party a dedicated identity, a role limited to the records they need, an end date set at the moment of granting and a named internal sponsor who is responsible for removing the access when the purpose ends. Vendor assessors in particular should see only their own assessment, never the wider register. Third-party risk for the wider business is covered in security risk governance.

Testing access rules before they go live

Access rules fail in two directions. A rule can be too wide, letting a user see records they should not, or too narrow, leaving an owner unable to act on the risk they are accountable for. Both need testing, and a passing test for the first does not prove the second. Build the test around negative cases, meaning users who should be refused, as well as positive cases for users who should succeed.

1. Set up one test identity per role and per business unit, and write down what each identity should be able to see.
2. Attempt to read, edit and delete a sample of records from each unit as each test user.
3. Attempt to change the approval and status fields as a user who is not an approver, and confirm the change is refused.
4. Attempt to approve a record that the same test user assessed, and confirm the approval is blocked.
5. Confirm that every refused attempt left an entry in the audit trail, since a later reviewer will need that history.

Break-glass access for urgent risk changes

Sometimes a risk must be changed outside normal hours, such as when an incident materializes and the owner is unreachable. A break-glass route lets a named emergency role act without the usual approvals, and it is safe only if its use is loud. Limit the route to a short list of people, require a reason at the point of use, notify the risk owner and the forum automatically, and review every use within the next working cycle.

Keeping the access model honest over time

Access models drift as people move and as the register grows. Two checks help. Reviews of that kind are often part of a platform access review. The first compares the list of people holding each risk role with the current staff directory, and flags anyone who has left or changed unit. The second compares the access granted with the access used, and flags roles that have not been exercised for a long period. Unused access is not a risk in itself, but it is access that someone may forget they hold, which is exactly the situation an examiner will ask about. Evidence of those checks belongs in the audit trail alongside the grants.

Frequently asked questions about risk platform access

Should auditors be given read access to the whole register?

Give them read access to the records within the audit scope and nothing else. Scope is set by the audit plan, and the access should follow it. A wider grant is harder to justify and harder to remove later.

Can access be controlled at the field level?

Yes, for fields such as remediation cost or a personal conduct note. Keep the number of hidden fields small, because each hidden field needs its own test and its own explanation to the people who cannot see it.

How do we handle a risk that touches two business units?

Assign one owning unit and give the other unit a read or contribute role. Shared ownership often means that nobody owns the decision, which is the outcome access design is meant to prevent.

What should be in the audit trail for access changes?

Who granted the access, to whom, the role, the reason, the start date, the end date where one exists and the date of removal. Removal entries matter as much as grant entries, because they show the access model was maintained.