ServiceNow Problem Management: Security and Access Design

Role Model for Problem Management

A role model defines who should have permission to create, view, update, and close problem records in ServiceNow. In most organizations, problem managers and senior technical staff create problems after identifying patterns or significant issues. While support agents view problems to understand known issues and incorporate solutions into their responses, they typically do not create or edit problems. Database administrators, system administrators, and application owners edit problems as investigations progress. Service desk agents can view problems but not create or edit them, allowing them to reference known solutions when handling incidents affecting the same systems.

Least Privilege Principle in Problem Context

Apply least privilege access: grant only the minimum permissions needed for each role to perform their job effectively. A database administrator investigating a problem with SQL Server does not need to view problems in other systems; restrict access to database-related problems. A service desk agent needs to read problems to reference solutions but should not edit investigation notes or change problem status. Infrastructure teams investigating network problems should not have edit access to application problem records. This containment reduces risk of accidental data changes, maintains focus on problems relevant to each team, and ensures only appropriate staff can modify investigation records and conclusions.

Segregation of Duties and Conflict Prevention

Separate the roles of problem creator, investigator, solution designer, approver, and implementer. A single person should not both create the problem record, design the solution, approve it, and implement it, as this creates conflict of interest and removes checks and balances. A technical team member investigates and proposes solutions; a separate approval authority verifies the solution and authorizes implementation. A third party executes the change. This separation ensures proper oversight and prevents bypass of change controls. For smaller organizations, roles may be combined but the principle of segregation should still be followed where possible.

Audit Evidence and Compliance

Configure problem records to track all changes: who modified the problem, when, and what changed. This audit trail proves compliance with change control and investigation procedures. Establish periodic review cycles where management reviews problem trends, verifies that resolved problems remain resolved and closed, and ensures that recurring problems receive escalated attention. Document these reviews as evidence of governance and oversight. This audit trail and documentation demonstrate control to external auditors in regulated industries.

Access Control Implementation in ServiceNow

Use ServiceNow’s role-based access control to implement your security model. Create roles such as Problem Manager, Technical Investigator, Change Approver, and Support Staff. Assign users to appropriate roles based on their responsibilities. Use field-level security to restrict who can modify sensitive fields like root cause analysis or recommended solution. Use table-level permissions to prevent users from creating or editing problems outside their domain or responsibility. Test access control to ensure users can do their jobs but cannot exceed their authority.

Special Considerations for Complex Environments

In large organizations with multiple business units or geographically distributed teams, problem visibility and access may vary by department. A problem in the network infrastructure team’s domain should not be visible to the HR service team. Use role-based views and filters to ensure teams see only problems relevant to their systems and services. Document these access boundaries clearly so teams understand what problems they should and should not access and why separation exists.

Monitoring and Compliance Validation

Establish regular review and validation cycles to ensure that problem management processes are being followed, access control is working as designed, and security measures are effective. Frequent reviews of access logs can identify unauthorized access attempts or overly broad permissions. Regular reviews of problem records can validate that investigations are following process and that conclusions are sound. Periodic reviews can assess whether governance structure still makes sense or needs adjustment.

Audit Trail and Evidence Collection

ServiceNow automatically maintains audit trails showing who accessed or modified each problem record and when. These audit trails provide evidence of proper oversight and governance. Export audit logs regularly to external storage for long-term retention and compliance purposes. These logs may be required for internal audits or regulatory investigations.

Where access is actually enforced on a problem record

Access design for problem records is often written as a role matrix and then implemented as a set of broad platform roles. The matrix looks right, but the enforcement is what the platform applies to each table, each field and each row, and that is where the gaps appear. A user who holds a general ITIL role may be able to read every problem in the instance, and a user with no role may still reach a field through a related list. Before trusting any matrix, trace each permission to the control that enforces it: table-level access rules, field-level rules, data policies that make fields read-only in certain states, and any scripted logic that filters records for a list or a report.

A test sequence for the access model

Testing access is not a single pass. It is a sequence that checks the things a reviewer is most likely to be asked about, and it should be repeated after any change to roles, to a related table, or to an integration.

1. Create one test user for each role in the model, with no extra roles, and record the exact role set used.
2. For each user, attempt to read a problem from outside their domain. A successful read is a finding even if no data is changed.
3. Attempt to edit each protected field from the form, from a list edit and from a related list on an incident. Record each path separately.
4. Move a test problem through each state and repeat the edit attempts after each move, since locks often apply only at a single state.
5. Check the integration account separately and confirm it cannot perform actions outside its documented purpose.
6. Store the test results with the role set used, so a later reviewer can repeat the same run.

Where the model is most often weakened

The model often weakens through convenience. A report that does not appear for a support user is fixed by widening a role instead of by adjusting the report’s filter. An integration fails with a permission error and is given an administrator role to get it working. A new team asks for access to all problems for a week and never loses it. Each change is small. The cumulative result is an access model that no one could describe if asked. A quarterly review of who holds which role, against the matrix, catches this before an auditor does.

Cross-domain access is the other weak point. Problems in one service often mention people, systems or data from another. Teams then request access to the other domain so they can read the context, and the access is granted rather than the context being shared through a controlled summary. Where that context is needed, provide a summary field or a linked, read-only record instead of broader access.

Questions security reviewers ask

Can a support agent see the root cause text on a problem?

That depends on the classification of the root cause. Where it can contain customer or security detail, restrict the field and publish a short, approved summary for agents. Do not rely on the form alone to hide it, since the same field may appear in a report or an export.

Do we need separate problem tables for sensitive domains?

Usually not. Field and row controls within one table are easier to maintain and test than parallel tables, which tend to drift apart. Separate tables are justified only when the data classification or the retention rule is genuinely different.

How do we prove the access model is working?

Keep the matrix, the test run with its role set, and the record of the quarterly review. Together they show what was intended, what was tested, and what was corrected, which is the evidence a reviewer usually asks for first.

Does the access model change when problems are linked to a security incident?

Yes. A problem linked to a security incident may need tighter restrictions while the investigation is open. Use the same controls with a stricter role set, and relax them only when the security owner agrees. The guide to access controls review covers the review routine that suits this case.

Wider access work that often runs alongside this design is covered in the access, privacy and segregation of duties scope.