New features: Deferred Policy Action in Netskope One CASB API gives employees a set number of days to fix a data violation before the policy acts, and Automated Incident Remediation Tracking marks the incident Auto Resolved once the file stops matching.
An enterprise security lead I spoke with recently had more than 300 open incidents in her cloud access security broker (CASB) API queue and no way to tell how many were already fixed. Employees had received violation emails, but the console was still showing every incident as new and they all required an analyst to open the file, check it themselves, and manually close the ticket if resolved. Her team’s workaround was a shared spreadsheet where analysts were supposed to log the date they checked each file and record what they found. And it had (sort of) been working… until some changes in her staff and an increase in volume turned it into one more thing noone had time to maintain. Hence the 300 open incidents.
Her problem sits at both ends of the remediation process, and I hear a version of it in nearly every conversation with security teams. At the start, a policy has to decide how hard to push: alert and hope the file owner acts, or simply automatically restrict access right away and risk interrupting live work. At the other end of that process, when heavy-handed blocking is avoided, nothing automatically confirms whether the owner acted, so manual checks are required. In this position, teams can generally report how many violation emails went out, but not how many exposures were fixed, which (let’s be honest) is the number everyone asks for at audit time. I’d argue that a process with no deadline at the start and no verification at the end is not actually a remediation process: it’s basically just a notification process.
Let’s throw in some numbers. At 15 minutes per incident, a queue of 300 would take about 75 hours to review, close to two working weeks for one analyst. I am yet to meet the team with two weeks to spare for work that produces no new findings.
Alerts and immediate action both fall short at the start
Until now, Netskope One CASB API policies offered two types of response: an alert, or an immediate restrictive action such as revoking access or quarantining a file. Alerts alone rely on the employee acting. If they don’t, sensitive files can stay shared with external parties for weeks after the owner was notified, with no record that the email was even opened. Immediate action closes the exposure but ignores context. Restricting access the moment a violation is found interrupts legitimate, in-progress work, and the disruption is usually felt before the explanation reaches anyone.
The admins I talk to want something closer to how a reasonable person would handle it, tell the owner what’s wrong, give them a few days, and step in only if nothing changes. People who lose access without warning look for workarounds, while people who get a clear explanation and enough time are more likely to fix the problem themselves, which is often faster and less contentious than having security do it for them.
How Deferred Policy Action works in Netskope One CASB API
Deferred Policy Action alerts the employee first, then takes the restrictive action only if the violation is still there after a set number of days. In the API Data Protection policy editor, administrators select Set Time Trigger under Profile & Action, which splits the policy response into two stages.
When a file first matches the policy, CASB API takes the Alert action and sends the configured notification. Administrators choose the recipients (the file owner, collaborators, admins) and the email template, which tells the recipient what was found and what needs to change. They also set how many days the owner has to fix the problem. If the file still matches the policy when that window ends, CASB API automatically takes the follow-up action defined in the policy (such as revoking access from specific users). Files fixed in time see no further action.
How Automated Incident Remediation Tracking resolves incidents
At the other end of the process, Automated Incident Remediation Tracking in Netskope One CASB API keeps watch over files that triggered an incident. When an employee removes a public link or cleans out the sensitive data, CASB API detects the change and sets the incident status to Auto Resolved.
This is a significant operational improvement for teams who want to avoid manual checks but for whom automations that close incidents after a certain time has passed (regardless of resolution status) do not contain enough rigor.
Note: Before you turn it on, check your custom incident statuses. We reserve Auto Resolved for this feature, so if you already created a status with that name, rename it first.
What changes for your team
Your team’s queue is about to get shorter and easier to trust. Incidents that are fixed by employees move automatically to Auto Resolved, so the ones still open are those where the exposure remains, giving analysts a much clearer view of where to spend their time.
Reporting improves too. A count of violation emails shows how many people were told about a problem, while a count of Auto Resolved incidents shows how many exposures the file owners fixed themselves. For organizations extending responsibility for defense down to business teams, that figure shows whether the training is working.
Choosing which policies get a timer
Deferred Policy Action suits situations where the owner can plausibly act as part of the fix. When data is sensitive enough that exposure can’t wait, immediate action is still the right call, and many admins use the time trigger for external collaboration policies while keeping immediate action for their highest-sensitivity classification tiers.
Ask these three questions to help determine policy:
- Can the file owner fix the problem without help from security? A person can often remove an external share alone, so sharing policies suit a timer.
- Can the organization tolerate a few days of exposure for this type of data? If not, use immediate action.
- Are people working in the file every day? Files in active use cost more when access disappears early, so they benefit more from a grace period.
How long to defer a policy action? In our own internal trials we have determined that seven days is a reasonable starting point for external collaboration policies, though the right number depends on how your teams work and how much risk your organization accepts. Because the first stage is an alert, the notification does most of the persuading. Write the email template so it is clear what was found, what needs to be changed, and how long the owner has to change it.
Set up a demo or discussion with our team and we’ll show you how Deferred Policy Action and Automated Incident Remediation Tracking work together.
