Next Generation API Data Protection Retroactive Scan

A retroactive policy scans all the files, folders, repositories, and entities for the app instance right from the inception of the SaaS app. A retroactive scan is decoupled from ongoing policy scan (a.k.a activity scan).

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

If you have newly on-boarded the SaaS app instance, Netskope takes a while to scan and calculate the exposure of the SaaS app depending on how large is the data set. Netskope recommends to initiate a retroactive scan only when the initial exposure calculation is complete.

While ongoing policy processing evaluates content as it changes to ensure compliance of these (both data and metadata) changes versus set policies, retroactive scan fulfills the need to re-evaluate all or a portion of the content in the protected cloud application in case of more structural changes. Some example of the changes that would trigger the need for a retroactive scan are as follows:

Create a SaaS app instance on the Netskope UI for the first time to ensure pre-existing violations are detected and remediated.

Netskope’s implementation of retroactive scan allows you to scan content only on `already discovered content`. The implication is that for the first retroactive scan when Netskope is deployed for the first time, or a new data set inherited by the customer – e.g. post organization merger, customers should take a two-step approach: firstly, complete listing of the full repository and only once this is complete, start a retroactive scan.
Merger or acquisition of a new company. Similar to the previous case, a retroactive scan ensures that new content that the acquiring company is inheriting as a result of the merger is compliant to company regulatory requirements.
Changes in internal and external regulations requiring policy changes. A retroactive scan can be used to ensure compliance of content already in the protected apps against new policies.
Threat intelligence updates. As new malware is discovered, and Netskopes’ threat intelligence database expands, customers would like to periodically re-evaluate content in the protected apps to ensure there is no malicious content.
Breach response. This is the most common scenario for a retroactive scan. Anytime there is a breach alert or a breach that has happened, customers have the judiciary duty to evaluate if sensitive data was compromised and if so notify the impacted parties the extent of the compromise. As customers may not normally detect sensitive data in private (or in some cases internally shared content), this changes in case of breach as any file in the repository could have been exposed as a result of that breach. A retroactive scan can help run this evaluation.

To access the retroactive scan page, log in to your Netskope tenant, navigate to Policies > API Data Protection > Next Gen and click Retroactive Scans. The page displays a list of retroactive scans, status of the scan, policy hit and files scanned count, start/end time, and a list of policies per retroactive scan.

Configure a Retroactive Scan

To initiate a new retroactive scan:

You can have up to two active retroactive scans (either In Progress or Paused) for a single SaaS app instance at any given time—but only one of them can be running.
– You won’t be able to start a second retroactive scan until one of the existing scans is completed.
– You also can’t resume a Paused scan if another scan is already In Progress.
Scans that are canceled, completed, or not yet started do not count toward this limit. This limitation applies at a per app instance level, not per tenant or per SaaS app. If you attempt to start a second retroactive scan, the UI will display an error message.

Log in to your Netskope tenant.
Navigate to Policies > API Data Protection > Next Gen.

You can click the ellipses (…) > Email Retroscan Usage to configure daily, weekly, or monthly usage alert emails to stay informed of your retroactive scan data consumption. To learn more: Weekly Email Notifications and Threshold Configuration.
This is an opt-in feature. To enable this on your tenant, talk to your Netskope sales representative.
Click New Retroactive Scan.

The New Retroactive Scan window opens.
Enter the name of the retroactive scan.
Under Object, select the SaaS app instance for which you intend to run the retroactive scan.

You can select one app instance only.
Under Scan Scope, you can set a time range filter that can help reduce the scan duration. Select one of the following options:

