Create a Next Generation API Data Protection Policy

This article describes the steps to create a Next Generation API Data Protection policy on the Netskope tenant UI. Before that, lets understand a fundamental concept of Next Generation API Data Protection.

Exposure-Based vs. Actor-Based Policies

Exposure-based policies evaluate the state of data — for example, whether a file is publicly shared or accessible to external users. Actor-based policies evaluate the identity of the user who performed a specific activity — for example, who created a public sharing link.

Next Generation API Data Protection supports exposure-based policies only. Actor-based policy definition is not supported. For actor-based enforcement, use Inline CASB.

Actor-based policy definition is not supported due to the following limitations:

• Rate limiting. Because Next Generation API Data Protection operates in out-of-band, it can be subject to rate limiting. In such situations, actor-based policies may be applied incorrectly. This risk does not exist in Inline CASB.

• Race conditions. Delays in receiving event notifications from SaaS providers can cause the policy engine to process incomplete data, making actor-based matching unreliable.

• Increased policy complexity. Netskope provides a consistent policy interface across all supported SaaS applications to simplify authoring and long-term management. Introducing app-specific exceptions for actor-based support breaks this consistency and significantly increases management overhead.

Create a Next Generation Policy

To create a Next Generation API Data Protection policy, follow the instruction below.

Based on your requirements, select the following options:

1. Log in to the Netskope tenant UI.

2. Navigate to Policies > API Data Protection.

   The API Data Protection page loads.

3. Under SAAS, click the Next Gen tab.

4. Click New Policy.

   The New API Data Protection Policy page loads.

