Writing About Work You Can't Describe
If your work is covered by a confidentiality agreement, a client contract, or a security restriction, you can still put it on a resume. Describe the category rather than the instance: the type of client, the kind of problem, the scale in general terms, the skills involved. What you cannot do is invent a sanitised version that is more impressive than the real one, and you should not paste the sensitive detail into an AI drafting tool in order to get help rewriting it.
Two separate obligations are in play. One is to your former employer or client, about disclosure. The other is to the reader, about accuracy. Vagueness is acceptable; vagueness plus embellishment is not.
What is usually restricted
- Client identity. Agency and consultancy work often cannot name who the client was.
- Internal project names, which may be public-facing in ways you do not know about.
- Unreleased products and features, particularly anything cancelled.
- Figures that were never published — revenue, user counts, incident numbers, internal costs.
- Anything under a security classification, where the rules are set externally and are not negotiable.
- Details of an incident or investigation, which may be restricted for legal reasons.
If you are unsure what your agreement covers, the conservative reading is the right one. Nobody has ever been harmed by describing their work one level more generally than strictly necessary.
Substitute the category for the instance
The technique is simple and works almost everywhere. Replace the specific with the class it belongs to, and keep everything else.
Instead of naming the client: “a national retailer,” “a mid-sized insurer,” “a public-sector health body.” The reader learns the domain and the type of constraint you worked under, which is the part that transfers.
Instead of the project name: “a customer data migration,” “a regulatory reporting programme.” The name was never informative to an outsider anyway.
Instead of an unpublished figure: describe the scale in a way that is common knowledge or clearly relative. “A system used by every branch” says something without disclosing a count. What you should not do is invent a number to stand in for the one you cannot use — a substituted figure is a fabricated figure, and it is exactly the kind of claim you cannot back up.
Instead of the outcome you cannot share: describe what you built and what it was for. The artefact and its purpose are usually not the confidential part.
Say that the constraint exists
A short note prevents a reader from concluding you are being evasive, and it is often read as a positive signal about how you handle information:
Client names omitted under NDA. Happy to discuss the nature of the work in general terms.
One line, at the end of the relevant section. It also sets expectations for the interview, where the same constraint will apply and you would otherwise be declining questions without explanation.
For classified or security-restricted work, follow whatever guidance your organisation gives, and say only what you are permitted to say about the level and setting.
Do not put the sensitive material into a tool
This is the part people miss. Working around a confidentiality constraint often involves rewriting a sensitive description into a general one, and the obvious way to get help with rewriting is to paste the sensitive description into an AI assistant. That is a disclosure, to a third party, of the thing you are not allowed to disclose.
Generalise first, by hand, then get help with the wording of the already-generalised version. This is a specific instance of a broader habit: keep the detailed record private and send only extracts to any tool, which is why the facts file you assemble before drafting should never itself be pasted anywhere.
The accuracy trap
Restricted work creates an unusual temptation, because the reader cannot check any of it. If nobody can know which insurer it was or what the system did, the description could be almost anything.
Resist it for two practical reasons beyond the obvious one. First, you will be asked about the work in general terms and will have to sustain the description in conversation, from memory, under follow-up questions — and a generalised account of something real is easy to sustain while a generalised invention is not. Second, the people most likely to interview you about a restricted domain are people who have worked in it, and general claims that do not fit how that domain actually operates are noticeable.
The honest version has a specific advantage: it stays consistent every time you describe it, which is what keeping one story across every surface requires.
What survives generalisation
More than people expect. A reader of a resume is mostly extracting the type of problem you solve, the constraints you can work within, and how you go about it. Almost none of that depends on naming the client. A bullet reading “rebuilt the regulatory reporting pipeline for a mid-sized insurer, reducing a monthly manual process to a scheduled job” discloses nothing and communicates a great deal.
Where the loss is real is in outcome figures, and the answer there is to lean on responsibility and artefact instead: what you were trusted with, what you built, how long you maintained it. Those claims are often stronger anyway, and they hold up under the sceptical read every resume deserves before it goes out.