---
id: KB-TZ-016
url: https://app.codecontract.io/help/traceability-and-compliance/who-authorised-this-exception
idioma: en
categoria: trazabilidad
audiencia: usuario
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-TZ-001, KB-IC-014]
citadoPor: [KB-TZ-019, KB-TZ-020]
---

# Who authorised this exception

_Letting something incomplete through is a legitimate decision; being unable to say who took it is not._

**Responde a:** recording an approved exception · who authorised bypassing the procedure · justifying an off-process approval · decision traceability

No company follows its own procedure one hundred per cent of the time, and that is fine: there are emergencies, waiting customers and situations the procedure never anticipated. What separates an orderly company from an improvising one is not having no exceptions — it is knowing which there were, who authorised them and why.

## The most repeated exceptions

| Situation | What is bypassed | What must be written down |
| --- | --- | --- |
| A supplier comes in with incomplete documentation | The requirement to be current | What is missing, until when, and who accepts it |
| Something is signed without the usual review | The approval step | Who decided and with what information in front of them |
| Out-of-spec material is accepted | The quality criterion | Who accepts it and for what specific use |
| Payment goes out without a matched delivery note | The prior reconciliation | Who authorises and what will be done afterwards |

> [!IMPORTANT]
> In all four, what gets asked for later is **never the missing document**: it is who decided to proceed without it. An exception with a name, a date and a reason is a management decision; the same exception without them is a breach, even if the outcome was identical.

## How to record it without building a new procedure

1. **In the same file where it happens** — Not in a separate exceptions register nobody maintains.
2. **With who authorises, not "it was authorised"** — A name. It is the difference between a decision and a fait accompli.
3. **With the condition and the deadline** — "Comes in today, supplies insurance by Friday" is an exception; "comes in" is a hole.
4. **And with the closure** — If the condition was met, note it; if not, that is information too.

> [!WARNING]
> The fourth point is barely ever done and it changes the meaning of everything above. An exception opened and never closed stops being an exception: it becomes the new way of working without anyone deciding it. If a review shows many open, the problem is no longer the exceptions — it is that the procedure asks for something operations cannot deliver.

## What it is for later

**En corto**

- In an audit: showing controlled exceptions beats pretending there are none.
- In a claim: it places who decided what, and on what information.
- And internally: if they rise month on month, it is the earliest sign something does not fit.

The last is the most useful and the least examined. Exceptions move before the compliance percentage does, because they signal real friction while the numbers still look fine.

> [!NOTE]
> None of this needs a form: it is enough that the decision is written where it happens, with who and why. A separate exceptions register survives three months; a note in the file survives as long as the file.

**Does having recorded exceptions look bad?**

Far worse is not having them recorded and having them surface on their own.

**Who should be able to authorise them?**

Whoever answers for that area. If anyone can, it is not an exception: it is the real process.

**What about genuine emergencies?**

Authorise them the same way, and note it the same day. What does not work is never noting it.

## Ejemplos

**A company lets a subcontractor on site without current insurance because of an urgency.**

- Records who authorises it, what is missing and until when
- Closes the exception when the policy arrives

→ The audit sees a controlled decision instead of an unexplained access.

**An exception is made and nobody knows who authorised it.**

- Records who authorised and when

→ The authorisation has a name and a date.

**The exception is requested by phone.**

- Asks for the authorisation in writing

→ The exceptional stops depending on two memories.

**The exception repeats and nobody notices.**

- Checks how many times it has been authorised

→ The exception stops becoming the rule unnoticed.

**Authorisation is given without recording the reason.**

- Records the reason alongside the authorisation

→ Months later it is understood why.

**A review asks about an old exception.**

- Checks the authorisation log

→ You answer from the record.