ServiceNow Security Incident Response: Security and Access Design

Access design for security incident response sets who can see and change incident details, and how much authority each responder holds. This page helps a reader set role-based visibility, least privilege for containment decisions, confidentiality levels for sensitive investigations, evidence integrity and audit logs.

Role-Based Access for Incident Investigation

Incident records contain sensitive information: details of the attack, systems compromised, potential attacker techniques. Not all staff should see all incident details. An incident responder investigating an intrusion needs full visibility. A manager needs to know incidents occurred and their status, but not the technical details. An employee needs to know if their account was compromised, but not details of other compromises. Design role-based access: Incident Investigator sees full incident details, Incident Manager sees all incidents and their status, Department Manager sees only incidents affecting their department, Employee sees only incidents affecting them.

Use visibility filters: an incident related to Finance should not be visible to Engineering staff. An incident in Incident Management table shows status but hides technical details if the viewer does not have investigator role. This requires careful field-level security configuration: some fields are visible to everyone (incident ID, status), others only to investigators (attack techniques, evidence), others only to affected parties (whether they are impacted).

Least Privilege for Incident Response Authority

Incident responders make decisions that affect business operations: they isolate systems, revoke accounts, alter network traffic. Not every responder should have authority to make every decision. A junior analyst should not have authority to isolate production systems without approval. A mid-level analyst can make routine containment decisions. A senior analyst or manager approves exceptional decisions. Document decision authorities: who can isolate what systems, who can revoke what accounts, who can block what IP addresses? This prevents mistakes and ensures decisions are reviewed by appropriate authority levels.

Confidentiality of Incident Investigations

Incident investigations are sensitive and sometimes confidential. An investigation into employee account compromise should not be visible to all employees. An investigation into a potential insider threat must be restricted to investigators and leadership. Use incident classification: Public incidents (company-wide security awareness, patching a vulnerability) are visible broadly. Restricted incidents (investigation of suspected insider threat, potential data breach) are visible only to investigators and relevant leadership. Confidential incidents (investigation of a suspected employee, CEO account compromise) are visible only to a limited group.

Configure visibility rules to respect incident classification: when an incident is marked Confidential, only people with Confidential access see it. All others see incident count and aggregate statistics, but not details.

Evidence Protection and Integrity

Incident investigation evidence (logs, screenshots, memory dumps, network traffic) must be protected to support potential legal action or regulatory investigation. Evidence should be: immutable (cannot be altered after collection), timestamped (recorded when collected), and linked to the incident (traceable to the investigation). Store evidence in ServiceNow as attachments to incident records, or link to external evidence storage systems. Configure access: investigator role can upload and view evidence, but cannot edit or delete it after upload (evidence is write-once). Audit logs show who accessed what evidence when. This chain of custody protects evidence integrity in case of legal proceeding.

Segregation of Duties: Investigation Versus Containment

Ideally, the person investigating an incident and the person making containment decisions are different people. The investigator’s job is to understand what happened. The decision-maker’s job is to approve containment actions. If the same person does both, there is pressure to make containment decisions quickly to stop investigating. Separate roles improve decision quality: the investigator documents findings thoroughly, then presents to the decision-maker who approves or challenges containment actions.

Audit Logs and Accountability

Every incident action must be logged: who created the incident, who investigated it, what evidence was collected, who made containment decisions, who approved recovery actions. Audit logs are evidence that incident response was conducted properly, followed procedures, and was reviewed at appropriate levels. Use immutable audit logs: once an action is logged, it cannot be edited or deleted retroactively. Queries on audit logs answer: who accessed this incident, when, and what did they do? This accountability is important if an incident investigation later becomes controversial or legally relevant.

Communication and Notification Access

When an incident is declared, notifications go to incident responders, management, and potentially customers or regulators. Control who is notified: does every incident trigger an all-hands email, or only critical incidents? Is communication automatic, or does an investigator manually notify people? If automatic, use notification rules: critical incidents notify executives immediately, medium incidents notify at end of shift, low incidents go to a weekly summary. Restrict notification content: notifications should provide enough information to understand urgency, but not expose sensitive investigation details to the entire company.

Retention and Compliance Archival

How long are incident records retained: indefinitely, or for a specific period? Regulatory requirements vary by industry (data breach laws typically require incident records retained for as long as legal claims remain possible). Archive old incidents: move them from active systems to read-only archives. Active incident responders access current incidents; archived incidents are accessed rarely, usually for legal hold or audit. Configure access so that archived incidents are harder to accidentally modify: archive status shows they are fixed and historical.

Where incident data leaks even when the main access rules are right

Teams often spend weeks on the record-level rules for incidents and then discover that the same case details are visible elsewhere. The leak is often not in the main table. It is in the places that were built for another purpose: list views on related records, search results, exported reports, notification bodies, attachments and the email that was copied to a distribution list.

• Search results that show short descriptions of restricted cases to people who cannot open them.
• Dashboards shared across the company that aggregate restricted incidents by department, which can reveal a single investigation.
• Notification templates that include the case summary in the subject line.
• Attachments uploaded to a general knowledge article instead of the restricted record.
• Integration accounts with broad read access that copy records into a less restricted system.

An access matrix by classification and role

Design the matrix from the classification down. Each classification level should say which fields are visible, which can be edited, which evidence can be attached and which notifications are sent. Roles are then assigned to classifications, not to individual incidents. The matrix below is a pattern; the labels should match the classifications your governance owner has approved.

Verifying access with test personas instead of admin screens

Viewing the access configuration from an administrator account can tell you very little, because administrators often bypass the rules that responders live under. A stronger check uses a test account for each persona and walks the same paths a real user would.

1. Create one test account for each role in the matrix, with the same group memberships as a real person in that role.
2. For each classification, open a sample case as the highest-privilege persona and note every field and list it reaches.
3. Repeat the check as each lower persona, and compare the results against the matrix, not against memory.
4. Search for a known restricted term as each persona and confirm that no record title or summary appears.
5. Export a report and a list view as each persona, and check the exported file for the same content.
6. Record the results in the test log with the date and the configuration version tested.

Handling evidence attachments and exports

Evidence is often the hardest thing to restrict well, because it is copied, downloaded and sent to outside experts. Restrict the ability to download attachments to the roles that need them. Set up an approved path for sending evidence to an external forensic firm, and record each transfer in the chain of custody so that the copy outside the platform is traceable.

Emergency access and its removal

Sometimes a manager outside the matrix needs to see a restricted case immediately. Allow an emergency grant that is time-limited, recorded with a reason and approved after the fact by the investigation lead. Schedule its removal when the grant is made, not at a later review, because temporary grants that are never removed can become the normal path.

Can an administrator see restricted incidents?

Administrators often can, because platform administration needs that power. The safer design treats administrator access to case content as an exception that is logged and reviewed, and keeps day-to-day administration separate from the investigation team.

How do we check that exports respect the same rules?

Run the export test as each persona, as described above, and repeat it whenever a new report or integration is added. An export that was built by a dashboard owner rather than by the access owner can be a common source of unexpected exposure.

What happens to company-wide dashboards?

Aggregate counts can be acceptable, but a count that is one or two cases for a department can identify the case. Set a rule for minimum group sizes in shared views, and review any drill-down that leads from an aggregate to a single record.

Do integration accounts need the same restrictions?

Yes. An integration account with broad read access can be a route around the rules in the matrix. Give each integration the fields it needs and nothing more, and treat its credentials with the same review cycle as a human role.

The identity boundaries that sit behind these rules are covered in the identity integration boundaries guide, and the access recertification guide covers how access is re-checked over time, which keeps the matrix accurate.