Reviewing Controls You Already Bought
The six questions to ask about a control you inherited, why most of them are running for situations that ended, and what to do with the data already collected.
Four inherited controls, reviewed at one employer after six years
Three of the four were running for a situation that had ended, and one of them for a team that no longer exists. This is one employer's own review, not a benchmark.
Most controls are inherited rather than chosen, and nobody revisits them. A system installed for a specific concern in 2021 is still collecting in 2026, about a team that has changed, for a problem that was resolved, and the only person who knew why has left.
The control described in “Reviewing Controls You Already Bought” should be matched by transparent operating rules. Organisations considering see the product in context for attendance point system can make that use more credible by publishing the purpose, selecting only necessary settings, limiting manager access and fixing a review date before the first record is collected.
Reviewing them takes an afternoon a year and reliably finds at least one that is collecting data about everybody for no current reason.
Teams reviewing “Reviewing Controls You Already Bought” can cross-check their approach against the Atlassian Trust Center. The comparison is most useful when the organisation records which recommendations apply, which do not and why.
The six questions
- What problem was this introduced for, and does it still exist?
- What does it collect, exactly, including incidentally?
- Who reviews what it produces, how often, and against what criterion?
- What has it found in the last twelve months?
- What would we lose if it were switched off tomorrow?
- Were people told what it collects, and is that still accurate?
The fourth is the one that settles most of them. A control that has found nothing in a year is either deterring effectively or doing nothing, and the distinction is usually answerable from the other five.
The control running for a situation that ended
The commonest finding. A monitoring agent deployed during a specific concern, a geofence for a field team that was disbanded, photo capture introduced after an incident in a department that has since been restructured.
Each continues because switching something off requires a decision and leaving it on does not.
The data already collected
Switching off a control raises a second question: what happens to what it gathered.
Retaining four years of unreviewed images or activity logs after the control is retired is the worst available position — all of the obligation, none of the purpose. Deciding the disposal is part of retiring it, and what is permitted differs by jurisdiction and is a question for somebody qualified in the place concerned.
Deterrence, honestly assessed
The usual defence of a control that has found nothing is that it deters. Sometimes true, and it decays: a control that nobody has ever seen act is discounted within a year or two.
The honest test is whether anybody could name a consequence that followed from it. If nobody can, the deterrent is doing less than claimed.
The review that produces a decision
Keep, change, or retire. Writing the answer down, with a date and a name, is what makes it a review rather than a discussion.
Changing is the most common outcome and the most useful: narrowing scope, shortening retention, moving from continuous to triggered, or restricting who can see the output. Those are small edits that materially change what the control is.
Telling people about a change
A control that is narrowed or retired is worth saying so, for the same reason the original notice mattered.
It is also one of the few pieces of unambiguously good news available in this area, and organisations routinely do it silently, which wastes it.
Finding what is running
The review assumes a list, and most organisations do not have one. Building it is the first pass and it is genuinely surprising: agents installed by a predecessor, a trial that was never ended, a module switched on during an implementation.
- Ask IT what agents are deployed to endpoints, and when each was added.
- Ask finance what is being paid for, by line, on the software budget.
- Ask each site what is installed on its terminals and doors.
- Check the time and payroll systems for modules that are licensed and enabled.
Four questions to four people. The list that comes back is reliably longer than anybody expected and it is the agenda for everything else on this page.
The owner problem
Each control needs an owner who is accountable for the six questions, and the honest answer is frequently that it has none: it was procured by somebody who has left, administered by IT and relied on by HR.
Naming an owner is what makes the annual review happen. Without one the review is everybody's good intention, which is the state that allowed the control to run unexamined for six years in the first place.
Putting it in the calendar
Annual, with the inventory described elsewhere here as the agenda. Each control, the six questions, the decision, the date.
An afternoon. It is the cheapest item in this entire collection and it addresses the thing most likely to cause trouble — a system nobody chose, collecting about everybody, for a reason nobody remembers, reviewed by nobody.