5. Under Object, based on your requirements, select the following options:

   • All Applications: Apply the policy to all SaaS apps and instances.

     If you select All Applications, some actions may be disabled because each application supports different actions. For example, when you select All Applications, only the actions supported by ‘all applications’ will be available. If even one application does not support a specific action, such as the quarantine action, that action will be disabled in the UI under these conditions.
     For granular controls in policy definition, Netskope recommends using the Applications, or App Instance options.

   • Applications: Apply the policy to the respective SaaS app(s) you select. On selecting this option, all app instances of a specific SaaS app gets included for policy scanning.

   • App Instance: Apply this policy to the respective SaaS app instance(s) you select.

     Select this option if you intend to use classification of files using Box labels. To apply the Box sensitivity label action, the user must select the same Box instance used for Sensitivity Label Integration when creating the Next Gen API Data Protection policy.
     To identify if the Microsoft 365 OneDrive or SharePoint app instance is GCC High or commercial, a GCC High app instance name will be suffixed by .us.

   • CCI Categories: Apply the policy based on the type of SaaS app solution. If you select a category, all the corresponding SaaS app and instances are included for policy scanning. Here are the SaaS app categories and corresponding SaaS apps:

     • Cloud Storage: Box, Dropbox, Egnyte, Google Drive, Microsoft 365 OneDrive, Citrix ShareFile

     • Collaboration: Atlassian Confluence, Cisco Webex, Google Calendar, Microsoft 365 Teams, Microsoft 365 SharePoint, Microsoft 365 Yammer, Slack Enterprise, Smartsheet, Zoom.

     • Customer Relationship Management: Salesforce

     • Development Tools: Atlassian Jira, GitHub

     • Generative AI: ChatGPT Enterprise, Microsoft Copilot

     • HR: Workday

     • IaaS/PaaS: ServiceNow

     • Webmail: Google Mail, Microsoft Outlook

       For Application and Categories, you can also exclude certain SaaS apps and instances from the purview of policy scanning. To do so, select the Application or Categories option from the Object drop-down list and click the Exclusions drop-down list and select the SaaS app/instance.

   • Content: Click the Specify App Instance drop-down list, select the SaaS app instance. The scan content window opens. You can either select All content or Specific resources. On selecting Specific resources, include and exclude the resource IDs to scan. Click Save.

     You can have a more refined scanning of Microsoft 365 SharePoint objects. With this enhancement, you can include and exclude a SharePoint file, folder, or sub-site by site name or site ID. Under Scan Content, select Specific Resources. Click the edit box under Specify Resources to Scan and Specify Resources to Exclude. Select the appropriate SharePoint file, folder, or sub-site from the drop-down menu.
     Currently, Netskope can scan outgoing emails’ sent folder only. It is recommended to set the scan content to All content for webmail apps.
     To get the resource ID, navigate to API-enabled Protection > CASB API (NEXT GEN) > Inventory. Click an entry from the Name field to view the details page. Note down the Resource ID value.
     Sample Resource ID:
     If you plan to scan a specific repository in GitHub, follow the procedure below.

     1. Navigate to API-enabled Protection > CASB API (NEXT GEN) > Inventory.
     2. Click the Content Collections > Repository tab.
     3. Identify the GitHub repository from the Name field. Click it.
        The details pane opens.
     4. Copy the Resource ID value.
     
     5. Go back to the policy wizard page Content > Specify App Instance > Specific resources, paste the resource ID under Specify Resources to scan.
     6. Click Save.

   • Add Criteria: Under this option, you can filter the policy further based on the following:

     • File Type: Apply the policy for a specific file type category. A few file type category examples are audio, image, word processor, presentation, video, etc.

       • The file type option is available for Generative AI, HR, email, and cloud storage apps only.
       • The file type criterion will only be matched against files. Other non-file resources will ignore this criteria.

     • Resource Type: Apply the policy for a specific specific resource category. A few resource type category examples are file attachment, email message body, chat message body, etc. Based on the SaaS apps you have selected, choose the appropriate resource type:

       • File/Attachment: Files attached in apps like Atlassian Jira, Gmail, Google Calendar, Microsoft 365 Outlook. Select this resource type for apps like Gmail, Google Calendar, and Microsoft 365 Outlook.

       • Email Message Body: Subject and body of the email. Select this resource type for email app like Gmail.

       • Chat Message Body: Content of a chat message. Select this resource type for chat messenger apps.

       • Comment: A comment left in a Atlassian Confluence page or Jira ticket. Select this resource type for Atlassian Confluence and Jira apps.

       • Page: A page created, edited, or deleted in Atlassian Confluence. Select this resource type for Confluence app.

       • Source Code Commit: This is applicable to development tools like GitHub where you’d like to monitor source code commits.

       • Title/Description: This is applicable to Google Calendar to monitor title and description of the Google calendar invitation.

       • Ticket: This is applicable to Atlassian Jira app to monitor Jira tickets.

       • AI Response: This is applicable to generative AI apps to monitor responses from the generative AI apps.

       • User Prompt: This is applicable to generative AI apps to monitor prompts entered by the end user.

       • Repository: This is applicable to GitHub to monitor if the repository is made public.

       • Top-Level Entity: This is applicable to Microsoft 365 SharePoint top-level sites.

     • Scan Content Type: Apply this policy for a specific app content type category like storage, ticketing, or messaging.

       • Storage: AI-Managed Folder, Personal Drive, Team Drive

         If you select AI-managed folder, you must regrant access to your Microsoft 365 OneDrive instance.

       • Generative AI: Fine Tuning Data, Memory

         – These options apply to ChatGPT Enterprise app only.
         – For fine tuning data uploads, Next Generation API Data Protection supports files up to 128 MB for DLP scan.

       • Ticketing: Custom Objects, Default Objects

       • Messaging: Direct Messaging, Private Channels, Public Channels

       • Calendar: Primary Calendar, Team Calendar

       To learn more: Scan Content Type.

     • Activity Type: Apply this policy for a specific user activity type category.

       • Box: Edit, share, un-share, upload, rename, move, copy, restore, lock, unlock, view, and download.

       • GitHub: User added to repository and user added to organization.

     • Google Label Badge: This option gets enabled only if you select Google Drive under Applications. Under Badge Value(s), enter the Google badge values. Separate multiple values by a new line. To know the badge values, log in to your Google Drive admin account and navigate to Security > Access and data control > Label manager. With this capability, Netskope can read through the badge values in Google Drive and apply a policy action. For example, if a document matches a badge value which is deemed sensitive, an alert action can be taken. Currently, you can apply the alert policy action only.

       – Before you can use Google label badge, ensure that you meet the prerequisite as documented here.
       – For Netskope integration to work, customers must define a single label that includes all required badge fields. No additional standard labels should be present.

     • Owner: Owner is a user who owns a file, mailbox, or chat history. There are multiple options under Owner. If you do not select any option, all users are selected by default.

       The Owner drop-down is disabled by default. To enable, select an app a listed below.

       How ownership is determined?

       Application	Owner Definition
       Atlassian Confluence	– Page: The page or content creator. – Comment: User who posts the comment. – File: File creator or uploader.
       Atlassian Jira	– Ticket: A ticket owner is assignee. – Comment: A comment owner is the parent ticket’s assignee. – File attachment: A file owner is the parent ticket’s assignee. Known Issue In Jira Cloud, users can configure privacy settings to hide their email address from API responses. When this setting is enabled for a ticket assignee (owner), the Jira API returns a null value for the emailAddress field. Impact When the owner’s email address is not available: – Owner domain or email-based policies do not match Policies such as “Owner domain is @company.com” cannot be evaluated because the owner’s email is unavailable. – Owner user profile or domain profile policies do not match Domain-based classification cannot be determined without the owner’s email address. – Owner is treated as external for exposure evaluation In the absence of domain information, the owner is classified as external. Only policies that include external exposure criteria are triggered. This is a platform limitation in Jira and not specific to the Owner attribute feature. The same behavior applies to existing exposure and collaborator-based policy evaluations.
       Box	File or folder owner. Note: Box only allows one designated owner.
       Cisco Webex	– File: File creator or uploader. – Message: Message sender.
       Dropbox	Folder owner is the file owner. Files in team folder are not supported.
       Egnyte	Private folder: Private folder owner is the files owner. Shared folder: Not supported.
       Email apps (Gmail, Microsoft 365 Outlook)	In Next Generation API Data Protection, there is a concept of “owner”, which means the “mailbox owner.” Currently, Netskope only support outgoing emails for scanning. In this case, the owner will always be the sender. To maintain the policy filter behavior while taking the owner definition into account, Netskope restricts the scanning of emails within the Sent folder only.
       GitHub	Code commits: User who commits the source code to the repository (not the author).
       Google Calendar	The owner(s) of the calendar/event. For events, ownership is transferrable.
       Google Drive	My Drive files: The file creator, including cases where ownership has been transferred. Shared Drive files not supported.
       Microsoft 365 OneDrive	The drive owner is the owner of file irrespective of who creates the file within the drive. For example, if user X creates a file in user Y’s drive, user Y is the file owner.
       Microsoft 365 SharePoint	The file creator is treated as the owner of the file.
       Microsoft 365 Teams	– File: The file creator on the corresponding SharePoint site. This differs from Classic API Data Protection, which treats the last modifiers or senders as attachment owners. – Message: Message sender.
       Microsoft Copilot	Message sender. The user that created the prompt.
       Salesforce	– File: File creator or uploader. – Not supported for message, page and comment.
       Slack Enterprise	– File: File creator or uploader. – Message: Message sender.
       Smartsheet	– File: File creator. – Comment: User who posts the comment.
       Workday	File creator or uploader.
       Zoom	– File: File creator or uploader. – Message: Message sender.

       Owner options:

       • User: Displays the total number of mailbox owners in a web mail app. You can select one or many users.

       • User Group: Next Generation API Data Protection supports Active Directory (AD) user group as a collaborator option. With this enhancement, you can include AD user groups from 3rd-party identity vendors. Select a user group from the list. User groups are part of the directory importer installation. If you do not see a populated list, you should import the AD user group. To do so, go to Settings > Tools > Directory Tools > SCIM Integration to set up your SCIM integration. To learn more: SCIM-Based User Provisioning.

         If a file is accessible to only some users within the AD group, Netskope considers it as a policy match.

       • User Profile: A set of users as defined in the user profile. User profiles allow you to upload a CSV file with all the users email addresses to include or exclude in a scan for policy violations. You can select one or many user profiles.

       • Domain: Displays a list of domains. You can select one or many domains.

       • Domain Profile: You can select a domain profile consisting of a list of custom domains. To create a domain profile, navigate to Policies > PROFILES > Domain. You can select one or many domain profiles.

       • Exclusions: You can set an exclusion list whereby the policy excludes scanning for the selected criterion. You can set an exclusion list from user, user group, user profile, domain, and domain profile.

         For a file to be excluded from scanning, all shared domains must be part of the exclusion list. If the file is shared with even one domain outside the exclusion list, it will be scanned.

     • Region: Enable Detect Cross-Region Policy. On enabling this setting, the policy detects cross-region file exposure between connected multi-geo regions.

       The policy detects cross-region file exposure only for multi-geo regions that are explicitly onboarded during instance setup.

