ServiceNow Platform Performance: Security and Access Design

This page sets out who should be able to see ServiceNow performance data and how to limit that access. It covers a small reader role, separating monitoring from configuration, and regular access reviews, so exposure stays low.

Performance data on a ServiceNow instance shows where the platform is weak and who caused a slowdown, so access to it needs the same design as any sensitive operational record. This page sets out the role model, least privilege and segregation of duties, field-level sensitivity, audit logging, administrative access, access reviews, and how to test what a performance reader can actually see and where to restrict: table, field, report or dashboard.

Role model for performance work

There is no separate performance role in the platform. The diagnostics that show why an instance is slow, such as the transaction logs, the slow query and slow transaction statistics and the index suggestions, sit behind the admin role, so whoever can read them can also change the instance. Keep that group small: it is the platform team, and it is the admin role referred to on the rest of this page.

Dashboards and reports built on performance data are governed by the ordinary reporting roles and, where trends are kept there, by Performance Analytics roles. For a curated view, create a read-only role of your own, grant it only the dashboards and tables it needs, and treat it as the reader role on this page. End users and finance should hold none of these grants.

Implementing least privilege

Give users the minimum role needed for their job. A platform team member monitoring performance needs Reader role only, not Admin role. An admin managing performance policies needs Admin role but not system admin.

Review access quarterly: are users still in the roles they need? Have job changes made some roles unnecessary? Remove unnecessary roles.

Segregation of duties in performance management

Monitoring (viewing performance data) should be separate from configuration (setting thresholds, defining escalations). One team monitors and reports, another team (or manager) makes changes to configuration.

This prevents a single person from both detecting an issue and covering it up by changing the monitoring.

Implement: monitoring team has Reader role, platform leadership has Admin role. Both must approve major changes to monitoring.

Data sensitivity and field-level security

Performance data can reveal sensitive information: database query performance might reveal what systems are under load, disk space issues might reveal growth trends, license usage might reveal future spending.

Protect sensitive fields: database response times, query costs, storage usage. Access should be limited to people who legitimately need the information (database team, storage team, platform leadership).

Use field-level security to hide sensitive fields from general viewers. Only approved roles can see sensitive fields.

Audit logging for performance management

Track who views performance data and when. This is important if performance data is sensitive. Track who makes changes to thresholds or monitoring configuration (someone might lower a threshold to avoid escalation).

Enable audit logging on: threshold modifications, escalation policy changes, exclusions from monitoring. Archive logs for the compliance period your policy requires.

Access control for specific performance metrics

Database performance: visible to database team and platform leadership. Not for application developers (who might optimize queries without good reason if they see performance data).

Integration performance: visible to integration team and affected app teams. Not for general users.

License usage and cost: visible to platform leadership and procurement. Not for end users (who might find out their org uses a lot of licenses and lobby for more budget).

Managing administrative access

Administrators who can configure Platform Performance should not also be able to bypass monitoring. If an admin configures a threshold too high to avoid escalations, that is a security issue.

Controls: require approval for threshold changes (review and approval workflow). Log all changes. Monitor for anomalies (threshold suddenly raised, monitoring disabled).

Disaster recovery and access recovery

If System Administrator access is compromised or forgotten, how do you regain control? Have a break-glass emergency access process: documented emergency account with admin access, used only in emergencies, heavily audited.

Change passwords on emergency accounts regularly. Log all emergency access for audits.

Access review and compliance

Quarterly access review: who has Platform Performance access, do they still need it, are there unused accounts? Send the list to team leads for certification.

Annual compliance check: are controls working (audit logs captured, thresholds not bypassed, access appropriately restricted)? Fix any issues found.

Escalation and incident management

Performance issues are tracked and escalated: if database performance degrades, escalate to the database team. If issues remain unresolved, escalate to senior platform leadership. Clear escalation paths prevent issues from festering.

Multi-Team Access Governance

In large organizations, multiple teams monitor performance: database team monitors database performance, network team monitors network latency, application team monitors application response time. Each team should see only their relevant metrics. Use platform access groups to organize users: database team in the database group, network team in the network group. Assign roles at the group level: database group gets database performance access, network group gets network performance access. This keeps permissions manageable as the organization grows and teams change.

