ServiceNow Instance Security and Access Control: Guides and Services

What Instance Security Encompasses

Instance security protects the ServiceNow platform from unauthorised access and misuse. Security measures include user access control, role-based permissions, audit logging of sensitive activities, encrypted data transmission, password policies, and integration with organisation-wide identity and access management systems.

Instance security also covers application-level security: preventing SQL injection and cross-site scripting attacks, validating user input before processing, securing API connections through authentication tokens, and managing secrets such as API keys and database passwords used by integrations. Security is a shared responsibility between the organisation and ServiceNow.

User Access Management

Access management begins with identity governance: ensuring that users in the system correspond to actual people in the organisation and that access is provisioned and deprovisioned with onboarding and offboarding. Integration with identity management systems like Active Directory or Entra ID automates user provisioning so new hires are added automatically.

Quarterly access reviews audit user access, confirming that each user’s access level is still appropriate for their role and that no unauthorised users have access. User records for people who left the organisation are deactivated immediately to prevent access. Access reviews provide evidence for auditors that access control is active.

Role-Based Access Control

Role-based access control (RBAC) groups permissions into roles. Users are assigned roles, and the permissions from all assigned roles determine what data and functions the user can access. The role model should map to the organisation’s structure: roles exist for IT Operations, Finance, Service Desk Management, and so on.

Access control lists (ACLs) define what data each role can access. An Incident Handler role might have read and write access to incident records assigned to their team, but read-only access to incidents assigned to other teams. ACLs can be scoped by record ownership, table, or custom filter logic.

Multi-Factor Authentication and Strong Authentication

Multi-factor authentication (MFA) requires users to provide a second factor such as a time-based code, biometric, or security key in addition to their password. MFA significantly reduces the risk of account compromise from password theft or weak passwords. MFA can be required for all users or targeted to privileged users and external users.

Single sign-on through OAuth or SAML integrates ServiceNow with organisation identity systems. Users sign in once and are authenticated to multiple applications without needing separate passwords. Single sign-on simplifies user experience and reduces password management overhead.

Audit Logging and Compliance

The instance logs all administrative changes, including role assignments, policy changes, and configuration modifications. Sensitive business activities can be logged so compliance teams can verify that data access controls are being followed. Audit logs are preserved for the duration required by regulations and provided to auditors during compliance reviews.

The sys_audit table captures historical changes to records, preserving previous values when records are modified. This allows auditors to reconstruct the state of data at any point in time, providing evidence for investigations into data integrity or unauthorised modifications.

Encryption and Data Protection

Data transmission to and from the ServiceNow instance uses HTTPS encryption. Sensitive data fields can be encrypted at rest in the database. ServiceNow provides field-level encryption for personally identifiable information and health records. Encryption keys are managed according to industry standards and compliance requirements.

API Security

APIs used by integrations must authenticate using credentials such as API keys or OAuth tokens. API rate limiting prevents abuse. API access can be restricted to specific IP ranges if integrations originate from known networks. API scope management ensures integrations only have access to the tables and fields they need.

Oblytech’s Security Services

We conduct access control audits to assess whether role-based access control is properly configured and whether access reviews are occurring regularly. We design access control models aligned to the organisation’s structure. Implementation includes provisioning automation, access governance workflows, and audit reporting. Security consulting addresses compliance requirements for specific regulations and industries.

Matching your question to the right guide

Instance security covers several decisions that are often made by different people: who may sign in, what each role can see, who may change the security configuration itself, and how evidence of all of this is kept. Reading the guides in the wrong order can produce a plan that looks thorough and still leaves a gap. The table below pairs each typical question with the guide that resolves it most directly, so a reader can start where the decision actually sits.

The hub does not replace any of these pages. It is the point where a reader confirms the question is about instance access and not about a neighboring concern such as network perimeter controls, endpoint protection or the security of a particular integration partner. Those belong to other teams, and an instance control cannot compensate for a gap in them.

Who decides what, before any setting is changed

Many stalled security projects stall at the same point: the platform team is ready to configure roles, but nobody has agreed who approves a role definition, who can grant an administrative role, and who will read the audit trail. Settle these three questions first. If the platform team holds all three, the instance can drift toward whatever is convenient for the people configuring it. If a separate security office holds all three, the platform team can wait for approvals on every small change. Many workable models split the work: the security office sets the standard and reviews exceptions, and the platform team applies the standard and keeps the evidence.

A starting sequence for a team with little time

1. Export the current list of users who hold administrative or elevated roles, and confirm each name against a business need.
2. Find every account that is shared, unowned or used only by an integration, and assign each one an accountable person.
3. Confirm that sign-in for administrative users requires a second factor, and record any exception with an expiry.
4. Check that audit logging captures role changes and changes to access controls, and that someone can search it.
5. Choose one recurring review of role assignments and put it on the calendar with a named reviewer.
6. Only after these steps, redesign roles and approval paths, because the evidence from steps one to five shows which roles are actually in use.

The order is deliberate. Redesigning roles before knowing who holds the current ones can produce a new model that the existing grants quietly override.

When a hub reader should look elsewhere

If the question is about a single integration, a particular application’s data sensitivity or a policy for personal data handling, a generic instance access guide will not settle it. Those questions need the owner of the integration or the data classification exercise described in the data classification workflows article. Likewise, the platform access review article is the companion read when the question is recertifying existing access rather than designing it.

Is an instance security review the same as a platform health check?

No. A health check looks at the overall condition of the platform, including performance and configuration debt. A security review focuses on who can do what and whether that is provable from the logs. The two often run together, but they answer different questions and should have separate owners.

Which guide should a new security lead read first?

Start with the governance model for the ownership questions, then the best practices guide for the controls. The roadmap is most useful once the owners and controls are agreed, because it sequences the work.

Do the controls differ for sub-production instances?

The principles are the same, but the risk differs when production data is copied into a lower environment. Decide who may sign in to sub-production, which data may be present there, and how refreshes are controlled, then apply the same review cadence.

Can the instance be secured without changing identity providers?

Often yes for the basics, such as role design, audit logging and admin restrictions. Single sign-on, provisioning and the directory are different: changing them is a larger project, and the integration patterns guide is the place to look for those boundaries.

Talking through your access model

If you are unsure which of these decisions is blocking the others, a structured review of your current roles and admin accounts is a sensible first step.