ServiceNow Instance Security and Access Control Requirements Workshop Questions

This page gives the questions a ServiceNow instance security workshop should settle, grouped by authentication, role-based access, data segregation, administrative access and audit needs. It also shows the warning signs that a question has not really been answered.

A security requirements workshop for a ServiceNow instance has to settle who authenticates and how, which roles exist and what they may touch, how data is segregated, who holds administrative access, and what auditors will ask for later. The questions below are grouped by those decisions, each with the warning sign that shows a group has not really answered it, and the closing section covers how to run the session so it produces decisions rather than notes.

Authentication Strategy and Identity Management

The first set of questions focuses on how users authenticate to ServiceNow. Will users authenticate with ServiceNow user accounts (username and password stored in ServiceNow)? Or will they use enterprise identity (Active Directory, Okta, Azure AD)? Will multi-factor authentication be required? Will password policies enforce complexity and expiration?

Enterprise identity integration is generally preferred. It centralises user provisioning and deprovisioning (when a user leaves the company, one deletion removes them from all systems). It allows single sign-on (users log in once and access multiple systems). It enables multi-factor authentication through centralized policy. ServiceNow-only authentication requires more operational overhead and is harder to audit.

Multi-factor authentication (MFA) adds security but complexity. Users must carry a second factor (phone, hardware token, authenticator app). For internal-only systems with limited sensitivity, MFA may be optional. For systems with sensitive data or external access, MFA should be required. Questions to clarify include: will MFA be required for all users or only privileged users? What second factor methods will be supported?

Another authentication question is guest or external user access. If partners, contractors, or customers access ServiceNow, how are they authenticated? Can they use enterprise identity, or do they need ServiceNow accounts? Can they access via SAML or OAuth, or only through passwords? External user authentication is often more complex and requires careful access control.

The warning sign is storing passwords in ServiceNow when your enterprise identity system is available. This creates support burden (password resets) and security risk (ServiceNow must securely store passwords). Use enterprise identity whenever possible and restrict ServiceNow accounts to special cases.

Role Definition and Role-Based Access Control

Once users are authenticated, the next level of security is authorization: what can each user do? The most granular approach is role-based access control (RBAC). Each user is assigned roles that grant permissions. Questions about role design focus on how many roles to define, what permissions each role has, and how role assignment is managed.

Overly broad roles grant too much permission. A single “IT Support” role should not grant access to change management, asset management, and configuration management if most IT support staff only work with incidents. Overly narrow roles create management overhead (assigning ten roles to each user) and user confusion.

A practical approach is to define roles by job function: incident handlers, change managers, IT administrators, business users. Each role includes permissions needed for that function. Users can be assigned multiple roles if they work across functions. Periodically audit role assignments to confirm users still need all their roles.

Role assignment should be automated where possible. If your enterprise identity system includes group memberships, ServiceNow can use groups to assign roles automatically. This prevents stale manual role assignments where users retain roles they no longer need.

Another authorization question is table-level permissions versus record-level permissions. Table permissions control access to entire tables (can a user view incidents at all?). Record permissions control access to individual records (can a user view only incidents assigned to their team?). Table permissions are simpler to manage; record permissions are more granular but complex. Most organizations use table permissions as the foundation, with record permissions for sensitive data or high-security areas.

The warning sign is over-permissive default roles or too many privileged users. If all IT staff have administrative access, logging and audit trails become noise. Limit administrative access to those who need it. Regular audits of permission assignments catch role creep (users with too many permissions).

Data Access and Segregation of Duties

Beyond table access, specific data access may need restricting. Questions about data access focus on whether certain data (payroll, executive performance reviews, customer financial information) should be hidden from certain users. Will you restrict access to the table, or grant table access but hide specific records or fields?

Segregation of duties is a compliance requirement in many organizations. A user should not be able to approve their own access request or change their own pay. Questions about segregation focus on whether these conflicts are enforced in the system or only monitored in audits. System enforcement is stronger.

Field-level security controls which fields a user can see. A user with access to employee records might see name and job title, but not salary or home address. Field-level security is granular but complex to manage. Use it for highly sensitive fields, not everything.

Data filtering ensures users see only records they have permission to access. A manager should see only incidents assigned to their team, not incidents from other teams. Data filtering should be automatic (based on user role or team assignment) rather than relying on users to restrict their own view.

Administrative Access and Change Control

Administrative access allows bypassing security controls and should be tightly restricted. Questions about administrative access focus on who has admin privileges, how long admin sessions last, and whether privileged actions are logged. Ideally, administrative work is logged and monitored.