Scan scope settings configured via the REST API may include advanced options not supported in the UI. As a result, the settings displayed here may be inaccurate or incomplete. Following settings can be configured via REST API v2 only:
– The custom date range option in the REST API supports time granularity down to the second, whereas the UI only supports day-level granularity.
– For scan speed settings, the REST API allows throttling between 1% and 100%, while the UI only offers preset options of 100%, 75%, 50%, and 25%.
- Select your local time zone – This will be applied to all time range-related settings and advanced scan preferences. By default, the the time zone picker selects the browser’s time zone.
  
  In some cases, your exact regional time zone may not appear in the list. If that happens, simply select a time zone with the same UTC offset as your local time. This will ensure accurate time display and functionality.
  
  Backward compatibility:
  
  For retroactive scans created prior to the introduction of the time zone picker:
  - The time zone picker will be left unset.
  - Date filters (before/after/custom range) will continue to display in the user’s browser time zone.
  - Relative date filters (last x/30/60/90 days, last month) and running hours will continue to display in UTC+0.
  If a user updates the time zone picker, it is treated as an intent to transition all time-based configurations—including filters and running hours to the newly selected time zone.
  
  Time calculations are based on the standard time offset of the selected time zone. Daylight Saving Time (DST) is not accounted for.
- Scan all files – This is the default setting. This option scans all files in your SaaS app.
- Only scan files created or modified – This option scans files created or modified in the last x^*/30/60/90 days, last month, before or after a specific date, or custom date range.
  
  ^*x could be 1-999 days for all SaaS apps except Google Calendar and Cisco Webex. For Google Calendar, it is 1-29 days. For Cisco Webex, it is 1-90 days.
- Only scan files either created or modified after the start of the last completed retroactive scan – This option scans only those files that were created or modified after the last completed retroactive scan. If there were no historical retroactive scans, Next Generation API Data Protection scans from the beginning.
You can toggle Advanced Scan Preference. Under this option, you can define the running hours and scan speed.

Running Hours: You can now configure specific time windows during which a retroactive scan should run. This allows organizations to reduce the impact of scans on ongoing user activity during normal business hours and better align scan operations with their operational policies. Select one of the following options:
- No running hour limit (default): This is the default setting. Scans will run continuously without any day or time limit.
- Only run retroactive scans on the specific days and hours: You can select the days and time when the scan should run.
Selecting a cell schedules a scan to begin at that hour and continue for one hour.
For example, selecting the cell for Monday at 02 AM schedules a scan from 2:00 AM to 3:00 AM.
If you select Sunday at 11 PM, the scan runs from 11:00 PM to 12:00 AM Monday. Multiple consecutive cells will schedule back-to-back hourly scans.
If you do not select a time zone, all times are in the UTC+0 time zone.

Scan Speed: This option defines how fast the retroactive scan can run on your SaaS app. This helps the administrator to have control on reducing the load on SaaS app. Select one of the following options:
- Very Fast – Full Throttle (default)
- Fast – 75% Throttle
- Medium – 50% Throttle
- Low – 25% Throttle
Netskope recommends setting the scan speed value to default. Tweak the setting only if you’re running into API rate limiting issues in systems outside of Netskope—such as your own SaaS application.
Click Save.

The New Retroactive Scan Policy page opens.
Fill in the applicable details. For detailed instruction, see Create a Next Generation API Data Protection Policy.
- Exposure: Add the exposure definition and exclusion.
- Object: Enter the following details:
  - The app instance is per-selected.
  - Under Content, you can scan all content or specific resource.
  - Add related criteria.
- Profile & Action
  
  Under + Notification, there is not Last Acting User. However, there is Last Modifier. This option sends alerts to the user who most recently edited the file content. This option is available for storage SaaS apps only.
- Enter the name of the policy and click Save.
(Optional) On the Retroactive Scans page, click Add Policy to add more policies to the newly created scan.
(Optional) On the Retroactive Scans page, under the newly created scan, you can edit the existing policy.
To start the retroactive scan, click Start Scan.

If the initial inventory listing is not complete, the scan results may be inaccurate. You can check the listing status on the Inventory page before starting the scan.
(Optional) While the retroactive scan is in progress, you can pause, cancel, clone, or delete a scan.

