A retroactive scan is a manually triggered scan of part or all of an instance’s existing inventory. Each entity in the retroactive scan goes through a similar flow for ongoing scans with the key difference that the policies used in a retroactive scan are defined within the retroactive scan. Existing ongoing policies are not used.
Difference between Classic and Next-Generation Retroactive Scan
Retroactive scans that depend on exposure must wait until provisioning/listing is complete for all content collection, content, and permissions related to content collection and content.
Next Generation scan prioritizes:
-
Ongoing scans.
-
Listing users, groups, content, and content collections.
-
Permission listing.
Classic retroactive scan prioritizes:
-
Listing users, groups, content, and content collections with permissions.
-
Ongoing scans.
Policies
The policy specifications vary between Classic and Next Generation API Data Protection systems.
-
In Classic, retroactive scans operate based on existing, ongoing policies. Once initiated, the policies selected for a retroactive scan become locked.
-
Conversely, in Next Generation, specific policies must be created explicitly for retroactive scans. These retroactive scan policies have no impact on ongoing scans; they are solely utilized for retroactive purposes.
The separation of policies enables users to freely adjust ongoing policies without concerns about locking.
Moreover, the policies configured for retroactive scans utilize the same policy creation page as ongoing policies. Users can configure exact duplicates of ongoing policies for retroactive scan purposes.
For a list of SaaS apps that support retroactive scans, see Next Generation API Data Protection Feature Matrix per Cloud App.