Troubleshooting ServiceNow Security Operations: A Practical Guide

This guide works through ServiceNow Security Operations faults one symptom at a time. Each symptom lists its likely causes, where to look in the platform, the fix and when to escalate. Most faults sit along one data path, from threat ingestion through correlation and assignment to closure.

Most Security Operations faults sit somewhere along one data path: threats are ingested from feeds and sensors, correlated into incidents, assigned to responders and tracked to closure, and a break at any step shows up as missing alerts, empty dashboards, incidents that never get created or escalations that never fire. The sections below take each symptom in turn with the likely causes, where to look and the fix, and end with when to escalate to Oblytech or ServiceNow support.

Symptom: Threat Alerts Are Not Appearing

Likely causes: the data source is not connected, the ingestion is failing, or alerts are being filtered.

Where to look: first, verify the data source is connected. Check Admin > API Integrations or your threat feed configuration (the exact location depends on which feeds you use: SIEM, threat intelligence platform, or third-party sensor). Confirm the feed is enabled and the API key or credentials are valid (they often expire).

Second, check ingestion logs. Many feeds have a status page in ServiceNow (look for a plugin-specific admin module) showing recent ingestion attempts, errors, and the last successful import timestamp. If the timestamp is old (days or weeks), the feed is not running.

Third, check filters. Some organizations configure threat filters to suppress false positives (low-confidence alerts, known benign domains, alerts from test systems). Verify the alert you expect is not being filtered out by a rule. Look for filter rules under Security Operations > Threat Intelligence > Filters or similar.

Fix: re-authenticate the data source (refresh API key), restart the integration (many platforms have a “Test Connection” or “Sync Now” button), and verify network connectivity if the data source is on-premises or requires VPN access. If filters are hiding alerts, adjust the filter rules or add a temporary exclusion for testing.

Symptom: Incidents Are Not Being Created from Threats

Likely causes: threat correlation rules are not configured, thresholds are set too high, or the incident creation workflow is disabled.

Where to look: check the threat correlation rules. Navigate to Security Operations > Threat Intelligence > Correlation Rules (or similar). Verify rules exist and are enabled. Each rule has a threshold: “create an incident if threat severity is high or critical” or “create an incident if the same threat is seen three times in one hour”. If thresholds are too strict (e.g., only critical threats, and you are seeing mostly high threats), few incidents will be created.

Check the incident creation workflow. Some organizations use a workflow that requires manual approval before an incident is created (to prevent alert fatigue). If the workflow is stalled (waiting for an approval that never arrives), incidents pile up in a draft state. Look for incident records with a state of “draft” or “pending_approval”.

Fix: enable correlation rules if they are disabled, adjust thresholds to match your threat environment (if you are tuning based on a month of data, you may suppress real incidents), and verify the incident creation workflow has appropriate auto-approval or is being monitored.

Symptom: Security Operations Dashboard Shows No Data

Likely causes: data is not flowing, the dashboard is querying the wrong table, or there is a permissions issue.

Where to look: first, check that threats or incidents exist in the system. Run a query: Security Operations > Threats (or Incidents) and count records. If the table is empty, data is not flowing (refer to the “Threat Alerts Not Appearing” section above). If records exist but the dashboard is empty, the dashboard may be querying a different table or applying filters that hide all data.

Check the dashboard query and filters. Edit the dashboard; for each widget, check the source table (is it “Threat Intelligence” or “Incident”?) and any filters applied (is it filtering to only the current user’s incidents, but you are viewing as an admin? Is it filtering to a specific threat source that has no data?). Check your user’s role and permissions: if you lack read access to the threat or incident table, the dashboard will appear empty.

Fix: verify data exists using a direct table query (bypassing the dashboard). If data exists, adjust the dashboard filters or queries. If data does not exist, troubleshoot data ingestion. Grant appropriate roles (typically “security_incident_responder” or similar) to dashboard users.

Symptom: Incident Assignment Is Not Happening Automatically

Likely causes: assignment rules are not configured, the workflow is disabled, or the assigned-to queue or team is not set up.

