Skip to main content
TENSOR docs
Explanation

Why regulatory toggles are sticky

The reasoning behind forward-only enablement and dual-approval to switch a regulatory toggle off.

Administrators expect feature toggles to flip freely. TENSOR regulatory toggles do not, and the difference surprises people. This page explains why -- it is the why behind the steps in the compliance how-to guides.

The short version

A regulatory toggle has two behaviours that an ordinary feature switch does not:

  1. Forward-only. Turning it on never reclassifies past data. You start producing regulated artifacts from the moment of enablement, not retroactively.
  2. Sticky-off. Once the toggle has produced its first regulated artifact, you cannot quietly switch it off. Disabling it requires a dual-approval request.

Why sticky-off exists

Regulations like DORA, NIS-2, MaRisk, and BAIT attach retention, audit, and reporting obligations to artifacts once they exist. If a tenant could silently disable a toggle after producing those artifacts, it could escape obligations the regulator still expects it to meet. Sticky-off encodes that: the obligation outlives the toggle.

Each toggle names the exact event that makes it sticky -- see the Becomes sticky when column in the toggle catalog. Most are an artifact being produced (a report generated, an incident classified). One, marisk_audit_retention_extended, becomes sticky on activation alone, because turning it on itself changes the retention rules.

What this means in practice

  • Decide deliberately before enabling. Use a non-production tenant to explore if you are unsure.
  • To switch a sticky toggle off, raise the dual-approval request from the same settings screen; a second authorized approver must clear it.
  • Enabling toggles in bulk via a signup bundle is additive -- applying a bundle never switches another bundle's toggles off.