Paused retroactive scans can remain paused for up to 120 days. After that period, the scan cannot be resumed. To proceed, you must cancel the paused scan and start a new one.
Once the retroactive scan is complete, you can view the following status:

Owner Attribute Backfill

What is Backfill?

Backfill is a data synchronization process used to update existing records in the Next Generation API Data Protection inventory following a change in system logic. In the context of SaaS applications such as Microsoft 365 OneDrive, backfill involves recalculating the ownership of existing files and folders based on the updated ownership model. When the rules governing how ownership and metadata are processed are improved, a backfill ensures that historical inventory data is recalculated and updated to reflect these new standards, maintaining consistency and accuracy across the platform.

Why is Backfill Required for Microsoft 365 OneDrive?

Next Generation API Data Protection has implemented a backfill for Microsoft 365 OneDrive to align the file and folder ownership definitions with standard SaaS industry definitions.

Old logic: The system assigned the file creator as the file owner.
New logic: The system assigns the drive owner as the owner of all files and folders within that drive, regardless of who created them.

Example Scenario

Consider drive-1, which is owned by user-1. Within this drive, there is a shared folder containing file-1, which was created by user-2.

Old logic: User-2 would be listed as the owner of file-1.
New logic: User-1 is listed as the owner of file-1, aligning with how Microsoft 365 OneDrive manages permissions and ownership at the drive level.

When is Backfill Necessary?

Backfilling is specifically required for retroactive scans. Retroactive scans reuse existing inventory data to optimize performance and reduce API call volume.

For ongoing scans, a backfill is not required because the system automatically applies the new ownership definition as it detects changes directly from the SaaS provider in real-time.

How to Configure Owner Attribute Backfill?

This backfill targets all Microsoft 365 OneDrive SaaS app instances that were created before the new ownership logic was deployed. When you navigate to the Retroactive Scan policy page, a dedicated UI pop-up message is displayed, prompting you to initiate the owner attribute backfill. This allows you to start the backfill asynchronously at a time of your choosing and monitor its progress directly from the UI.

The Merits of Backfilling

Executing a backfill ensures the integrity of your security policies. If your retroactive scan policies include owner-based criteria or exposure criteria influenced by ownership, the backfill ensures that policy matching remains accurate. Without it, policies may fail to trigger or may produce false positives based on outdated ownership data.

Processing Time & Guidelines

The duration of a backfill depends on several factors:

Shared API quota: Backfill relies on API calls to fetch updated metadata. It must compete for the same shared API quota used by ongoing activities and other running retroactive scans.
System activity: High levels of concurrent scanning activity can slow down the backfill velocity.
Data volume: The total number of files in the inventory is the primary factor in determining the overall completion time.

As a general guideline, consider the backfill as a subset of the initial provisioning process in terms of resource requirements and time expectations.

Weekly Email Notifications and Threshold Configuration

You can configure daily, weekly, or monthly usage alert emails to stay informed of your retroactive scan data consumption. These alerts help you proactively manage quotas—similar to storage notifications on platforms like Google Drive or iCloud. Salient features are as follows:

Set a custom threshold (e.g., 100 GB a day/week/month).
Emails are triggered only if your weekly usage exceeds this limit.
Customize the name of the report, recipients, frequency, and the delivery time.

To configure the email notification, navigate to Policies > API Data Protection > NEXT GEN > RETROACTIVE SCANS, click the ellipses (…) > Email Retroscan Usage.

Retroactive Scan Actions

Important points to note on retroactive scan actions and states:

You can edit a retroactive scan or policy as long as the retroactive scan has not started yet.
In the scan/pause/complete/canceled state, you can only view, clone, or delete the retroactive scan or policy, i.e. you cannot edit a retroactive scan once it’s started.
Netskope allows only one active retroactive scan per app-instance. If a tenant has multiple app-instances connected, Netskope allows each app-instance to have an active retroactive scan.

Status vs Action Matrix