6. Under Exposure, select the following option:

   • Exposure: Users are individuals or bots associated with an account in the protected application, and with (read or write) access to content in the application. There are multiple options under Exposure. If you do not select any option, all exposure types are selected by default. On clicking Add Definitions, there are 2 options – Definition & Exclusion. Based on your requirements, you can include and/or exclude from the selection match options below:

     Exposure computation works at a ‘collaborative’ level. For example, if the administrator includes ‘user 1’ in a policy, any file that is shared with ‘user 1’ even by users who are not part of the policy will trigger a policy alert.
     Salesforce supports exposure filters only for files. To learn more: Salesforce File Exposure Guidance.
     For Atlassian managed accounts, Next Generation API Data Protection can retrieve Atlassian Confluence users’ email address only if the email address visibility is set to either “Anyone” or “”. This is the default setting for Atlassian managed accounts. If the user email is private, the exposure options are not available. To check if the user email address is public:

     1. Log in to your Atlassian account and view the Profile and visibility page: https://id.atlassian.com/manage-profile/profile-and-visibility.
     2. Scroll down to the ​Contact​ section and ensure that your email address visibility is set to either ​Anyone​ or ​your company name​​.
     • You can leave the User field empty (except for Microsoft Yammer). If you do so, all users will be scanned.
     • Workday note: Netskope uses the primary email of the user to calculate the domain exposure.
     • GitHub note: There is a GitHub policy enhancement on exposure options. To learn more: GitHub Policy Enhancement

     • INTERNAL/EXTERNAL: A list of file sharing exposure options are:

       • Owner: Not shared with anyone.

       • Internal: Shared between users and groups from one single domain defined in Internal Domains or defined as an internal user in the app instance.

       • All Internal Users: Shared between all users and groups within the organization.

       • External: Shared with external users and groups.

       • Anonymous: Shared with general public. Accessible by anyone.

       • SharePoint/OneDrive: All internal users via EEEU. This exposure is for files shared specifically via ‘everyone expect external users’ group in OneDrive and SharePoint.

       To learn more: Next Gen File Sharing Exposure.

       • Citrix ShareFile & Workday note: Currently, Netskope does not use the internal domains setting to calculate the exposure level for Citrix ShareFile and Workday.
       • GitHub note: There is a GitHub policy enhancement on exposure options. To learn more: GitHub Policy Enhancement

       
       

       • Microsoft Yammer note: Anonymous user does not exist in Microsoft Yammer. All users are on the Yammer organization.

       A few examples of the file sharing exposure:

       1. If you want to run a policy to match all the internal named users (e.g, michael@abc[.]com, steve@abc[.]com etc.), you can select the Internal options to show all documents shared with named users.

       2. If you want to run a policy to match all internal users irrespective of the sharing options, whether they are shared with a link or a named user, you would select the following options:

          • Owner

          • Internal

          • All Internal Users

            This will match all files that are shared with either of the above exposure options.

     • User Geo: This matches entities flagged as originating from a particular multi-geo location. On selecting this filter, you can select multiple user geo locations.

       This exposure filter applies to Microsoft 365 apps only.

     • User Group: Next Generation API Data Protection supports Active Directory (AD) user group as a collaborator option. With this enhancement, you can include AD user groups from 3rd-party identity vendors. Select a user group from the list. User groups are part of the directory importer installation. If you do not see a populated list, you should import the AD user group. To do so, go to Settings > Tools > Directory Tools > SCIM Integration to set up your SCIM integration. To learn more: SCIM-Based User Provisioning.

       If a file is accessible to only some users within the AD group, Netskope considers it as a policy match.

     • User Profile: A set of users as defined in the user profile. User profiles allow you to upload a CSV file with all the users email addresses to include or exclude in a scan for policy violations.

       • User profiles must be added before they are listed here. To download a CSV file that contains your user profiles, go to Policies > Profiles > User, and then click New User Profile. Complete the steps in the New User Profile wizard, and then select a user profile here.
       • GitHub note: There is a GitHub policy enhancement on exposure options. To learn more: GitHub Policy Enhancement

     • Domain: Displays a list of domains. You can select one or many domains.

       Smartsheet does not support domain-based exposure policy.

     • Domain Profiles: You can select a domain profile consisting of a list of custom domains. To create a domain profile, navigate to Policies > PROFILES > Domain.

       • Citrix ShareFile & Workday note: Currently, Netskope does not use the domain profiles setting to calculate the exposure level for Citrix ShareFile and Workday.
       • GitHub note: There is a GitHub policy enhancement on exposure options. To learn more: GitHub Policy Enhancement

     • # Internal Named Users: To set thresholds for when content sharing triggers a policy violation, click to set the range and number of internal users. Select the More Than or Less Than radio button and enter the number of internal collaborators that need to be detected for a policy violation to occur.

     • Exclusions: You can set an exclusion list whereby the policy excludes scanning. You can set an exception list from user profiles, internal & external domains, anonymous users, and domain profiles.

       – When creating a Next Generation API Data Protection policy with an External or Anonymous exposure scan type, and one or more domain profiles are added to the exclusion field, Next Generation API Data Protection now automatically selects All Internal Domains in the domain profile exclusion list. Administrators can remove the pre-selected All Internal Domains domain profile at any time based on their requirements.
       This behavior reflects the intended use of external/anonymous exposure policies, which are designed to detect files shared outside the organization. When domain profiles are used in exclusions to carve out specific external domains, the implicit intent is also to exclude all internal domains from the scan scope. Previously, internal domains were not selected by default in Next Generation API Data Protection, which could result in unintended scan behavior.
       – GitHub note: There is a GitHub policy enhancement on exposure options. To learn more: GitHub Policy Enhancement