A practical approach is: only a small group of platform engineers have administrative access. Administrators know they are being monitored and their actions are logged. Administrative access is required to sign an approval and acknowledge responsibility for changes made. This audit trail creates accountability.

Time-limited administrative privileges are more secure than permanent. An administrator might have elevated access only during a maintenance window, not all the time. Time-limited access reduces the window during which an admin account can be compromised.

Administrative password management is critical. Shared admin passwords are a security anti-pattern (if someone with access leaves, the password is compromised). Use personal accounts with administrative roles, or use a password vault to manage shared passwords with audit trails.

Compliance and Audit Requirements

Depending on your industry and regulations, compliance requirements may dictate access control policies. Questions about compliance focus on what regulations apply, what access control requirements they impose, and how you will demonstrate compliance.

Common compliance frameworks include HIPAA (healthcare), PCI DSS (payment processing), SOX (financial services), GDPR (data protection), and ISO 27001 (security management). Each has access control requirements. Clarify which frameworks apply to your organization and what they require from a ServiceNow perspective.

Audit trails are often required. Compliance frameworks typically require logging which user accessed what data, when, and why. ServiceNow audit trails provide this if configured correctly. Retention periods are set by the applicable regulations.

Access reviews are often required. Compliance typically requires periodic reviews (annually or quarterly) to confirm users still need all their permissions. Automated reports showing role assignments help with these reviews.

The warning sign is compliance requirements discovered late. During requirements workshops, clarify compliance obligations from the start. If you discover halfway through implementation that PCI DSS requires quarterly access reviews, you must retrofit the monitoring and audit trails into an already-configured system.

Monitoring and Incident Response

The final set of questions focuses on detecting and responding to security incidents. Will you monitor for suspicious activity (multiple failed logins, unusual access patterns)? Will you have a process to disable compromised accounts quickly? Will you audit access to sensitive data?

Suspicious activity detection can be automated: alerts for multiple failed logins, access from unusual locations, or access at unusual times. These alerts allow quick response if an account is compromised. False positives (legitimate users working at night) should be managed; too many false positives cause alert fatigue and being ignored.

Incident response process should be documented: if an account is suspected to be compromised, who disables it? Who investigates? How is access restored once the incident is resolved? A clear process prevents chaos during security incidents.

Running the Security Requirements Session So It Produces Decisions

A workshop on instance security often fails in a predictable way: the room agrees that access should be least privilege, nobody owns the sentence that says who gets which role, and the platform team leaves with a list of opinions. The session needs a different structure from a general requirements meeting. Invite the people with authority to approve a control, not only the people who will feel its effects, and close the session with a decision register that names an owner and a date for every open point.

Who Must Be in the Room

Bring the instance owner, a directory or identity administrator, one representative from the business units whose records are sensitive, the person who answers to internal audit, and whoever will run the first access review. A session without the identity administrator can produce authentication answers that cannot be built, and one without the reviewer can produce role designs nobody can certify.

Sequencing the Topics

1. Settle the identity source first, because provisioning, deprovisioning and second factors all depend on it.
2. Agree the admin role list second, since every other control is easier to design once the people allowed to change configuration are known.
3. Walk through sensitive data last, using real field names from the instance rather than abstract categories.
4. Finish with evidence and incident handling, so the answers to earlier topics feed directly into what gets recorded.

What a Good Output Looks Like

A decision register with four columns is enough: the question, the decision, the owner and the review date. Anything that cannot be decided in the room goes into a parked list with a single accountable person and a deadline for the answer. Avoid minutes that read as a transcript; the register is the artifact an auditor or a new platform engineer will open later.

Common Ways the Session Goes Wrong

A common failure is letting one executive settle the whole role model by instinct. Ask for the job the role must do, then test whether the proposed permission set matches it. A second failure is treating the workshop as a one-off. Access rules change when the business changes, so the register should be revisited each time the access review runs.

Frequently Asked Questions Before the Workshop

Should we send the questions in advance?

Yes, but send them grouped by topic block and ask each attendee to bring one example of a real access request they handled. Concrete cases surface gaps that abstract questions hide.

What if the identity team cannot attend?

Postpone the authentication block rather than guessing. A decision made without the identity administrator tends to be reversed during build, which costs more time than a short delay.

How many topics can one session cover?

Keep each session to a small number of topic blocks. Security decisions made late in a long session are the ones most often revisited.

Can the register replace a formal design document?

It can record the decisions, but it does not explain the reasoning in full. Keep a short rationale beside each entry so later administrators understand why a control exists.

The roles and RACI guide is the related read on assigning the owners the register will need, and for the identity topic block, the identity integration boundaries article sets out the related decisions.