Most of the conversation around SYSC 10A record-keeping assumes the system worked: the call was captured, filed, retained, and can be produced. Far less gets said about the times it doesn't work — a mobile call that drops before the recorder engages, an extension moved onto a new desk without being added to the capture policy, a storage fault that silently loses an hour of a busy morning. Every recording system has a failure rate above zero. The obligation to keep the record doesn't go away because the reason it wasn't kept was technical rather than deliberate.
The rule expects relevant conversations and communications to be recorded and retained, and even its own narrow allowance for genuine technical failure doesn't let a firm off the hook quietly: SYSC 10A.1.15R requires a firm that's unable to record for exceptional circumstances to document what happened and retain that evidence for the regulator, not simply move on. A regulator looking at a gap will generally care less about the mechanical cause and much more about two other things: whether the firm already knew about it, and what happened after it was found. A firm that can point to a logged, investigated, and remediated gap is in a materially different position from one that discovers the same missing call for the first time when asked to produce it.
An incident is not the same thing as an absence
Two failure modes tend to get treated as interchangeable when they aren't. An incident is a gap the firm already knows about — surfaced by a reconciliation check, a support ticket, an engineer noticing an empty slot in the index — with a timestamp, a cause, and a remediation attached to it. An absence is a gap nobody has gone looking for yet, sitting quietly in the record until a specific request eventually goes hunting for a call that isn't there. The underlying technology can be identical in both cases. The compliance posture is not. One is a control catching its own failure and doing something about it. The other is no control at all, indistinguishable from a working one right up until it's tested.
Building for the failure, not just the success path
In practice that means treating capture the way any system with a non-trivial failure rate should be treated: reconciled on a schedule, not assumed correct because the dashboard is green. A dialler log or calendar system that shows a call took place is a natural, independent source to check the recording archive against — anything that appears in one and not the other is a gap, and the sooner that comparison runs, the more options remain, from a prompt note in the client file to, occasionally, a voluntary follow-up while the conversation is still recent enough to matter.
The remediation record carries as much weight as the detection itself. What was missing, how it surfaced, what caused it, and what changed so it doesn't recur — that's a short internal note, not a project, and it's the piece that turns "our system failed once" into an answer a firm can actually give when asked. Silence about a known gap tends to be judged far more harshly than the gap itself; it reads as a firm that chose not to look, which is a different and worse finding than a firm that looked and found something to fix.
None of this is really a story about outages. It's the same structural principle the rest of the record-keeping obligation rests on: a control that can demonstrate it works — including the specific, slightly uncomfortable proof of having once caught its own failure — is worth more than one that has simply never yet been tested. That's the standard the compliance tooling built under this roof is held to as well: not zero failures, which no honest capture system promises, but no undetected ones.