7. Under Profile & Action, select the following options:

   For a complete list of apps that support various profiles and actions, see Next Generation API Data Protection Feature Matrix per Cloud App.

   • Profile: You can select either of the following options:

     • None

     • DLP: If you select this option, select one or more predefined or custom DLP profile(s) from the list. To manage DLP profiles, navigate to Policies > PROFILES > DLP. For more information on managing DLP, see Data Loss Prevention.

     • Threat Protection: If you select this option, choose the default predefined malware scan profile. Custom malware profile will be introduced in a future release.

       Next Generation API Data Protection follows the same long-standing behavior as Classic API Data Protection when handling malicious files. If a SaaS application detects and blocks malware, Netskope does not execute any configured remediation actions. Instead, the threat protection engine generates an alert to notify the customer, without applying policy-based remediation actions.

       You can configure a severity-based remediation action – low, medium, and high. For each severity, you can define an action. A threat protection policy defines the severity based action executed in case of a policy match. If you select quarantine as an action for a severity, the UI prompts you to enter an optional password. This is the password to open the the malware infected quarantined file. Though the password field is optional, Netskope does not recommend to leave this field empty because a few compression software do not support empty password.

       

       – It is important to note that the severity-based remediation actions for threat protection in Classic API Data Protection were at the tenant-level (Settings > Threat Protection > API-enabled Protection). However, in Next Generation API Data Protection, it is at the policy level. This means you can have granular controls over this feature at a per policy level.
       – As part of this feature rollout, Next Generation API Data Protection will not support any 3rd party Endpoint Detection & Response (EDR). When you configure a severity-based remediation action for threat quarantine, there will be no option to select a remediation endpoint. You cannot configure a remediation profile under Policies > Threat Protection. As an alternative, you can leverage and perform the same actions using Netskope Cloud Exchange. For more information, see:
       – Carbon Black Plugin for Threat Exchange
       – CrowdStrike Plugin for Threat Exchange
       
       

       
       
       • Next Generation API Data Protection supports files up to 128 MB for DLP and threat protection. The default file size is set to 32 MB. However, if you’d like to try this enhancement, contact your Netskope sales representative/support to enable this on your tenant.
       
       
       • Netskope can detect malware in Atlassian Confluence file attachments only.
       
       

       
       

   • Action: The action to be taken when a policy violation occurs.

     For a list of apps that support various actions, see Next Generation API Data Protection Feature Matrix per Cloud App.

     • Alert: When you select this action and a policy violation occurs, Netskope sends a notification in Skope IT > Alerts page.

       Alerts are generated for the last 30 days only.

     • Access Review: This action sends a notification to the Microsoft 365 SharePoint site owner to review and remediate site-access permissions.

     • Apply Sensitivity Label: This action applies a Digital Rights Management (DRM) label to sensitive files. Data Rights Management is a class of solution aimed to classify and manage access to digital content. Netskope supports Box, Google, and Microsoft Purview Information Protection (MPIP, formerly Microsoft Information Protect) labels. With this action, you can apply either a Box, Google, or MPIP label on DLP-sensitive files. Once you select this action, you should select the DRM vendor, instance, and label. For a list of apps that support this action, see Next Generation API Data Protection Feature Matrix per Cloud App.

       – Before you can apply a Box, Google, or MPIP sensitivity label, you should set up a Box, Google, or MPIP instance first. To learn more: Digital Rights Management.
       – To apply the Box sensitivity label action, the user must select the same Box instance used for Sensitivity Label Integration when creating the Next Gen API Data Protection policy.
       – This feature is part of the Advanced DLP offering. To enable this on your tenant, talk to your Netskope sales representative.

     • Change owner to a specific user: This action changes the owner of the file to a specific user. On clicking this option, the UI prompts you to enter the email address of the specific user.

       Currently, this action is available for Google Drive and Workday apps only. To learn more: Policy Action Special Behavior.

     • Delete: This action deletes violating files, folders, chat messages, et al. For per SaaS app nuance, see Next Generation API Data Protection Feature Matrix per Cloud App.

       Ensure that you refine the policy as required. If you set the exposure level to ‘all’ and policy action to ‘delete’, the policy will delete all content from the storage app.

       Unlike classic API Data Protection, the delete action does not require to be bound with a DLP profile, which means the policy can delete content collections such as folders. However, due to SaaS apps’ upstream API capability, some of the special content collections may not be deleted even if the policy matches:

       SaaS app / Containers that can be deleted	Files	Folders	Personal Drive	Shared Drive	Sites
       Google Drive	Yes	Yes	No	Yes	Not applicable
       Microsoft 365 OneDrive	Yes	Yes	No	Not applicable	No
       Microsoft 365 SharePoint	Yes	Yes	Not applicable	Yes	No

     • Quarantine: This action isolates the affected file and tombstones it. Select an existing quarantine profile from the list, or create a new one. To learn more: Create a [Next Gen] Quarantine Profile.

       Additional reading:
       – Quarantine Tombstone for Microsoft Office 365 File Types
       – Quarantine Tombstone for Google Workspace File Types

     • Legal Hold: This action allows organizations to preserve all forms of relevant information when litigation is reasonably anticipated. If a file meets the policy criteria, you can opt to save a copy specifically for legal purposes. Select an existing legal hold profile from the list, or create a new one.

     • Restrict access to internal users: This action restricts the access of the file to users within the organization and domains as defined under Settings > Administration > Internal Domains.

       Special note on GitHub. To learn more: Policy Action Special Behavior.

     • Restrict access to owner: This action restricts the access of the file to the owner only.

       Special note on Google Drive. To learn more: Policy Action Special Behavior.

     • Restrict access to owner’s domain: Restrict access to users within the current domain. Remove file permissions if a user’s email domain differs from the file owner’s. Only users in the current domain will have access.

     • Restrict access to specific domains: Restrict access to users of the domains in the domain profile. Only users matching the specified domain profile will have access.

     • Restrict access to specific domains and internal users: This action restricts the access of the file to selected domain(s) and internal users as defined in the previous bullet item. On clicking this option, the UI prompts you to enter the domain profile name.

       If you do not have a domain profile defined, click Manage Domain Profiles to create a new domain profile.

     • Restrict access to specific users: Restrict access only to the users in the user profile. Only users matching the specified user profile will have access.

     • Revoke access from specific domains: This action removes access for users matching the specified domain profile. On clicking this option, the UI prompts you to enter the domain profile name.

       • If you do not have a domain profile defined, click Manage Domain Profiles to create a new domain profile.
       • Read Guest/External User Parsing Limitation under the appendix section for additional information.

     • Revoke access from specific users: Revoke access to all users except the ones in block-list user profiles. Remove access for users matching the specified user profile.

     • Revoke org-wide sharing: This action removes any kind of organization-wide sharing links.

       Anyone with a direct link or those who have been added to the document will still retain access.

     • Revoke public sharing: Remove general access/public links. Only users with access can open the files.

     • Revoke Users Added at the File Level: This action removes individually listed users be it internal or external from accessing the file. This action is currently available for Microsoft 365 OneDrive & SharePoint.

       Special note on Microsoft 365 OneDrive & SharePoint. To learn more: Policy Action Special Behavior.

     • SharePoint/OneDrive: Revoke EEEU sharing: For files shared specifically via ‘everyone expect external users’ (EEEU) group in OneDrive and SharePoint, this action removes the EEEU group exposure.
       

     • Disable print & download: Restrict users from printing and downloading files. You can apply this policy action to restrict access to view only.

     • Set Link Expiration Date: Publicly shared links will expire after ‘x’ days. When you select this option, a prompt will appear asking you to specify the number of days until the link expires.

       This action is available for Box storage app only. Log in to Box as an admin, then navigate to Admin Console > Enterprise Settings > Content & Sharing tab. Scroll down to the Auto-Expiration setting and enable Allow item owners and editors to modify the expiration date. This setting is required for this action to work.

     • Restrict sharing to view: Remove edit and comment permissions from files and folders.

   • + Notification: You can define an email or message notification for events in the policy wizard. These notifications, triggered by events like policy violations or alerts, provide administrators and designated user groups with timely information about important activities. Click + Notification to configure additional settings.

     For a list of apps that support email notification, see Next Generation API Data Protection Feature Matrix per Cloud App.

     • How often to notify people: You can select either a periodic interval (30 minutes, 60 minutes, 6 hours, 24 hours) or after each event. There are additional options for After each event. You can send a message notification to:

       The following options are presently available for Cisco Webex and Slack Enterprise apps only.

       • Acting user: User who sends the message or uploads a file that triggers a policy violation.

       • App instance owner: The organization owner who set up the Slack Enterprise instance. This option is available for Slack Enterprise only.

       • Group chat: Sends a message to a private space Netskope-Alert created by Netskope after setting up the Cisco Webex instance. This option is available for Cisco Webex only.

       • Selected user: Specific users based on email or user profile.

     • Send notification to: You can send a notification to:

       • Owner: Creator of the email, message, or file.

         The Owner field does not apply to repository when you configure email notification for GitHub.

       • Admin: Admin email that was configured as part of the instance setup.

       • Collaborators: Everyone with whom the email, message, or file is shared.

       • Last Acting User: This option sends alerts to the user who most recently acted on the file, including editing, sharing, or changing permissions, at the time the policy violation is evaluated.

         – This option is currently supported for storage SaaS apps only.
         – Last acting user or modifier is identified on a best-effort basis. SaaS apps like Microsoft 365 OneDrive may delay user data via APIs, so the user notified may be from a prior edit of the file.

       • Selected Users: Specified users.

       You can either use the default email template or create a new template for the notification.

     • From User: Optionally, you can enter an email address from whom the notification will be sent.

   • + Set Time Trigger: You can define a grace period during which a policy violation remains in an alert-only state, allowing users or administrators to remediate the issue or request an exception. If the violation is not resolved within the configured timeframe, the policy automatically enforces the follow-up action. Click + Set Time Trigger to configure additional settings.

     – This feature is being rolled out in a phased manner. If it is not yet enabled on your tenant, no action is required—availability will be extended to more tenants soon.
     – This setting is available only for SaaS applications that support actions beyond ‘Alert’. For a list of apps that support various actions, see Next Generation API Data Protection Feature Matrix per Cloud App.

     1. + Notification: You can set the notification the first time the policy matches.

        On the first policy match, the action is limited to Alert. Any subsequent matches before the timer expires, a Skope IT alert will be generated for record-keeping purposes.

     2. Follow-up action after X days: Define the grace period (1-90 days) for remediation before the policy action is enforced.

     3. Action: Define the follow-up action from the list of actions for the specific SaaS app that you selected under Object > Applications.

        The Only remove users how match the policy the first time checkbox is invoked when you select most Restrict Access actions. Use this option to control when users are removed from sharing or access as part of a deferred policy action. When enabled, only the users identified during the first policy match are tracked and removed when their individual timers expire. Any subsequent changes to this setting apply only to newly created timers, ensuring that existing deferred actions continue to run without interruption or retroactive impact.

        

     4. + Follow-up Notification: You can set the notification if the policy still hits after X days as defined earlier.

     To learn more about follow-up actions and pending triggers, see How to handle pending triggers?

