It is Thursday afternoon at a payments company in Amsterdam. The contract platform engineer who built most of the company’s Kubernetes setup over the past year posts a goodbye message with a link to “Platform handover v3”: nine pages, architecture diagrams, a section called “gotchas”. People reply with thank-you emojis. Two weeks later the TLS certificate on the internal API gateway expires on a Sunday morning. It turns out the renewal was never automated. The engineer renewed it by hand every 90 days from a script on his laptop, using a cloud access key that is still active, because nobody knew it existed.
The scenario is invented, but every engineering manager who has worked with external specialists will recognise each piece of it. This article is for tech leads, engineering managers and HR partners who are responsible for ending an engagement with a contractor in a staff augmentation model. The argument is this: contractor offboarding is not a task for the notice period; it is evidence you collect throughout the engagement. A handover document written in the final week is the weakest form of knowledge transfer available. The only reliable test is that the team is already doing the departing person’s work before that person leaves, and that the last day is boring.
Plenty of companies believe the opposite: that good offboarding means a good checklist and a well-written document. The checklist matters, but it answers the question “did we do the steps?”, not “can we operate without this person?”. The second question is the one production will ask on the first Monday.
Why is a contractor’s last day the most expensive day of the engagement?
Because on that day knowledge that lived “with someone” stops being available, and somebody else pays to rebuild it. Panopto’s Workplace Knowledge and Productivity Report from 2018, based on a YouGov survey of just over 1,000 US workers, estimated that 42% of institutional knowledge is unique to the individual and not shared with colleagues. The survey covered knowledge workers in general, not only software teams, but the mechanism in engineering is the same and often stronger, because system knowledge lives in code, configuration and people’s heads, in decreasing order of readability.
Teams with contractors add a second factor. External specialists are frequently brought in precisely for the areas the internal team lacks the skills or time to cover: a new payment provider integration, a cloud migration, test automation, database performance. In those areas the specialist knows more than anyone else by design. When they leave, they take the most concentrated knowledge the team had.
What does that cost? There is no reliable study that gives a single figure, so it is better to work it out yourself. An illustrative estimate: if a successor needs six weeks instead of two before they can change the inherited area independently, those four extra weeks of senior time at EUR 335–485 per day (the reference range ARDURA publishes for senior developers) come to roughly EUR 6,700–9,700 in the successor’s time alone. Add the time the rest of the team spends answering questions and the risk of an incident in an area nobody understands. The drivers of the result are the size of the area, the quality of automated tests, the number of integrations and whether anyone else on the team has ever worked in that code.
The last day is also the most expensive from a security standpoint. Accounts, tokens and secrets the team does not know about do not expire on their own. Verizon’s 2025 Data Breach Investigations Report found that third-party involvement in breaches doubled year over year, from 15% to 30%. A staff augmentation contractor is not a “third party” in the report’s sense, but their access sits on the boundary between two organisations, and boundaries are where controls are weakest.
How is contractor offboarding different from an employee leaving?
At first glance it isn’t: someone leaves, you collect the equipment, disable accounts and reassign work. In practice there are at least five differences, and each one changes the plan.
There is a vendor in the middle. In staff augmentation your contract is with a company, not the individual. Notice, replacement, equipment returns to the vendor, the final invoice and confirmation of the IP assignment all go through the vendor. If the vendor does not know your offboarding has a plan, it cannot align its own steps with it. NIST SP 800-53 Revision 5 has a dedicated control for this, PS-7 External Personnel Security, which requires external providers to notify the organisation when their personnel leave, precisely so that access can be revoked on time.
Code ownership does not transfer by default. In the US, code written by an employee within the scope of employment is a work made for hire owned by the employer. Software written by an independent contractor generally does not fall into the statutory work-made-for-hire categories, so ownership moves only through a signed written assignment. The EU Software Directive (2009/24/EC, Article 2(3)) gives employers the economic rights to programs created by employees in the course of their duties, and again says nothing that covers contractors. This has to be settled before the last day, not after, and we come back to it below.
The notice period is shorter and set by a commercial contract. For employees, notice is set by employment law and the employment contract, and in many European countries it grows with tenure. In staff augmentation it is whatever the vendor contract says. At ARDURA, every engagement can be ended with 30 days’ notice and no penalties. That flexibility is an advantage for the client, but it also means the whole offboarding has to fit inside a month. Read what your contract actually says; our glossary entry on notice periods covers the typical terms.
Contractors often hold broader technical permissions than an equivalent employee. Counterintuitive, but common. A specialist brought in to “sort out the infrastructure” gets cloud admin rights on day three because otherwise they cannot work, while an employee in the same role would have accumulated those rights gradually. The faster someone was granted access, the worse that access tends to be documented.
End-of-engagement incentives are different. A departing employee often stays in the same industry and city and cares about references. A contractor usually moves to their next project with the same vendor, which works in the client’s favour: the vendor wants the exit to be clean. That is a reason to plan offboarding together with the vendor, not around it.
When does offboarding really begin?
On the first day. That is not a figure of speech. Three things set up during the first week of an engagement determine whether the notice period will be calm.
The first is an access register. Every permission granted to an external specialist goes into one place: system, role, who approved it, date. This is not bureaucracy. It means that on the day notice is given, the list of things to revoke already exists. Without a register, revoking access depends on memory, and memory fails exactly on the tools used once a month. If you run onboarding from a checklist, and we have written separately about onboarding external specialists, add a “register entry” box next to every access grant.
The second is the second-person rule. Every area a contractor works on has someone on the internal team who reviews their changes, joins key decisions and could take over if needed. In 2016 Guilherme Avelino, Leonardo Passos, Andre Hora and Marco Tulio Valente analysed 133 popular GitHub projects and found that 65% of them had a truck factor, the number of people whose departure would stall the project, of two or fewer. Those are open projects, often with hundreds of contributors. In a closed commercial codebase where one external specialist owns a module, that module’s truck factor is usually exactly one unless someone deliberately raises it. Code review by a second person and pair programming at critical moments are the cheapest ways to do that.
The third is recording decisions when they are made. Short architecture decision records, pull request descriptions that explain why and not only what, runbooks written after the first incident rather than the last one. Documentation written as you go costs minutes. Documentation reconstructed at the end costs days and is worse, because the author no longer remembers the context.
If these three things worked from the start, the notice period is for verification, not rescue. If they did not, and you have just learned the engagement is ending, the rest of this article shows how to catch up in 30 days. But treat it as a signal to start the next engagement with the register.
What exactly has to be secured: knowledge, access, code, or something else?
Five things, not three. Knowledge, access and code are the obvious categories; the other two are the ones that usually get lost.
Code. Everything the specialist wrote must be in the organisation’s repository, either merged or explicitly abandoned. That includes helper scripts, local configuration, data analysis notebooks, SQL queries they ran by hand and infrastructure-as-code they tested locally. Code that lives outside the repository is the single biggest source of surprises.
Knowledge. Two kinds. Explicit knowledge that can be written down: how a module works, its dependencies, known issues. And tacit knowledge the author often isn’t aware of: why a parameter has that particular value, which alert can be ignored on Monday mornings, whom to call in finance when the numbers don’t reconcile. The second kind is more valuable and does not travel through documents.
Access and secrets. Named accounts are half of it. The other half is the secrets the specialist knew or created: API keys, service account passwords, pipeline tokens, SSH keys added to servers, MFA devices tied to shared accounts.
Artefacts and commitments. Open tickets, promises made to other teams (“I’ll add that endpoint next sprint”), scheduled jobs, subscriptions and licences registered to their email address, cloud resources they spun up for testing that still cost money every month.
Relationships. People who got used to messaging the specialist directly: other teams, external vendors, business stakeholders. If nobody tells them whom to contact now, their messages will disappear into a void for weeks.
These five categories frame the rest of the article. An offboarding plan is essentially five lists, each with an owner on the internal team.
How do you plan a 30-day notice period week by week?
The typical mistake is treating the notice period like a normal month of work with a footnote: “and hand over at the end”. The specialist keeps pulling tickets from the backlog until the final week, then writes a document. The result is that the most new, untransferred code is produced exactly when the least should be.
A better split reverses the proportions. Week one is inventory and planning, week two is closing out and writing down, weeks three and four are the team doing the work under observation. The table below shows the plan for a 30-day period. If your contract has a different notice period, scale it, but keep the rule that at least the final third belongs to the team, not the departing specialist.
| Week | Goal | Main activities | Led by | Evidence the stage is done |
|---|---|---|---|---|
| 1 | Inventory | List of areas, access, secrets, scheduled jobs and open commitments; a named receiver for each area; agreements with the vendor | Tech lead + specialist | Five lists with owners, signed off by the tech lead |
| 2 | Close out | Merge or abandon open branches; move scripts into the repo; record decisions and runbooks; freeze new work in the area | Specialist | No open branches by the specialist without a decision; runbooks executed by someone else |
| 3 | Reverse shadowing | Receivers perform the area’s tasks; the specialist observes and answers; a gap list is kept | Receivers | Gap list with due dates; at least one deployment done without the specialist’s hands |
| 4 | Absence test and cut-over | Days when the specialist answers written questions only; progressive permission reduction; secret rotation plan; paperwork | Tech lead + HR partner + vendor | Access register empty for the specialist; rotation scheduled; exit record signed |
Two practical notes. First, in week two freeze new work in the departing specialist’s area, especially anything large. A feature started that week will be finished in a hurry or handed over half-done, which is worse than handing over something complete. Second, schedule the period so that the last day is not a Friday before a long weekend or a release day. The last day should be boring, and boredom has to be planned.
The HR partner’s role here is bigger than it looks. They are usually the first to hear that an engagement is ending (from the vendor or from leadership), they track the formal deadlines, and they can make sure everyone who worked with the contractor is told. The tech lead owns the substance; the HR partner makes sure nothing falls between the chairs.
Why is a handover document written in the final week nearly worthless?
This is the most contested part of the argument, so it deserves a proper defence. A handover document is not worthless. It is simply the weakest tool available, and in many teams it is the only one.
First reason: a document describes what the author thinks matters, not what the reader doesn’t know. The author knows the system so well they cannot see where someone else will trip. They write about the architecture because it feels important and leave out that the staging certificate has to be renewed by hand every 90 days, because to them that is obvious. The gaps in the document sit exactly where the knowledge is most tacit.
Second reason: it is written under time pressure by someone whose attention has already moved on. This is not bad faith. The specialist is thinking about the next project, has final tickets to close and writes the handover on a Thursday evening. Nine pages with diagrams look solid, but nobody has tested them.
Third reason: nobody checks the document before the author leaves. It is first read when something breaks. That is when the steps turn out to be out of date, links point to deleted pages and “gotcha number four” is a single sentence that only made sense to the person who wrote it.
Fourth reason: tacit knowledge, by definition, cannot be written down on request. It surfaces only in situations that need it: a deployment, an incident, an unusual customer ticket. That is why the best way to transfer it is joint work on real tasks, not “tell us about the module” sessions.
What replaces it? The document still gets written, but its role changes. It is not “the knowledge transfer”; it is an index: a list of areas, links to runbooks, decision records and repositories, a contact list. Short, current and tested by the person taking over. The actual transfer happens in weeks three and four through work, and the document is a by-product: every question raised during reverse shadowing, together with its answer, goes into a runbook.
Someone will ask: what if the contractor leaves overnight, through illness or an emergency? Then there is no document and no shadowing, and all you have is what you built earlier: the access register, a second person in each area, decisions recorded as they happened. Which is one more argument that offboarding is collected over the whole engagement.
How do you verify that knowledge actually moved to the team?
Through reverse shadowing and an absence test. Both are simple, but both need discipline, because shortcuts are tempting.
Reverse shadowing inverts normal onboarding. In onboarding, the newcomer watches the experienced person. In offboarding, the receiver does the work and the departing specialist watches, speaking up only when the receiver is stuck or heading the wrong way. The rules: the receiver’s hands are on the keyboard, the specialist does not “just show it quickly”, and every question the receiver could not answer alone is logged as a gap.
Which tasks should be shadowed? The ones that happen most often in the area and the ones that carry the most risk. For an application module, a typical set is: deploying a change to production, diagnosing and fixing a reported bug, responding to a monitoring alert, changing configuration, answering a business question about the data. For an infrastructure area: provisioning an environment, renewing a certificate, restoring from backup, scaling a service. If the receiver gets through these scenarios with few questions, the knowledge has moved. If not, you know exactly what is missing.
The absence test covers the final days before departure, when the specialist is formally on the clock but not involved in daily work. They answer only questions posted in writing on a shared channel, and every question and answer goes into a runbook. The test shows how many questions the team has when the specialist is “gone”, while keeping a safety net because they are still there.
How do you judge the result? Simple criteria are enough. Has the receiver performed at least one deployment in the area independently? Has every runbook been executed by someone other than its author? Is the number of absence-test questions falling day by day? Is the shadowing gap list closed, or does every remaining gap have an owner and a date? If any answer is no, that is a decision point: narrow the scope of what is handed over, ask the vendor for a short extension, or arrange a few paid consultation hours after the engagement ends.
To be fair, reverse shadowing costs money. For two weeks you pay for a specialist who ships no new features, and you occupy the receiver’s time. Anyone who objects should compare that cost with the estimate in the first section: several weeks of slower work by the successor plus the risk of an incident in an area nobody understands. Two weeks of shadowing is almost always cheaper.
How do you hand back code so nothing lives on a single laptop?
The rule: on the last day, not one line of code, script or configuration exists only on the departing specialist’s machine. It sounds obvious, but in practice it means checking several places that are easy to forget.
Branches. List every branch the specialist authored and decide for each one: merge, hand to a named person, or delete with a note explaining why. A “for later” branch without an owner is a debt nobody will pay.
Open pull requests. They must be closed or reassigned. Taking over someone else’s PR halfway through review is one of the most frustrating jobs on a team, so it is better for the specialist to finish them in week two.
Local scripts and tools. Ask directly: what do you run on your machine rather than in the pipeline? Data migration scripts, report generators, diagnostic tools, SQL saved in a database client. Anything used more than once goes into the repository with instructions. Anything run on a schedule goes into the organisation’s scheduler, not a cron job on someone’s laptop.
Configuration and environments. Config files, environment variables, IDE settings needed to build the project. A simple test: the receiver clones the repository on a clean machine and builds the project from the README. If that fails, something is still on the specialist’s laptop.
Infrastructure. Cloud resources created by hand rather than from code. If the specialist built infrastructure, ask for a list of resources created outside your infrastructure-as-code tooling and decide which should be codified and which deleted.
One thing cannot be done technically: recalling local copies. GitHub’s documentation is explicit that removing a collaborator from a private repository revokes their access and deletes their forks of it on GitHub, but the former collaborator keeps any local clones. That is no reason to panic, because the specialist is bound by contract and confidentiality obligations. It is a reason to include in the exit record a statement that copies of code and data have been deleted from personal devices, particularly any personal data if the specialist had access to it, which under the GDPR remains your responsibility as controller.
Which access should be revoked and which secrets rotated?
This is the most important distinction in the whole process: disabling an account does not invalidate a secret. If the specialist knew the password for a database service account, disabling their SSO account does not change that password. If they generated an API key for your payment provider and put it in a pipeline, the key keeps working regardless of whether its creator still has access to anything.
The scale of the problem is measurable. GitGuardian’s State of Secrets Sprawl 2025 report counted about 23.8 million new secrets pushed to public GitHub repositories in 2024, and found that 70% of secrets detected in 2022 were still valid in 2024. Those figures describe public repositories, not your team, but they show the mechanism: secrets live far longer than they should because nobody rotates them. We covered how to make rotation routine rather than a project in our article on secrets management in CI/CD pipelines.
A practical split into three categories:
Revoke: named accounts. Email and calendar on your domain, the SSO account and everything behind it, repositories, cloud IAM users, roles and groups, work-tracking tools, chat, VPN, monitoring, and SaaS tools with named accounts that are not behind SSO. The last category is the one most often missed, because it does not switch off when SSO does.
Rotate: shared secrets and secrets the specialist created. Passwords of technical and service accounts they knew. API keys and tokens they generated, including those stored in pipelines and secret managers. SSH keys added to servers (check authorized_keys files, not just accounts). Passwords for shared accounts, such as an admin login at an external SaaS provider. MFA devices tied to shared accounts.
Reassign: resources and subscriptions. Third-party accounts registered to the specialist’s address, licences assigned by name, alerts and notifications routed to them, scheduled jobs running with their permissions. These will stop working or stop notifying anyone once the account goes, which is sometimes worse.
When should this happen? Here is another position not everyone will accept: do not cut everything in the last hour; reduce permissions progressively over the final two weeks. In week three, when the team takes over the work, the specialist no longer needs production deployment rights. Remove them and leave read access. If something breaks, you find out while the specialist is still around to help, not on the Monday after they leave. On the last day only a handful of core accounts remain, which can be disabled quickly and verified. ISO/IEC 27001:2022 control A.5.18 (access rights) expects permissions to be reviewed and removed when no longer needed; progressive reduction simply applies that principle consistently during the notice period.
Secret rotation should happen after the last day, not before it, because the specialist may need a working environment until the end. In practice: the rotation list is ready in week one, rotation happens on the first working day after departure, and someone other than the person who did it confirms completion. For the wider picture, including identity management across the organisation, see our guide to IT security in business.
What has to be settled contractually before the specialist leaves?
Three formal matters that are much harder to resolve after the last day than before it.
IP assignment. As noted above, contractor code is not automatically yours. In the US, 17 U.S.C. § 204(a) requires a transfer of copyright ownership to be in writing and signed, and work-made-for-hire treatment generally does not reach software written by an independent contractor. In EU member states the rules differ in detail, and several, including Poland, require a written agreement that lists the specific fields of use being transferred. In staff augmentation the chain usually runs from the specialist to the vendor and from the vendor to the client. Before the last day, confirm that both links exist, that they cover everything you need, and when the transfer takes effect. Many contracts tie the transfer to payment of the invoice for the period, which means rights in the final month’s code pass only once the final invoice is paid. That is normal, but you should know it. We went through this in detail in who owns the code in staff augmentation.
Obligations that outlast the engagement. Confidentiality, restrictions on using client data, any non-solicitation or non-compete terms where they are enforceable. ISO/IEC 27001:2022 control A.6.5 (responsibilities after termination or change of employment) requires that security responsibilities remaining valid after someone leaves are defined, communicated and enforced, contractors included. In practice: remind the specialist in the final week which obligations still bind them, and confirm the vendor has them in its own contract with the specialist.
Return of assets and an exit record. ISO/IEC 27001:2022 control A.5.11 requires organisational assets to be returned when employment, a contract or an agreement changes or ends. Assets are not only a laptop, if you issued one, but also hardware security keys, badges, paper documents and data. It is worth closing the engagement with a one-page record signed by the tech lead, the specialist and the vendor: assets returned, access revoked, a statement that copies of code and data have been deleted from personal devices, and confirmation of the IP assignment. A year later someone can show that page to an auditor or a lawyer.
If your company is an EU financial entity, there is one more layer. The Digital Operational Resilience Act (DORA), applicable since 17 January 2025, requires in Article 28(8) exit strategies for ICT services supporting critical or important functions, with exit plans that are documented, sufficiently tested and periodically reviewed. The provision concerns the relationship with an ICT service provider rather than an individual specialist, but the departure of a key contractor is exactly the kind of event such a plan should anticipate.
What role should the staffing vendor play in offboarding?
A bigger one than most clients assume, and it is worth using. The vendor has three things the client does not: the contractual relationship with the specialist, the ability to supply a successor, and experience across many exits.
The contractual relationship. The vendor can require the specialist to return equipment, sign statements and honour post-engagement obligations. The client can ask; the vendor can insist. So send the offboarding plan to the vendor in the first week of the notice period and ask them to confirm which items they own.
A successor and an overlap. If the area still needs work, the best option is an overlap: the successor starts before the predecessor leaves and goes through reverse shadowing alongside the internal team. At ARDURA, if a specialist leaves mid-engagement, we guarantee a replacement within 5 business days, and every new engagement starts with a 2-week replacement guarantee. If the replacement joins in the first week of the notice period, that leaves several weeks of joint work, which is roughly what the plan above needs. The terms of our staff augmentation services are set out on the service page.
Experience. A vendor running many engagements knows what usually goes missing. Ask directly: what most often surfaces after a specialist leaves at other clients? What is your handover standard? Who on your side makes sure the specialist leaves things in order? A good vendor has concrete answers.
There is one thing a vendor cannot do for you: absorb the knowledge. The knowledge has to land in the client’s team, because the client will maintain the system. A vendor can supply a successor, but if an entire area passes from one contractor to the next and nobody internal understands it, the area’s truck factor is still one. That is why the second-person rule on the client side applies when a specialist is swapped, not only when an engagement ends. Our glossary entry on offboarding and knowledge management summarises the same principles.
How do you measure whether offboarding worked?
Offboarding formally ends on the last day, but its outcome shows only weeks later. Measure it like any other team process, otherwise every offboarding will look the same as the last one.
Five simple indicators that need no special tooling:
Time from departure to the first independent change in the area. How many days passed before someone on the team shipped a change in the inherited area without outside help? If reverse shadowing worked, that change happened before the departure, so the answer is zero.
Questions sent to the former specialist. How many times in the following 30, 60 and 90 days did someone have to contact the departed specialist, through the vendor or directly? Each one is a gap you did not catch during the notice period.
Incidents in the inherited area. Number and time to resolve incidents in the area for 90 days after departure, compared with the 90 days before. More incidents does not necessarily mean poor offboarding; longer resolution times usually do.
Time to revoke access. How many hours passed between the end of the last day and the disabling of the last named account? How many secrets on the list were rotated on the first working day after departure? An auditor will ask exactly this.
After-the-fact discoveries. An account that was not in the register. A script that was not in the repository. A subscription on the specialist’s email address. Each discovery becomes a line on the checklist for next time.
Collect these indicators in a short review 30 days after the departure with the tech lead, the HR partner and the receiver. Half an hour is enough to update the checklist and the access register for future engagements. If you work with the same vendor repeatedly, share the results with them as well.
A checklist for the final week
The checklist does not replace the argument of this article, but it is needed to close the items that require no thinking. Here is a version you can paste into your work-tracking tool and assign owners to.
Code and artefacts (owner: tech lead). All of the specialist’s branches merged or closed with a decision. No open PRs authored by them. Local scripts moved into the repository. Scheduled jobs moved into organisational infrastructure. Project built from scratch on a clean machine by the receiver. Test resources in the cloud deleted or reassigned.
Knowledge (owner: receiver). Knowledge index updated. Every runbook executed by someone other than its author. Reverse-shadowing gap list closed or every gap owned and dated. Architecture decisions recorded. External contacts told whom to reach now.
Access (owner: tech lead + administrator). Production permissions removed in week three. Named accounts disabled on the last day, including SaaS tools outside SSO. Secret rotation list ready and rotation scheduled for the first working day after departure. SSH keys removed from servers. Alerts and notifications rerouted.
Paperwork (owner: HR partner). Vendor confirmation of the IP assignment chain. Reminder of post-engagement obligations. Assets returned. Exit record signed by all three parties. Date set for the 30-day review.
If any of these items is new to you, reread the section on when offboarding begins. Most of them are easy in the final week only if the groundwork started much earlier.
What are the key takeaways for tech leads and HR partners?
Offboarding a contract specialist is neither a farewell courtesy nor a box to tick for the auditor. It is the moment you find out whether the team built knowledge or merely rented it. The good news is that almost everything that decides the outcome can be planned.
Remember six things. First, start offboarding on the first day: an access register, a second person in every area and decisions recorded as they are made. Second, reverse the proportions of the notice period: a week of inventory, a week of closing out, two weeks of the team working under the specialist’s observation. Third, do not trust a handover document until someone other than its author has followed it. Fourth, remember that disabling an account does not invalidate a secret, and rotate everything the specialist knew or created. Fifth, settle the paperwork before the last day: the IP assignment chain, post-engagement obligations and the record of returned assets. Sixth, measure the outcome at 30, 60 and 90 days and improve the checklist for next time.
If you are planning changes to your team or want a successor to take over an area from a departing specialist with a proper overlap, see how our staff augmentation services work: engagements can be ended with 30 days’ notice, and if a specialist leaves mid-engagement we provide a replacement within 5 business days. Get in touch if you would like to talk through a handover plan for a specific area.