Compliance and Regulatory Considerations

Some industries require specific audit trails for performance management. Financial services may require evidence that performance is monitored continuously. Healthcare may require documentation of system reliability. Maintain detailed audit logs of who accessed performance data and when. Preserve logs as evidence for audits and compliance reviews. Periodically generate audit reports showing: access patterns, configuration changes, threshold violations, and escalations. Use these reports to demonstrate that performance is actively managed and monitored according to policy.

Testing what a performance reader can actually see

A role model on paper tells you what a person should be able to do. It does not tell you what they can see when they open a performance dashboard, a slow query view or an exported report. Those are different questions, and the gap between them is where much exposure happens. Before a performance dashboard is shared beyond the platform team, the person responsible for access should test it from the point of view of each role, using test accounts on a non-production instance rather than their own administrator login.

The reason is practical. Administrators inherit broad rights, so anything they open looks correct to them. A test account with only the reader role will reveal fields, related lists and report rows that were never meant to be visible, often through a related table that was left open years ago. Plan the test as a short, scripted walk through each role, and record what each account can open, filter, export and share.

Choosing where to restrict: table, field, report or dashboard

Restricting performance data can happen at four levels, and each level catches a different kind of leak. A single control rarely covers everything, so the decision is about which combination matches the sensitivity of the data.

The table is a reminder that dashboard visibility is the weakest control on its own. Treat it as navigation, not as protection, and make sure the controls beneath it are the ones that actually decide what a reader sees.

A sequence for auditing the grants on a performance area

The following order works well when inheriting an existing setup, because it starts from the data and moves outward to the people.

1. List every table, report and dashboard that contains performance metrics, including scheduled exports and any custom tables created for monitoring.
2. For each item, record the roles that can read it, the roles that can change it, and any group that receives it by schedule.
3. Run the test walk-through with a reader account, an operator account and a configuration account, and note each place where the result differs from the intended model.
4. Remove any grant that exists only because a previous project needed it and no current owner can name the reason.
5. Check that the people in the groups still hold their current jobs. A group that once held an operations role may now include people from an unrelated team.
6. Write the result into the access record, with the reviewer and the date, so the next review starts from evidence. A broader walk through every role is covered in the platform access review write-up.

Where the controls usually break

• A report built for one team is copied to create a variant for another, and the copy keeps the original sharing list without anyone deciding that it should.
• An integration account is given broad read access to diagnose a problem, and the grant stays after the diagnosis is closed.
• A monitoring threshold is changed by an administrator who is also the person whose work the threshold measures.
• Exports leave the platform through email or a spreadsheet, and the audit trail may stop at the moment of download.

Each of these failures is a process failure as much as a configuration one. The fix is a short rule that says who approves a copy, who approves a new sharing group, and who receives the monthly list of accounts that can export performance data.

Frequently raised questions about performance data access

Do table controls still apply when a dashboard is shared?

Generally, a shared dashboard does not give a reader rights they do not already hold on the source data. Reports and widgets are evaluated against the reader’s own permissions, so a widget will show less when the reader lacks rights. The practical risk is the opposite: a widget built by an administrator may display an aggregate that reveals more than any single row would. Test the aggregate itself with a reader account. The access control list concept guide explains how the rules at each level combine.

Should performance administrators be able to edit access control rules?

Usually not. The person who tunes performance and the person who decides who may see performance data are doing two different jobs, and combining them lets one person widen their own visibility. Keep rule changes with the security owner and let the performance team request them through a ticket with a stated reason.

What should happen to shared reports when someone leaves the team?

Hand ownership to a named successor before anyone’s exit date, and check the recipients of any scheduled report the leaver owned. A scheduled export that continues to run for a former employee is a common and easily missed exposure.

Is a reader role enough for an on-call engineer?

For watching dashboards during an incident, usually yes. An engineer who must change a threshold or pause a monitor during an incident needs a separate, time-limited grant, recorded in the change log and removed when the incident closes. Granting standing administrator rights for that situation is the wrong answer.

Next step

A review of this kind often starts with the test walk-through described above, and it often produces a short list of grants to remove.