Where to look: check incident assignment rules. Navigate to Security Operations > Incident Management > Assignment Rules (or similar). Verify rules exist and are ordered correctly (rules are processed in order; if an early rule matches, later rules are skipped). Each rule should have a condition (e.g., “if severity is high”) and an assignment (e.g., “assign to the SecOps team”).

Verify the assignment destination exists. If a rule says “assign to ‘Security Team A'”, confirm that queue or team exists and has members. Check the incident workflow: assignment often happens in an “on create” workflow; verify the workflow is enabled and the assignment step is not failing due to missing data (e.g., assigning to a team that does not exist in this system instance).

Fix: enable assignment rules or workflows if disabled, verify conditions match your incident data (an assignment rule looking for “threat source = Splunk” will never fire if your threats come from a different source), and ensure the assignment destination exists and has members.

Symptom: False Positives Are Creating Too Many Incidents

Likely causes: correlation thresholds are too low, filters are not configured, or the data source is noisy.

Where to look: review recent incidents and identify patterns in false positives. Common sources: test systems (firewalls, intrusion detection systems) are being monitored but should not be; development environments are generating alerts that should be suppressed; or known benign events (failed login attempts after password changes, network scans for compliance testing) are creating alerts.

Check threat correlation thresholds. If your rule is “create incident on any high-severity threat”, and your data source has high false-positive rates, you will be inundated. Check filters and suppression rules: can you filter by source (exclude test systems), by destination (exclude development networks), or by confidence level (only incidents with high confidence)?

Fix: add filters to suppress known false positives (e.g., “exclude alerts from IP range 10.0.0.0/8” for internal networks). Adjust correlation thresholds or confidence levels. Consider tuning the data source itself (some SIEM or IDS configurations can be made less noisy). Track metrics: how many alerts are created daily, how many become incidents, and what is the ratio? If incident-to-alert ratio is high (e.g., 1:2), you are filtering well. If it is low (e.g., 1:10), thresholds need tuning.

Symptom: Escalations Are Not Happening

Likely causes: escalation workflows are not configured, the SLA timer is not running, or escalation criteria are not being met.

Where to look: check incident escalation workflows. Navigate to Security Operations > Incident Management > Workflows and look for escalation steps. Verify the workflow is enabled and the escalation condition (e.g., “if incident age exceeds SLA target”) is correct. Check the incident SLA: each incident type should have an SLA (e.g., “high-severity incidents must be resolved within 4 hours”). Verify the SLA is attached to the incident and the timer is running.

Run a test: create a test incident with high severity and old creation time (manually set the created date to old in a test instance). Does escalation trigger? This confirms the logic is working.

Fix: enable escalation workflows, attach SLAs to incident types, and verify escalation conditions are realistic (do not set an SLA target your team cannot reliably meet).

Symptom: Closing an Incident Doesn’t Send a Notification

Likely causes: notification workflow is not configured, the notification rule doesn’t match the incident, or email is not configured.

Where to look: check incident closure workflows. When an incident state changes to “resolved” or “closed”, a workflow should trigger a notification. Verify the workflow exists, is enabled, and has a notification action. Check notification rules: they may filter by severity, assignment, or other criteria. An incident that doesn’t match the filter (e.g., low-severity incident, but the rule only notifies for high-severity) will not send a notification.

Verify email is working. Check the incident notifications by navigating to the incident record and viewing the activity stream; if the notification action ran, you will see a log entry. If not, the workflow did not execute or the notification step was skipped.

Fix: enable notification workflows, verify notification rules match your incident data, and test email delivery (send a test email to yourself from ServiceNow to confirm email is working).

When to Escalate to Oblytech or ServiceNow Support

Escalate if: data sources are not authenticating despite correct credentials (likely a platform or integration issue); the platform is performing slowly (query timeouts, dashboard loading slowly); or you have made configuration changes and want a second opinion on correctness. Provide details: which data source is failing, what error message is shown, and what you have already tried to fix it. Escalation time depends on the issue and on how complete the details are.