This table lists the available actions against a retroactive scan status.

Important Points to Note

Here is a list of important points to note w.r.t retroactive scan:

You can have up to two active retroactive scans (either In Progress or Paused) for a single SaaS app instance at any given time—but only one of them can be running.
- You won’t be able to start a second retroactive scan until one of the existing scans is completed.
- You also can’t resume a Paused scan if another scan is already In Progress.
Scans that are canceled, completed, or not yet started do not count toward this limit. This limitation applies at a per app instance level, not per tenant or per SaaS app. If you attempt to start a second retroactive scan, the UI will display an error message.
Paused retroactive scans can remain paused for up to 120 days. After that period, the scan cannot be resumed. To proceed, you must cancel the paused scan and start a new one.
You can bind a retroactive scan to a single instance and same for all its policies. You cannot change this after creation. You should create a new retroactive scan with new policies.
A retroactive scan can support multiple policies, and a policy can support multiple profiles.
Netskope supports multiple retroactive scans running across instances. However, only one active scan per instance.
The retroactive scan policy editor has the same look and feel as the ongoing/active policy editor.
Retroactive scan policies are disjoint from ongoing/active policies. That means you cannot use an existing ongoing/active policy for a retroactive scan and vice-versa. In addition, when you create a new retroactive scan policy, the policy does not list under ongoing/active policy page and vice-versa.

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

Create a SaaS app instance on the Netskope UI for the first time to ensure pre-existing violations are detected and remediated.

Netskope’s implementation of retroactive scan allows you to scan content only on `already discovered content`. The implication is that for the first retroactive scan when Netskope is deployed for the first time, or a new data set inherited by the customer – e.g. post organization merger, customers should take a two-step approach: firstly, complete listing of the full repository and only once this is complete, start a retroactive scan.
Merger or acquisition of a new company. Similar to the previous case, a retroactive scan ensures that new content that the acquiring company is inheriting as a result of the merger is compliant to company regulatory requirements.
Changes in internal and external regulations requiring policy changes. A retroactive scan can be used to ensure compliance of content already in the protected apps against new policies.
Threat intelligence updates. As new malware is discovered, and Netskopes’ threat intelligence database expands, customers would like to periodically re-evaluate content in the protected apps to ensure there is no malicious content.
Breach response. This is the most common scenario for a retroactive scan. Anytime there is a breach alert or a breach that has happened, customers have the judiciary duty to evaluate if sensitive data was compromised and if so notify the impacted parties the extent of the compromise. As customers may not normally detect sensitive data in private (or in some cases internally shared content), this changes in case of breach as any file in the repository could have been exposed as a result of that breach. A retroactive scan can help run this evaluation.

Configure a Retroactive Scan

To initiate a new retroactive scan:

Log in to your Netskope tenant.
Navigate to Policies > API Data Protection > Next Gen.

You can click the ellipses (…) > Email Retroscan Usage to configure daily, weekly, or monthly usage alert emails to stay informed of your retroactive scan data consumption. To learn more: Weekly Email Notifications and Threshold Configuration.
This is an opt-in feature. To enable this on your tenant, talk to your Netskope sales representative.
Click New Retroactive Scan.

The New Retroactive Scan window opens.
Enter the name of the retroactive scan.
Under Object, select the SaaS app instance for which you intend to run the retroactive scan.

You can select one app instance only.
Under Scan Scope, you can set a time range filter that can help reduce the scan duration. Select one of the following options:

Scan scope settings configured via the REST API may include advanced options not supported in the UI. As a result, the settings displayed here may be inaccurate or incomplete. Following settings can be configured via REST API v2 only:
– The custom date range option in the REST API supports time granularity down to the second, whereas the UI only supports day-level granularity.
– For scan speed settings, the REST API allows throttling between 1% and 100%, while the UI only offers preset options of 100%, 75%, 50%, and 25%.
- Select your local time zone – This will be applied to all time range-related settings and advanced scan preferences. By default, the the time zone picker selects the browser’s time zone.
  
  In some cases, your exact regional time zone may not appear in the list. If that happens, simply select a time zone with the same UTC offset as your local time. This will ensure accurate time display and functionality.
  
  Backward compatibility:
  
  For retroactive scans created prior to the introduction of the time zone picker:
  - The time zone picker will be left unset.
  - Date filters (before/after/custom range) will continue to display in the user’s browser time zone.
  - Relative date filters (last x/30/60/90 days, last month) and running hours will continue to display in UTC+0.
  If a user updates the time zone picker, it is treated as an intent to transition all time-based configurations—including filters and running hours to the newly selected time zone.
  
  Time calculations are based on the standard time offset of the selected time zone. Daylight Saving Time (DST) is not accounted for.
- Scan all files – This is the default setting. This option scans all files in your SaaS app.
- Only scan files created or modified – This option scans files created or modified in the last x^*/30/60/90 days, last month, before or after a specific date, or custom date range.
  
  ^*x could be 1-999 days for all SaaS apps except Google Calendar and Cisco Webex. For Google Calendar, it is 1-29 days. For Cisco Webex, it is 1-90 days.
- Only scan files either created or modified after the start of the last completed retroactive scan – This option scans only those files that were created or modified after the last completed retroactive scan. If there were no historical retroactive scans, Next Generation API Data Protection scans from the beginning.
You can toggle Advanced Scan Preference. Under this option, you can define the running hours and scan speed.

Running Hours: You can now configure specific time windows during which a retroactive scan should run. This allows organizations to reduce the impact of scans on ongoing user activity during normal business hours and better align scan operations with their operational policies. Select one of the following options:
- No running hour limit (default): This is the default setting. Scans will run continuously without any day or time limit.
- Only run retroactive scans on the specific days and hours: You can select the days and time when the scan should run.
Selecting a cell schedules a scan to begin at that hour and continue for one hour.
For example, selecting the cell for Monday at 02 AM schedules a scan from 2:00 AM to 3:00 AM.
If you select Sunday at 11 PM, the scan runs from 11:00 PM to 12:00 AM Monday. Multiple consecutive cells will schedule back-to-back hourly scans.
If you do not select a time zone, all times are in the UTC+0 time zone.

Scan Speed: This option defines how fast the retroactive scan can run on your SaaS app. This helps the administrator to have control on reducing the load on SaaS app. Select one of the following options:
- Very Fast – Full Throttle (default)
- Fast – 75% Throttle
- Medium – 50% Throttle
- Low – 25% Throttle
Netskope recommends setting the scan speed value to default. Tweak the setting only if you’re running into API rate limiting issues in systems outside of Netskope—such as your own SaaS application.
Click Save.

The New Retroactive Scan Policy page opens.
Fill in the applicable details. For detailed instruction, see Create a Next Generation API Data Protection Policy.
- Exposure: Add the exposure definition and exclusion.
- Object: Enter the following details:
  - The app instance is per-selected.
  - Under Content, you can scan all content or specific resource.
  - Add related criteria.
- Profile & Action
  
  Under + Notification, there is not Last Acting User. However, there is Last Modifier. This option sends alerts to the user who most recently edited the file content. This option is available for storage SaaS apps only.
- Enter the name of the policy and click Save.
(Optional) On the Retroactive Scans page, click Add Policy to add more policies to the newly created scan.
(Optional) On the Retroactive Scans page, under the newly created scan, you can edit the existing policy.
To start the retroactive scan, click Start Scan.

If the initial inventory listing is not complete, the scan results may be inaccurate. You can check the listing status on the Inventory page before starting the scan.
(Optional) While the retroactive scan is in progress, you can pause, cancel, clone, or delete a scan.

Paused retroactive scans can remain paused for up to 120 days. After that period, the scan cannot be resumed. To proceed, you must cancel the paused scan and start a new one.
Once the retroactive scan is complete, you can view the following status:

