The compliance industry has a redundancy problem. CIS Benchmarks require that legacy authentication be blocked. CISA SCuBA requires that legacy authentication be blocked. DISA STIGs require that legacy authentication be blocked. Three separate frameworks, three separate control definitions, three separate audit procedures, all evaluating the exact same technical configuration. Multiply this pattern across hundreds of controls and the result is a compliance program that spends more time reconciling duplicate requirements than it does actually improving security posture.
Unified controls solve this by defining each technical requirement exactly once. A single canonical control for "Block Legacy Authentication" maps to every framework that requires it. When a scan evaluates that control, the result simultaneously satisfies CIS 1.1.1, SCuBA 2.1, and the relevant STIG finding. One evaluation, multiple framework credits. The compliance team works through a single control list instead of three overlapping ones.
The Framework Overlap Reality
The degree of overlap across major compliance frameworks is substantial. Analysis of the major M365 security frameworks reveals that the average technical control satisfies requirements in more than three separate framework sections.
This means that an organization tracking compliance against three frameworks is not managing three times the work. The actual unique control set is roughly one-third of the combined framework requirement count. But without unified controls, the compliance team does not know which requirements overlap. They evaluate the same configuration three times, document it three times, and report on it three times. Unified controls expose the overlap and eliminate the redundant work.
The V2 Threshold Engine
Traditional compliance evaluation is binary: a control passes or fails. But real-world configurations are rarely that simple. A password policy might require a minimum length of 14 characters. Does a policy set to 12 characters fail identically to one set to 6? Both are non-compliant, but the risk differential is enormous. The V2 threshold engine introduces nuanced evaluation with eight distinct threshold types.
The boolean type handles simple true/false checks. The compare type evaluates numeric values against minimum, maximum, or exact thresholds. The includes and excludes types check whether specific values appear or are absent from configuration sets. The count type verifies that collections contain the required number of elements. The regex type matches string patterns for complex configuration values. The composite type combines multiple sub-thresholds with AND/OR logic. The custom type supports registered evaluator functions for domain-specific logic that cannot be expressed with the standard types.
"Binary pass/fail compliance is a blunt instrument. A threshold engine that distinguishes between 'misconfigured' and 'catastrophically misconfigured' enables risk-proportional prioritization. Not all failures are created equal."
Domain Tagging and Variations
Each unified control is tagged with one or more security domains: Identity, Email Security, Data Protection, Endpoint, Network, and others. Domain tags enable dashboard views that show compliance by security area rather than by framework, which is often more actionable for engineering teams. The identity team cares about Identity domain controls regardless of which framework maps to them.
Controls also support variations. A single canonical control for "Configure Safe Links" might have variations for different policy scopes: one for the default policy, one for strict preset, and one for custom policies. Each variation can have its own threshold definition while sharing the parent control's framework mappings. This eliminates the need to create separate controls for configuration variants that serve the same security purpose.
Two-Tier Visibility
Unified controls follow the same default-plus-overlay visibility pattern used throughout TATER. Default controls (maintained by the platform) are visible to all organizations. Organization-specific controls are visible only to the organization that created them. This allows MSPs to maintain a standard baseline of controls that apply to all clients while permitting individual organizations to add controls that reflect their unique regulatory requirements. SuperAdmins edit the defaults; OrgAdmins create org-specific overlays.
How TATER Helps
TATER's unified controls page presents the complete control inventory with domain chips, framework mappings, and threshold definitions. The V2 threshold engine evaluates scan data against each control's threshold configuration, producing granular pass/fail results with evidence data. Multi-framework mappings mean that each scan simultaneously advances compliance against every framework that references evaluated controls. Domain filters, search, and bulk operations streamline control management. The two-tier visibility model ensures that platform defaults and organizational customizations coexist without conflict.
