How do identity and SOC programmes both suffer from control toil?

How control toil turns identity operations and SOC work into repetitive drag

Control toil is the point where a control still exists on paper, but its operating burden starts consuming the time and attention of skilled staff. In identity programmes, that often shows up as repeated access reviews, entitlement clean-up, joiner-mover-leaver exceptions, and manual approvals that never seem to converge. In SOC programmes, the equivalent burden appears in endless triage, duplicate alerts, repetitive enrichment, and investigation hand-offs that delay real response. The shared problem is not just inefficiency. It is that the organisation trains experts to spend their day on low-judgement work that machines or better process design should absorb. ENISA’s ENISA Threat Landscape is useful context because it shows how crowded threat environments amplify operational load when teams cannot separate signal from routine noise.

When that load rises, the control stops behaving like a safeguard and starts behaving like a queue. Identity teams delay removals, accept exceptions, or sample reviews rather than completing them properly. SOC analysts defer enrichment, close noisy alerts too quickly, or spend their time revalidating obvious cases. In both cases, the organisation can end up with slower decisions and weaker assurance even though activity levels look high. In practice, many security teams discover control toil only after exceptions, backlogs, and overdue work have already become accepted as normal.

Why the same failure pattern appears in access reviews and alert triage

Identity and SOC programmes suffer from control toil for the same structural reason: they both depend on repeatable decisions that are easy to describe but expensive to perform at scale. A review, an approval, a triage step, or an investigation note may be individually simple, but the volume turns them into a capacity problem. Once staff begin handling work as a stream of interruptions, the organisation loses consistency, and the control becomes more about throughput than assurance.

• In identity, the burden accumulates around ownership, entitlement accuracy, exception handling, and timely removal of access.
• In SOC operations, the burden accumulates around alert deduplication, enrichment, escalation decisions, and case closure quality.
• In both, repetitive work creates a hidden quality risk because analysts start optimising for speed instead of fidelity.

The practical failure is not simply that people are busy. It is that the work is structured in a way that requires expert judgement for routine cases that should have been standardised. That pushes scarce staff into administrative loops while genuinely ambiguous decisions wait longer. Where identity and SOC workflows are tightly coupled, control toil can also create cross-team delay, because one queue feeds the other and each side waits on the same finite group of reviewers or responders. This guidance breaks down when the underlying process is still unstable, because automation only amplifies a broken decision model.

Where control toil shifts from annoyance to control weakness

Tighter control design often reduces short-term convenience, requiring organisations to balance assurance against operational friction. The important distinction is between necessary human judgment and routine work that merely masquerades as judgment. Where every access change needs bespoke review, or every alert needs a manual investigation path, the control is too expensive to sustain and teams begin to bypass it informally.

That is why control toil becomes a control weakness when it produces one or more of these patterns:

• backlogs that outgrow the review or investigation window
• exception lists that become a permanent operating state
• overreliance on “temporary” manual workarounds
• inconsistent decisions because reviewers lack time or context
• alert fatigue that lowers investigation quality

There is a useful governance distinction here. In identity, the risk is often stale privilege or incomplete attestation. In SOC work, the risk is missed or delayed detection because analysts are processing noise instead of meaningful signals. The control looks different, but the failure mode is similar: the organisation spends effort proving it is doing the control, while the control itself becomes less trustworthy. For practitioners, the key question is not whether the task is necessary, but whether the task still needs a human in every instance. If the answer is no, the process should be redesigned around standard paths and exception-only review.

Practitioner Guidance

What to prioritise: Identify the repetitive steps that consume expert time but rarely change the final decision. In identity, that often means routine approvals and clean-up tasks; in SOC, it is enrichment and first-pass triage. If a task is high-volume and low-variance, it is a candidate for standardisation before it is a candidate for more staffing.

Decision rule: Preserve human judgement for exceptions, disputed cases, and materially risky cases. If the same decision is being made thousands of times with little variation, the control should usually be redesigned so humans review the edge cases, not the whole queue.

What to measure: Track backlog age, exception volume, rework rate, and the share of analyst or reviewer time spent on routine handling versus exception handling. Those signals show whether the programme is protecting judgment or merely burning it.

Practitioner takeaway: The most dangerous form of control toil is not workload itself, but the gradual normalisation of backlog, exception handling, and superficial review as if they were evidence of effective control.

Related resources from NHI Mgmt Group

• How should security teams implement least privilege in SOC 2 access control programmes?
• What do identity teams get wrong when they treat SOC and SOX as the same control problem?
• How should security teams handle control deficiencies in identity governance programmes?
• Who should be accountable for control monitoring in identity programmes?