Owner Attribute Backfill

What is Backfill?

Why is Backfill Required for Microsoft 365 OneDrive?

Next Generation API Data Protection has implemented a backfill for Microsoft 365 OneDrive to align the file and folder ownership definitions with standard SaaS industry definitions.

Old logic: The system assigned the file creator as the file owner.
New logic: The system assigns the drive owner as the owner of all files and folders within that drive, regardless of who created them.

Example Scenario

Consider drive-1, which is owned by user-1. Within this drive, there is a shared folder containing file-1, which was created by user-2.

Old logic: User-2 would be listed as the owner of file-1.
New logic: User-1 is listed as the owner of file-1, aligning with how Microsoft 365 OneDrive manages permissions and ownership at the drive level.

When is Backfill Necessary?

Backfilling is specifically required for retroactive scans. Retroactive scans reuse existing inventory data to optimize performance and reduce API call volume.

For ongoing scans, a backfill is not required because the system automatically applies the new ownership definition as it detects changes directly from the SaaS provider in real-time.

How to Configure Owner Attribute Backfill?

The Merits of Backfilling

Processing Time & Guidelines

The duration of a backfill depends on several factors:

Shared API quota: Backfill relies on API calls to fetch updated metadata. It must compete for the same shared API quota used by ongoing activities and other running retroactive scans.
System activity: High levels of concurrent scanning activity can slow down the backfill velocity.
Data volume: The total number of files in the inventory is the primary factor in determining the overall completion time.

As a general guideline, consider the backfill as a subset of the initial provisioning process in terms of resource requirements and time expectations.

Weekly Email Notifications and Threshold Configuration

Set a custom threshold (e.g., 100 GB a day/week/month).
Emails are triggered only if your weekly usage exceeds this limit.
Customize the name of the report, recipients, frequency, and the delivery time.

To configure the email notification, navigate to Policies > API Data Protection > NEXT GEN > RETROACTIVE SCANS, click the ellipses (…) > Email Retroscan Usage.

Retroactive Scan Actions

Important points to note on retroactive scan actions and states:

You can edit a retroactive scan or policy as long as the retroactive scan has not started yet.
In the scan/pause/complete/canceled state, you can only view, clone, or delete the retroactive scan or policy, i.e. you cannot edit a retroactive scan once it’s started.
Netskope allows only one active retroactive scan per app-instance. If a tenant has multiple app-instances connected, Netskope allows each app-instance to have an active retroactive scan.

Status vs Action Matrix

This table lists the available actions against a retroactive scan status.

Important Points to Note

Here is a list of important points to note w.r.t retroactive scan:

You can have up to two active retroactive scans (either In Progress or Paused) for a single SaaS app instance at any given time—but only one of them can be running.
- You won’t be able to start a second retroactive scan until one of the existing scans is completed.
- You also can’t resume a Paused scan if another scan is already In Progress.
Scans that are canceled, completed, or not yet started do not count toward this limit. This limitation applies at a per app instance level, not per tenant or per SaaS app. If you attempt to start a second retroactive scan, the UI will display an error message.
Paused retroactive scans can remain paused for up to 120 days. After that period, the scan cannot be resumed. To proceed, you must cancel the paused scan and start a new one.
You can bind a retroactive scan to a single instance and same for all its policies. You cannot change this after creation. You should create a new retroactive scan with new policies.
A retroactive scan can support multiple policies, and a policy can support multiple profiles.
Netskope supports multiple retroactive scans running across instances. However, only one active scan per instance.
The retroactive scan policy editor has the same look and feel as the ongoing/active policy editor.
Retroactive scan policies are disjoint from ongoing/active policies. That means you cannot use an existing ongoing/active policy for a retroactive scan and vice-versa. In addition, when you create a new retroactive scan policy, the policy does not list under ongoing/active policy page and vice-versa.