When the Handbook Was Never Issued

A policy only helps if you can show it reached the person, and in most organisations that evidence does not exist. The handbook is on an intranet, it has been revised three times, nobody can say which version was live in March two years ago, and the only record of issue is an induction checklist that was last completed in 2019.

The workflow in “When the Handbook Was Never Issued” becomes more reliable when work records, approvals and later corrections can be distinguished. For teams exploring remote desktop monitoring software, Monitask resources for remote desktop monitoring software can provide practical context, while policy ownership, employee explanation and final decisions remain with accountable people.

That gap turns a straightforward conduct case into an argument about whether the rule applied at all. It is also one of the few gaps on this site that can be closed in an afternoon — for the future, though never for the past.

For an independent reference relevant to “When the Handbook Was Never Issued”, consult the CERT insider-risk research. Use it to test record quality, access, retention, fair process and exception handling against the organisation’s real departure workflow.

What the question actually is

Three separate things get run together: whether a policy exists, whether it was in force at the relevant time, and whether the person had it. Only the third is usually in dispute, and only the third tends to be unevidenced.

The useful test is narrow. Could you show, with a date on it, that this person was given or pointed to this document, in this version, before the thing they are said to have done? If the honest answer is no, the case does not collapse, but it rests on something else and everyone should know that before the first meeting.

What counts as evidence of issue

• A signed or electronically acknowledged receipt naming the document and its version.
• An induction record listing what was issued, dated and completed.
• A system log showing the person opened the document, with a timestamp.
• An email to the person attaching the document or linking to a stable address.
• A training record for a session that covered the rule, with an attendance list.
• A contract clause that incorporates the handbook, combined with evidence of where the handbook was.

The last one does a lot of work in practice and is the one most often missing — plenty of contracts never mention the handbook at all, which leaves the document floating free of anything the person agreed to.

Versions, and the date nobody recorded

Even where issue can be shown, the version usually cannot. Intranet pages are edited in place. A document described as "the current policy" is the current one, not the one that was current when it mattered.

Keeping dated copies of superseded versions costs nothing and is almost never done. A folder of PDFs named by date, written to once a quarter, is enough. The absence of it means that when the question is asked the organisation can describe its rules but cannot prove what they were.

The rules that do not need issuing

Not every expectation needs a written policy behind it. Some conduct is obviously unacceptable whether or not a document says so, and treating everything as though it required a written rule produces absurd results.

But the boundary is narrower than managers assume, and the further a rule is from the obvious, the more the organisation needs to show it was communicated. Rules about expenses, use of systems, outside work, social media and attendance all sit squarely in the territory where issue has to be evidenced.

Fixing it going forward

The remedy is dull and effective: reissue the handbook now, with a version number and a date, through a route that produces a record, and ask for an acknowledgement. Keep the acknowledgements somewhere that is not the intranet. Then keep every superseded version.

That protects every case from today onwards. It does nothing for a case about something that happened last year, and pretending otherwise by reissuing a document mid-process and treating it as though it had always been there is visible and damaging.

Rules that changed after the event

A policy revised between the incident and the hearing creates an obvious trap: the version read at the meeting is not the version that applied.

Pull the version in force on the relevant date and work from that, and say in the file which version was used. Where the rule has since been tightened, the person is entitled to be judged by the old one; where it has been relaxed, that is worth knowing too. The organisation that cannot tell which version applied has a problem that is separate from, and larger than, the case in front of it.

What to do about the case in front of you

Record the gap in the file before the process starts. Then take advice on what the case rests on without the document — a contractual duty, an instruction given directly, an expectation the person acknowledged in some other way, or in some situations nothing at all.

Where a policy cannot be shown to have been issued, say so in the file at the outset and describe what the concern rests on instead. A gap that was identified and reasoned about reads differently from a gap that was found by somebody else.

The organisations that come out of this well are not the ones with perfect records. They are the ones that knew what was missing before anyone asked, which is a question worth asking once, properly, rather than at the point somebody requests the file.