When exposing data externally to customers, the risk of security breaches and data leakage increases, especially on a platform that houses both internal and customer data. ServiceNow operates as a shared responsibility platform, meaning that while the platform provides built-in security features, organizations are responsible for configuring and managing access controls, authentication policies, and data protection measures.

Over the years, I’ve compiled a set of best practices for securing CSM data, helping organizations mitigate risks and avoid common pitfalls. By following these guidelines, you can ensure a secure implementation while minimizing the chances of costly security incidents.

Application Scopes

When creating new case types in ServiceNow, it's considered a best practice to place each case type in its own scope. This practice ensures better organization, modularity, and security of your configurations. By isolating each case type within a separate scope, you can avoid cross-scope access issues, which enhances the maintainability and scalability of your case management system.

Placing a case type in a scope allows you to manage and encapsulate all the related artifacts—such as business rules, client scripts, UI policies, and workflows—within a defined boundary. This modular approach not only helps in organizing the components related to a specific case type but also makes it easier to apply updates, troubleshoot issues, and maintain the system over time. Each scope can have its own set of permissions and access controls, ensuring that only authorized users can modify or access the configurations within that scope.

Creating ACLs for All Case Types

Implementing ACLs: It's a best practice to create Access Control Lists (ACLs) for all case types in ServiceNow Customer Service Management (CSM). ACLs define the permissions required to access and modify case records, ensuring that only authorized users can perform specific actions such as create, read, update, or delete.

Best Practices for ACLs:

1. Role-Based Access: Define ACLs based on user roles to ensure that permissions are appropriately granted.
2. Condition-Based Controls: Use conditions within ACLs to apply access rules dynamically based on specific criteria.
3. Regular Reviews: Periodically review and update ACLs to adapt to changes in user roles and organizational requirements.

Utilizing CSM Query Rules

Implementing Customer Service Management (CSM) query rules in ServiceNow is a best practice for managing data visibility and access efficiently. Query rules allow you to define and enforce conditions that control which records are displayed to users based on their roles and specific criteria.

Authentication 

Avoid Local Authentication, Leverage SSO

Leverage Single Sign-On (SSO): Single Sign-On (SSO) authentication should always be utilized for consumers and contacts to streamline and secure the authentication process. SSO enables users to log in with a single set of credentials across multiple platforms, enhancing security by enforcing centralized password policies and reducing the risk of password-related breaches. For consumers and contacts, this also means a smoother and more efficient login experience, reducing friction and improving satisfaction.

Avoid Local Authentication: In the context of Customer Service Management (CSM), it's best practice to avoid using local authentication for consumers and contacts due to security risks and management complexities. Local authentication can result in inconsistent password policies, higher chances of unauthorized access, and increased administrative overhead in managing user credentials.

Provisioning Best Practices: Implement automated user provisioning through SSO to ensure that consumer and contact accounts are consistently and securely managed. This includes automatic creation, updating, and deactivation of user accounts based on their status in the identity provider. Automated provisioning reduces the risk of orphaned accounts, ensures compliance with access policies, and simplifies user account management, particularly for large and dynamic consumer bases.

Restricting Case Creation to Users with Consumer or Contact Records

Restrict Case Creation: It's a best practice to restrict case creation in ServiceNow Customer Service Management (CSM) to only those users who have valid consumer or contact records. Allowing case creation for users without these records can lead to data inconsistencies, unauthorized access, and difficulties in managing and resolving cases effectively.

Ensure Data Integrity: By restricting case creation to users with established consumer or contact records, you ensure that all cases are associated with verified and identifiable individuals. This practice maintains the integrity of your case data, making it easier to track, manage, and resolve cases efficiently. It also helps in maintaining accurate records of interactions and communications with consumers and contacts.

Enhanced Security: Restricting case creation helps prevent unauthorized users from submitting cases, thereby protecting your instance from potential abuse and ensuring that only authenticated and validated users can interact with your CSM platform. This security measure reduces the risk of fraudulent activities and ensures that only legitimate issues are addressed.

Requiring Authentication Before Case Creation

Mandatory Authentication: Requiring users to authenticate before creating cases in ServiceNow Customer Service Management (CSM) is a critical best practice. This ensures that only authorized individuals can submit cases, maintaining the integrity and security of your case management system. Authentication helps verify the identity of the user, ensuring that all submitted cases are legitimate and associated with verified consumer or contact records.

Security Issues with Public Case Submission: Allowing public, unauthenticated case submissions poses significant security risks. Unauthenticated submissions can lead to spam, fraudulent cases, and potential abuse, overwhelming your instance (e.x. Denial of Service Attacks) and making it difficult to manage and resolve legitimate issues. Public case submission also increases the risk of exposing sensitive information to unauthorized individuals, which can compromise the security and confidentiality of your data.

Adaptive Authentication

Adaptive authentication enhances security by dynamically enforcing access controls based on user context, such as role, IP address, and location. Adaptative Auth evaluates authentication requests against predefined policies, granting or denying access based on risk factors. For example, a user logging in from an untrusted location may require multi-factor authentication (MFA), while a trusted user on a corporate network experiences seamless access.

This approach is a best practice because it strengthens security without disrupting user experience. By enforcing stricter authentication only when needed, organizations reduce friction for trusted users while blocking unauthorized access. It also extends to REST API access control and supports domain separation, ensuring tailored security across business units. Adaptive authentication helps ServiceNow customers balance security and usability, reducing breach risks while maintaining smooth access.

Credit ServiceNow documentation.

PII/PHI Customer Data

Encrypting sensitive data in ServiceNow Customer Service Management (CSM) is a critical best practice to protect confidential information from unauthorized access and breaches. Encryption transforms data into a secure format that can only be accessed by individuals with the correct decryption key, ensuring that sensitive information remains confidential even if it is intercepted or accessed by unauthorized users.

Best Practices for Data Encryption:

1. Identify Sensitive Data: Determine which data needs to be encrypted based on its sensitivity and regulatory requirements.
2. Encrypt Data at Rest and in Transit: Ensure that sensitive data is encrypted both when stored (at rest) and when transmitted over networks (in transit).
3. Regular Audits: Conduct regular security audits to verify that encryption methods are properly implemented and up to date.

Methods of Encrypting Sensitive Data:

• Column Level Encryption: Column Level Encryption (CLE), formerly Encryption Support, permits and denies access to encrypted data based on user role.
• Cloud Encryption: Uses a ServiceNow-generated key or a customer-created key to protect sensitive data at rest in ServiceNow datacenters. It employs FIPS 140-2 Level 3 validated hardware security modules (HSM) and AES 256-bit encryption.
• Full Disk Encryption (FDE): Encrypts the entire storage system within the database server. This method is suitable for customers with legal obligations to protect data.
• Edge Encryption: Encrypts sensitive data on a company's premises before sending it to a ServiceNow instance over the internet. Edge Encryption includes tokenization, which masks specific data patterns within a field, and mass key rotation, which automatically encrypts data with new keys to protect historical records.
• Database Encryption (DBE): Another method for customers with legal obligations to protect data.

Sensitive Data Handling in Agent Chat and Virtual Agent

Detect and Mask Sensitive Information: In ServiceNow, it's a best practice to configure the Sensitive Data Handler to automatically detect and mask sensitive information shared in Agent Chat or Virtual Agent conversations. This involves setting up rules to identify sensitive data such as personal identifiers, financial details, or proprietary information, and then masking this data to prevent exposure. This approach enhances data security, ensures compliance with privacy regulations, and protects sensitive information from unauthorized access during conversational interactions.