8. Under Policy Name, enter the policy name. and a short description.

9. Under Status, based on your requirement, select the following options:

   • Disabled: Keep the policy disabled and enable it later.

   • Enabled: Enable the policy so that it takes effect immediately.

10. On the top-right, click Save followed by Apply Changes.

    You should see the newly created policy on the policy home page.

    If you have kept the policy disabled, make sure to enable the policy. You can click the more options icon (…) to the right of the policy entry and click Enable followed by Apply Changes.

Next, you can view the DLP incidents under Incidents > DLP. For more information on DLP incidents, see About DLP.

Appendix – Special Behavior of SaaS Apps

GitHub Policy Enhancement

Originally, certain data protection policy exposure options were unavailable for GitHub, like user profile, internal domains, external domains and anonymous users, domain profiles, and exclusions. This limitation stemmed from Netskope’s inability to retrieve users’ email IDs from GitHub. With the latest update, Netskope can now retrieve users’ email IDs from GitHub, opening up a world of possibilities for improved data protection. But there are some prerequisites:

• SAML SSO Configuration: To unlock this functionality, you must have SAML Single Sign-On (SSO) configured in your GitHub organization.

• Email as NameID: Ensure that the NameID for your SAML configuration is set to an email address.

• Enforced SSO: It’s crucial to enforce SSO for all members within your organization.

