Here’s something nobody tells you when you start freelancing in DevOps: you are now your own security team. There’s no IT department checking your laptop, no compliance officer reminding you to rotate keys, no colleague who notices you left a client’s credentials in a shared note. If something leaks, it leaks from you, and your reputation takes the hit. The good news is that a freelancer security checklist doesn’t need to be heavy. The trick is to stop treating security as a one-off clean-up you do when a project ends, and instead slip a tiny check into each phase of how you work with a client. Below is the list I’d hand to any friend going independent, organised by project phase so you can actually use it.

Why “I’ll tidy up at the end” doesn’t work

Most freelancers I’ve talked to have a version of the same plan: do the work, then at handover, revoke access, delete local copies, hand over passwords. Sounds fine. In reality, by the time a project ends you’re already juggling the next client, the handover gets rushed, and you forget the SSH key you created in week one on a server you touched once. Months later, that key still works. Worse, problems that started early, like a secret pasted into a chat thread, have been sitting there the whole time.

So flip it around. Each phase gets its own small set of checks, done right then, while it’s fresh. Here’s how that looks.

Your freelancer security checklist, phase by phase

Phase 1: Before you sign anything

• Ask how they’ll give you access. If the answer is “we’ll email you the root password”, gently suggest something better. You’re not being difficult; you’re showing them you’re careful.
• Put responsibilities in writing. Who owns the accounts you’ll create? Who’s responsible if a third-party tool you introduce has a vulnerability? A line or two in the contract saves arguments later. If you want help wording those clauses, our post on getting contract terms right with DevOps clients walks through it.
• Clarify data handling. Will you see customer data? Production logs? Personal information? Know before you start, not when you stumble on it.
• Check your own insurance or liability position. It’s boring, but you’ll be glad you thought about it.

Phase 2: Onboarding day

• Ask for the minimum access you need for the first task. You can always request more. Starting with full admin “to save time” is how freelancers end up holding keys they never needed.
• Use your own named accounts. Never share a login with someone on the client’s team. If something goes wrong, named accounts make it clear who did what, which protects you.
• Start an access log. A simple file per client listing every account, key, token and system you’ve been given, with the date. This takes a minute and makes offboarding painless.
• Turn on multi-factor authentication everywhere it’s offered, straight away.

Phase 3: Setting up your workspace

• Separate clients on your machine. Different browser profiles, different folders, ideally different cloud CLI profiles. Mixing two clients’ credentials is an easy and embarrassing mistake.
• Keep secrets in a password manager or vault, not text files. If you’re tempted to paste a token into a notes app “just for today”, that’s the moment to stop.
• Encrypt your disk. If your laptop gets stolen from a café, encryption is the difference between an inconvenience and a disaster.
• Keep your OS and tools updated. Freelancers are attractive targets precisely because they hold access to multiple organisations.

Phase 4: Every day you write code or config

• Install a pre-commit secret scanner. It inspects every commit for strings resembling credentials and refuses it before it leaves your machine. This single habit prevents one of the most common freelancer slip-ups.
• Scan new dependencies and images when you add them. A tool like Trivy tells you within seconds if a package or container image has known problems. Much easier to swap it now than explain it later.
• Treat infrastructure code like application code. If you write Terraform or similar, run a policy scanner such as Checkov on it before you apply. Public storage buckets and open security groups are the classics it’ll catch.
• Write commit messages that explain security-relevant changes. “Restricted inbound rules to office IP range” helps the client’s team understand what you did and why.

Phase 5: When you deliver a change

• Ask for a review on anything touching access, payments or personal data. Even a quick look by someone on the client’s side catches assumptions you didn’t know you made.
• Attach evidence. A screenshot or log showing scans passed is a small thing that builds a lot of confidence. It’s part of what our guide on earning the confidence of a brand-new client calls showing your work.
• Never deploy to production with credentials you shouldn’t still have. If you were given temporary elevated access for a task, give it back when the task is done, not at the end of the contract.

Phase 6: Offboarding

• Open your access log and go line by line. Revoke, or ask the client to revoke, everything on it. Tick each item off.
• Delete local copies of client code, data exports and config files, unless the contract says otherwise.
• Hand over documentation of any secrets you created, so the client can rotate them.
• Send a short written confirmation listing what’s been revoked and deleted. It’s professional, and it protects you if questions come up later.

Notice how much lighter Phase 6 is when Phases 2 to 5 were done properly. That’s the whole point.

What if you catch a mistake mid-project?

It will happen. You’ll realise you pushed a token to a branch, or that a test bucket was public for a day. The temptation is to quietly fix it and hope nobody noticed. Don’t. Tell the client promptly, explain what happened, what you’ve already done (rotated the key, closed the bucket), and what you’ll change so it doesn’t repeat. Clients are surprisingly forgiving of honest, fast disclosure. What they don’t forgive is finding out later that you knew and stayed silent. And here’s the nice part: because you’re catching these things inside the phase where they happen, the fix is usually tiny. A key that was exposed for ten minutes is a very different conversation from one that sat in the repository for four months.

A quick story from the trenches

A friend of mine, a Kubernetes freelancer, once got a polite but tense email from a former client six months after a contract ended. Their security team had found an active access key in his name on a staging cluster. Nothing bad had happened, but they wanted to know why it still existed. He’d simply forgotten it. He had no access log, no record of what he’d been given, and spent an afternoon trying to reconstruct it from memory. These days he keeps a log for every client from day one, and says offboarding now takes him twenty minutes instead of a nervous week of second-guessing.

Making the checklist stick

A checklist only helps if you actually use it. A few tips that work for most people:

1. Copy it into a template you duplicate for each new client.
2. Automate what you can. Scanners in pre-commit hooks or in the client’s pipeline run without you remembering.
3. Review it monthly. Five minutes on the first of the month to check active access across all clients.
4. Talk about it with clients. Mentioning your security routine in proposals is a genuine differentiator. Our starter FAQ for new DevOps freelancers covers how to position yourself, and security habits deserve a line in that pitch.

Leveling up your security skills as a freelancer

Clients increasingly expect DevOps freelancers to know their way around pipeline security, not just pipeline speed. If you want to go deeper than a personal checklist, DevSecOpsSchool’s courses for working DevSecOps practitioners are worth a look. Its certifications are organised around roles; the professional-level one, for example, is about putting scanning, secret detection and compliance checks right into CI/CD, which is exactly the kind of work clients hire freelancers to set up. The platform also connects curated freelance talent with organisations that need security-automation help, which could be a useful channel if you’re building a client base in this area.

The short version

You don’t need an enterprise security programme to freelance safely. You need a handful of small checks, done in the phase where each risk shows up: before signing, at onboarding, while setting up, while coding, when delivering and when leaving. Do them as you go and the scary end-of-contract clean-up mostly disappears. Your clients get peace of mind, and you get to sleep properly.