How to show confidential or NDA work in your portfolio

A lot of the best work people do never sees daylight. It sits behind a login, inside a client's internal tools, or under a non-disclosure agreement you signed on your first day. That leaves a gap in your portfolio exactly where your strongest evidence should be.

The good news is that you can almost always say something useful about confidential work without saying anything you shouldn't. This guide covers how to work out what you're allowed to share, how to anonymise a project properly, how to talk about results without revealing real figures, and what should never appear on a public page.

Start with what you actually agreed to

Before you write a word, find out what your obligations are. Confidentiality comes from a few places, and they don't all say the same thing:

• A signed NDA or confidentiality clause, either in your employment contract or in a separate agreement with a client.
• Your employer's or client's policies, such as a rule against showing internal tools or naming customers.
• Industry or legal rules that apply to certain kinds of information, such as health, financial or government data.

Read the relevant document again rather than relying on memory. Some agreements only cover specific information, like pricing or customer lists. Others restrict you from mentioning the client at all. Some expire after a set period; many don't.

If the wording is unclear, ask. This guide isn't legal advice, and when real legal risk is involved, the person to check with is your former manager, the client, or a lawyer.

When in doubt, leave it out. A slightly thinner case study costs you very little. A breach of confidence can cost you a reference, a client relationship or more.

Ask for permission, it's often easier than you think

Many people never ask whether they can show a project, assume the answer is no, and leave their best work off. A short, specific request often gets a yes, especially if you make it easy to agree.

A good request:

• Names the project and explains exactly what you'd like to show.
• Offers to remove the client name, real numbers or anything sensitive.
• Offers to send the draft for review before it goes live.
• Gives a clear, easy way to say no.

For example:

"Hi Priya, I'm putting together a portfolio and would love to include a short write-up of the onboarding redesign I worked on last year. I'd describe the problem and my process in general terms, wouldn't name the company, and would use mock screens instead of real ones. Happy to send you the draft first. Totally fine if you'd rather I didn't."

Keep the reply. If someone gives permission, save the email so you can point to it later. If they ask you to change something, change it.

How to anonymise a project properly

Anonymising is more than deleting a logo. A reader in the same industry can often work out who the client was from small details, so strip the identifying ones and keep the useful ones.

Replace the name with a description

Swap the company name for something that gives context without identifying anyone:

• "A national retail chain" instead of the brand name.
• "A mid-sized software company in the logistics space."
• "A public-sector agency" or "a regional healthcare provider."

Choose a description broad enough that several organisations could fit it. "The largest pet insurer in a small country" is technically anonymous but obviously isn't.

Remove the details that give it away

Watch for:

• Product names, internal code names and project nicknames.
• Distinctive brand colours, fonts or illustrations in screenshots.
• Exact locations, dates of launch or events covered in the news.
• Names of colleagues, customers or partners.
• Unusual features that only one company is known for.

Rebuild visuals instead of blurring them

Blurred screenshots look awkward and can sometimes be partly read. A better option is to recreate the work:

• Mock screens with neutral colours, placeholder text and fake data.
• Simplified diagrams of a process or system, drawn from scratch.
• Sketches or wireframes that show your thinking without the finished, branded product.
• A redacted structure, such as the outline of a report with section headings but no content.

Label them clearly: "Recreated for this portfolio with sample data." That honesty reassures readers and protects you.

Talk about results with relative numbers

Real figures are often the most sensitive part of a project. Revenue, user counts, budgets and conversion rates can all be confidential. You can usually still show the size of the change without the raw values.

Some safe approaches:

• Percentages and ratios instead of absolute figures: "cut processing time roughly in half."
• Ranges or rounding: "a team of around 20," "a budget in the low six figures," if even that is allowed.
• Before-and-after comparisons: "from several days to the same afternoon."
• Direction and scale without numbers: "the support team stopped needing a separate queue for this issue."

Before and after

Before:

"Increased checkout conversion from 2.31% to 3.04% for Brand X, adding $1.8M in quarterly revenue."

After:

"Redesigned the checkout flow for a national retailer, which noticeably improved conversion over the following quarter. The change was large enough that the same pattern was rolled out to two other regions."

The second version gives away no figures and no client, but the reader still understands that the work mattered. For more on presenting numbers responsibly, see quantifying your achievements.

Only use a relative number if you could honestly explain where it came from. "Roughly half" should still be true.

Describe the process, not the secrets

The part of a case study that matters most to readers is usually how you thought, not what the final product looked like. That's good news, because your thinking belongs to you in a way the deliverable may not.

Focus on:

• The kind of problem: "customers were abandoning a long application form partway through."
• What you investigated and the methods you used.
• The options you considered and why you chose one.
• The trade-offs and constraints, described generally.
• What you'd do differently next time.

Leave out:

• The client's strategy, pricing or unreleased plans.
• Specific findings from internal research or customer data.
• Code, documents or designs you don't own.
• Anything about security, infrastructure or vulnerabilities.

The structure in how to write a case study works well here. Problem, role, process and result can all be written at a level of generality that stays safe.

A short example

"I joined a project for a financial services company whose customers were calling support to ask about the status of their applications. I mapped the existing status messages, ran short interviews with support staff, and found that most calls came from two confusing stages. We rewrote those messages and added a simple progress indicator. Over the next few months, support teams reported far fewer calls about application status."

There's no client name, no screens, no internal data and no figures. Yet a hiring manager can see exactly how this person works.

What never to include

Some things don't belong on a public portfolio no matter how carefully you frame them:

• Anything you've been explicitly told not to share.
• Personal data about customers, patients, students or users.
• Passwords, keys, internal URLs or system details, even in a corner of a screenshot.
• Unreleased products, financial results or plans that haven't been announced.
• Legal, HR or disciplinary matters.
• Work that belongs to someone else, presented as if it were yours.

Our guide to personal information on your portfolio covers the personal side of this, including your own details.

Offer more in private

A public portfolio is visible to anyone. An interview is a much more controlled setting. It's common to keep the public version of a project light and offer more depth when you're speaking directly with someone.

A line like "More detail available in conversation" at the end of a case study signals that there's substance behind it. Even then, only share in private what you're allowed to share in private. Some agreements cover any third party, interviewer included. For tips on walking someone through a project, see presenting your portfolio in an interview.

When almost nothing can be shown

Occasionally you're in a role where you genuinely can't describe the work at all. In that case:

• Describe your responsibilities and skills at the level your resume already does.
• Write about your general approach to the kind of problem you solve.
• Add a personal or practice project that demonstrates the same skills.
• Lean on testimonials from colleagues, with their permission, that speak to how you work rather than what you built.

That's a perfectly reasonable portfolio. Readers in fields full of confidential work understand the situation.

Putting it together

Confidential work doesn't have to be invisible. Check what you agreed to, ask for permission when it's reasonable, and anonymise properly by removing names, distinctive details and real screens. Use relative numbers that you can stand behind, and put the emphasis on your process and decisions, which are what readers care about most. Keep the sensitive material off the page entirely, and offer more in conversation where it's appropriate.