Once you’ve met these criteria, Netskope seamlessly retrieves users’ email IDs from GitHub. This breakthrough empowers you to leverage advanced policy exposure options, enhancing your GitHub data protection strategy.

Important Notes for GitHub Policies

When configuring a Next Generation API Data Protection policy for GitHub, keep the following limitations and behaviors in mind:

• Restrict Access to Internal Users action

  This action only removes external collaborators from the repository.

• Entity support
  Next Generation GitHub policies currently apply only to commits pushed to a repository.

Microsoft 365 OneDrive & SharePoint Commercial

• Guest/External User Parsing Limitation: Guest/external users included in a user profile will not be considered for exposure computation in OneDrive and SharePoint. This is currently a known limitation. As a workaround, guest/external user domains can be added to the domain profile.

• Delete Inherited Link: In Microsoft 365 OneDrive and SharePoint, files can inherit sharing links from a parent folder. When performing remediation actions—either manually from the Inventory page or via policies—if only certain users need their inherited access revoked, new sharing links may be generated at the file level to preserve access for others.

• Exposure Calculation for Deleted Groups: A file shared with a group that was deleted before provisioning the Netskope API Data Protection, the Exposure Status of the file on the Inventory page will be blank. To fix this, the Microsoft tenant administrator should revoke the permissions of the deleted group in the Microsoft tenant. Thereafter, Netskope can correctly calculate the exposure and execute policy actions for the file.

