ServiceNow Notifications and Email Handling: Security and Access Design

A notification leaves the platform the moment it is sent, and whatever it carries is then forwarded, archived and searched outside any access control the instance applies. This page covers role-based recipient and content rules, data masking for personal and financial data, passwords and tokens that must never appear in a message, email handling security, segregation of duties, audit logging, a design checklist and review cycle, and when sensitive content should not use email at all.

Role-Based Notification Access

Recipient Role Assignment

Notifications in ServiceNow are sent based on recipient role. For example, an incident notification goes to the assigned group. If the assigned group includes members without a business need for the information, they should not receive the notification. Use role hierarchies or dynamic groups to restrict notification recipients. Example: only senior engineers should receive notifications about critical security incidents, not all engineers.

Content-Based Access Control

Some notifications should contain full details; others should contain only a subset. Define notification rules that filter content based on recipient role. For example, a financial audit notification to finance staff includes account numbers and amounts; a notification to other stakeholders is generic (audit scheduled, completed, or failed). This requires multiple notification templates tied to recipient roles.

Data Masking in Notifications

Masking Personal Data

Notifications may include personal data (employee names, phone numbers, email addresses). Depending on recipient role and regulatory requirements, some data should be masked. For example, a change notification to customer-facing staff may mask employee SSN and internal phone numbers. Implement masking rules in your notification workflows; test them to ensure data is genuinely masked.

Masking Financial Data

Invoice notifications, budget notifications, and payment notifications contain financial data. Finance staff need full details; other recipients should see only summary amounts or no amounts at all. Use different notification templates for different audiences.

Password and Token Masking

Never send passwords or API tokens in notifications, even to the intended recipient. If a reset is needed, send a link to a secure password reset flow; do not send the temporary password in email. Audit logs should not contain passwords either; log only that a password reset was issued.

Email Handling Security

Email Injection Prevention

If your notifications include user-supplied content (e.g., a comment from an incident), validate and sanitise that content before including it in email. Malicious content in user input (e.g., shell commands, HTML injection) could compromise email or email clients. Use email templating libraries that escape HTML and special characters.

Reply-To Address Configuration

Configure reply-to addresses carefully. If a notification is sent from a distribution list or no-reply address, replies go to that address; if the address is not monitored, replies are lost. Alternatively, set reply-to to the ticket or request URL, so replies create a comment in the system. Document the intended reply behaviour so recipients understand.

Attachment and Link Handling

Notifications may include links to records or reports. Links should be routable (the recipient can access the URL), and they should not leak sensitive information in the URL query string. For example, use record IDs, not sensitive data, in URLs. Do not attach sensitive files to emails; instead, provide a link to a secure download.

Segregation of Duties in Notifications

Who Can Modify Notification Rules?

Notification rules control who receives what information. Restrict modification of notification rules to a limited set of roles: Platform Administrators and potentially Security teams. A user who can modify notification rules can redirect sensitive alerts to themselves. Audit changes to notification rules and escalate suspicious changes.

Who Can Send Notifications?

In typical configurations, the system sends notifications based on workflows and rules, not manual user action. If you allow users to manually send notifications, restrict this to certain roles and audit all manual sends. Manual notification sends are often used for social engineering or information leakage; be cautious.

Audit Logging

Notification Delivery Logging

Log every notification sent: recipient, content, timestamp, and reason. Use these logs for audit and investigation. Query logs to answer: who received this sensitive notification? Was it delivered correctly? Did any failed deliveries need follow-up?

Email Forwarding and Retention Audit

Email forwarded outside your organisation is a data leakage risk. Detect and audit email forwarding (e.g., rules that automatically forward notifications to external addresses). A user forwarding incident emails to their personal account is a security incident. Set up alerts for suspicious forwarding patterns.

Access to Notification Records

In some configurations, users can access notification records (viewing what notifications were sent). Restrict this view to Administrators and Auditors. A regular user viewing notification records could find information they should not have access to.

