Screenshots can't be turned on without an approved DPIA - here's the actual mechanism
"Intrusive features stay off until your own DPIA is recorded" is a claim we could have left as a policy suggestion in a settings page. It isn't - it's enforced in code, at the exact moment someone tries to flip the switch.
A DPIA (Data Protection Impact Assessment) is a documented risk assessment before starting a higher-risk processing activity - required thinking for anything as intrusive as screenshot capture. Plenty of products ask you to complete one as a compliance checklist item, then let you enable the feature regardless of whether you actually did. Custelis ties the two together directly: there is no way to enable screenshots without an approved DPIA record already existing for your organization.
The actual sequence
A compliance officer records one - title, purpose, necessity, proportionality, data categories, risks, safeguards. It starts as a draft, editable while it stays a draft.
Approving requires step-up re-authentication - the same elevated confirmation legal holds and tenant suspension use. Once approved, the record is locked: you can't edit an approved DPIA after the fact, only record a new one. That's deliberate - an approved DPIA is a fixed record of what was actually assessed, not a document that can quietly drift from what a feature was approved to do.
The org-level permission toggle checks, at the moment you flip it: does an approved DPIA record exist for this organization? If not, the request is rejected with a specific error telling you to go record one - not a silent no-op, not a checkbox that just doesn't do anything.
With the org-level permission on, you can save a screenshot policy - capture rate (capped at 60/hour, enforced server-side regardless of what the client sends), interval mode, masking, retention, exclusions. That policy save goes through the same gate again: no approved DPIA, no enabled policy, even if you skip straight to this step.
Why two gates, not one
The org-level permission and the granular screenshot policy are separate on purpose. Turning the org-level permission off is always allowed - no DPIA required to reduce protection, only to increase it. That asymmetry matters: a compliance officer should never be blocked from shutting something off quickly, only from turning something more intrusive on without having actually assessed it first.
What this replaced: before this was built, the screenshot-enable toggle didn't work at all - it called a route that didn't exist, silently fell back to demo data, and showed a fake "saved" message. Nobody had ever actually enabled a screenshot policy through the product. We're mentioning that not to bury it, but because a vendor whose "DPIA-gated" claim was quietly non-functional for a while is exactly the kind of gap our own 20-point vendor checklist tells you to check for directly, not take on faith.
Related reading
See the gate itself
No credit card to start. Intrusive features stay off until your own DPIA is recorded.
Try for free