Slack Enterprise Channel Promotion and Conversation Policies

When a channel is shared with multiple workspaces or includes external users, Slack promotes it to the organization level. In Next Generation API Data Protection, the existing channel will be deleted, and a new one will be created for the promoted channel.

In Next Generation API Data Protection, you can bind specific policies to individual channels. If a channel is deleted during promotion, the policies previously set on that channel becomes invalid and will not transfer to the newly promoted channel automatically.

This applies only when you configure channel-specific policies.

Salesforce File Exposure Guidance

The Salesforce file exposure feature in Next Generation API Data Protection allows you to define policies based on how files are shared in Salesforce. This section outlines the current limitations and recommended best practices to help you configure policies effectively.

Important Notes

• Only file exposure is supported.

• Exposure for page, comment, and chat message body is not supported. Their exposure values are always reported as Unknown.

File Exposure Types

• ContentDocument (Salesforce Files)

  A ContentDocument represents a Salesforce file available in the Files tab in both Classic and Lightning experiences.

  Exposure definitions:

  • Anonymous – File has a direct public link.

  • External – File is directly shared with external users or groups containing external users.

  • All Internal Users – File is directly shared with the entire organization, giving access to all internal users.

  • Internal – File is uploaded to shared libraries or directly shared with internal users/groups (other than the owner).

  • Owner – File is uploaded to “Owned by Me” without being shared with others.

  Limitations (Salesforce API constraints):

  • Inherited permissions from parent libraries are not supported. Users or groups with access via library permissions cannot be identified.

  • Parent folder public links are not supported.

  • File share deletions are not tracked, which may cause inaccurate exposure reporting. This will be addressed in a future release.