Design Checklist

• Recipient roles are defined and tied to notification templates
• Notification rules restrict content based on recipient role
• Sensitive data (PII, financial, passwords) is masked in notifications
• Email templates escape user-supplied content
• Reply-to addresses are configured appropriately
• Modification of notification rules is restricted to Admins
• Notification delivery is logged for audit
• Email forwarding is monitored and logged
• Access to notification records is restricted

Review Cycle

Review notification rules and access controls annually. Test that masking works correctly for each sensitive data type. Audit notification logs for anomalies (unexpected recipients, unusual timing, forwarding). Update notification templates when workflows change to ensure data masking rules are still accurate.

Many security reviews of notifications start with the platform, as the notifications and email handling guides would suggest: who can see which record, which fields are visible, and who can edit a rule. Those questions matter, but a message does not stay inside the platform once it is sent. It lands on a lock screen, syncs to a phone, sits in a shared mailbox, gets copied into an archive and is sometimes forwarded before anyone decides it should not have been. A review that stops at the instance leaves those paths unexamined.

Following a message past the point where it leaves the platform

Trace one sensitive notification from its trigger to the last place it is stored, using the same audit evidence approach described in the audit trail evidence guidance. The trace often passes through the mail relay, the recipient’s device, any shared or delegated mailbox the recipient can read, the organization’s mail archive and any backup of those systems. Each stop can widen the audience. The purpose of the review is to decide, for each stop, whether the content is acceptable there, and if not, to change the message rather than rely on the stop being secure.

Deciding what must never be in a message body

The safest sensitive value is the one that is never sent. Before a template is approved, list every field it would print and ask whether the recipient needs that value to act, or only needs to know that the record has changed. In many cases the answer is the second, and the message can carry a record number and a sentence instead. Where the value is needed, the message should send the recipient to the record and let the platform’s own access rules decide whether they can see it. A template that quotes a value because it was convenient is a common source of avoidable exposure.

1. List every field each template prints, including those pulled in through a related record.
2. Mark each field as needed-to-act, needed-to-know, or not needed.
3. Remove the not-needed fields, and replace needed-to-know fields with a status sentence.
4. Route needed-to-act fields through a link that requires sign-in to view.
5. Test the rendered message on a phone lock screen and in a shared mailbox, not only in the template preview.

Rules created outside the change process

Not every notification is built through the formal change path. Scripts and flows can send messages, and a user with enough access to create one may not be in the group that reviews notification changes. Restrict who can create or enable outbound messages, log those changes, and review the log on a schedule. Access reviews for the rules can follow the same cadence as the access recertification cycle. An unexpected rule is often the first sign that someone is using notifications to move data out of a record, whether by mistake or on purpose.

When sensitive content should not use email at all

Credentials, reset details and certain personal records belong in a secure flow that asks the recipient to authenticate, not in a message. Where the process truly requires a document to reach an outside party, a controlled sharing mechanism with an expiry and an access log is safer than an attachment. Say so in the design, so that a later requester does not add the field to an email because it was the quickest route.

Is encrypting email enough?

Encryption protects the message in transit and sometimes at rest, but it does not stop the recipient from reading, copying or forwarding it. Treat it as one control among several, and design the content as though it will be read by someone who should not see it.

Who should review a notification template for security?

The process owner for the data, with the security contact confirming the exposure points. A platform administrator can check the technical handling, but the decision about what the business is prepared to send belongs to the owner.

How should a breach of notification content be handled?

Treat it as an incident in the normal security process. Record which message went to which recipients, identify the content, and decide with the data owner whether notification of the affected people is required under the organization’s obligations.

Do shared mailboxes ever receive restricted content?

The safer answer is no. A shared mailbox has many readers, and the list of people who can open it changes over time. If a team needs restricted detail, route it to named individuals or through the record instead.