• Document (Salesforce Classic Document)

  A Document represents a Salesforce Classic Document.

  Exposure definitions:

  • Anonymous – Document is publicly accessible when marked as Externally Available Image in Salesforce UI.

  • External – Not applicable. Salesforce APIs do not provide visibility into users or groups with direct access.

  • All Internal Users – Parent folder is configured as accessible by all users.

  • Internal – Parent folder is restricted to specific users/groups. The actual list of users cannot be retrieved via Salesforce APIs.

  • Owner – Parent folder is hidden from all users or the file is uploaded to My Personal Documents.

• Attachment (Salesforce Classic Attachment)

  An Attachment refers to files uploaded via the Notes & Attachments section in Salesforce Classic. Exposure is always set to Internal exposure.

  • Exposure is always set to Internal.

  • Access inherited from the parent object cannot be resolved due to Salesforce API limitations.

  Best Practices for Salesforce Exposure Policies

  Because Salesforce supports exposure filters only for files, we recommend using a two-policy approach for complete coverage:

  1. Policy for files:

     • Set the Resource Type to File/Attachment.

     • Apply your desired exposure filters (for example, Anonymous, Internal, Owner, etc.).

  2. Policy for other entities (page, comment, chat message body):

     • Set the Resource Type to Chat Message Body, Page, and Comment.

     • Do not apply exposure filters. Keep the Exposure value set to All, otherwise content may not be scanned.

  Always verify policies after creation to ensure exposure filters are applied only where supported. This prevents missed scans and ensures accurate results.

ServiceNow Alert URL Behavior for Dependency Table Violations

When a DLP violation is detected on sensitive data in a ServiceNow dependency table, the generated alert URL points to the specific table record where the data was found, rather than the parent request item.

For example, catalog variable values for Request Item (RITM) tickets are stored in dependency tables such as sc_item_option, sc_item_option_mtom, and sc_multi_row_question_answer. If sensitive data is detected in one of these tables, the alert links directly to that dependency table record instead of the parent sc_req_item.

This behavior is expected and occurs because the connector treats monitored ServiceNow tables as independent entities. It does not resolve parent-child relationships between related tables.

In contrast, Incident (incident) records store data directly within the main table, so alert URLs point to the incident record itself.

This behavior is by design and is not a product defect.

Policy Action Special Behavior