Contractor disappears

What this means

An unreachable contractor is first a continuity problem, not proof of malicious intent. Protect the business without making accusations: preserve their work, suspend unnecessary access, transfer service ownership, and reconstruct the knowledge needed to operate.

Treat the situation as a security incident if you see unauthorized changes, data transfer, threats, extortion, deleted work, or access after revocation. Get legal advice before accessing a contractor’s personal accounts or devices.

Warning signs

• The contractor misses agreed check-ins and cannot be reached through primary or backup contacts.
• Deployments, support, billing, or maintenance depend on their personal account or device.
• Nobody else can access a repository, domain, cloud account, password vault, build, database, or customer conversation.
• Credentials are shared and there is no reliable way to distinguish their activity.
• Work, documentation, source code, invoices, or customer data exist only in contractor-controlled systems.

Recover now

First 15 minutes

1. Open an incident record and appoint one owner. Record the last confirmed contact, current commitments, systems involved, deadlines, and signs of malicious activity or personal emergency.
2. Try agreed contact routes calmly. Use the primary channel, backup contact, agency contact, and emergency method allowed by the contract. Ask for a short safety confirmation and handover; do not accuse or threaten.
3. Inventory their access and ownership. Start with password manager, email, source control, cloud, hosting, domain and DNS, CI/CD, databases, payments, support, newsletter, analytics, monitoring, social accounts, file storage, devices, and physical keys.
4. Suspend named access before deleting accounts. Disable SSO or user accounts, revoke active sessions, and remove repository or service access where business risk justifies it. Suspension preserves data and is easier to reverse if the absence is temporary.
5. Protect critical operations. Pause risky deployments and financial changes. Rotate any shared password, token, SSH key, API key, or recovery code the contractor knew; removing their named account does not revoke shared credentials.

Today

1. Transfer business-owned data before deleting identities. Reassign repositories, documents, calendars, support conversations, automation, billing, email, dashboards, and cloud resources to a current owner.
2. Recover control of contractor-owned services. Use contracts, invoices, payment records, provider support, and proof of business ownership. If an account is legally personal to the contractor, do not impersonate them; ask the provider and legal adviser for the correct transfer path.
3. Reconstruct current work. Review repositories, issue trackers, deployment logs, infrastructure, recent invoices, meeting notes, customer messages, and monitoring alerts. Write down production state, unfinished changes, deadlines, and unknowns.
4. Revoke non-human access linked to them. Check personal access tokens, SSH and deploy keys, OAuth or GitHub Apps, webhooks, CI/CD secrets, cloud access keys, database users, VPN profiles, device certificates, forwarding rules, and password-vault emergency access.
5. Secure physical and local copies. Request return of company hardware, keys, documents, and backups under the contract. Assume local clones and downloaded data cannot be technically recalled; rely on contractual and legal obligations.
6. Keep the business running conservatively. Assign temporary owners, freeze nonessential changes, notify affected customers only when delivery or security is materially affected, and bring in replacement expertise for systems nobody understands.
7. Escalate evidence of harm. Preserve logs and communications. Contact legal counsel, insurer, security help, providers, or law enforcement as appropriate for theft, sabotage, extortion, or data exposure.

Verify recovery

• Every critical service has a current business-controlled owner and recovery method.
• The contractor’s named accounts are suspended or removed, and old sessions and shared credentials no longer work.
• No critical domain, repository, cloud resource, payment account, dataset, or automation remains owned only by the contractor.
• A current operator can deploy, roll back, restore data, answer customers, and pay essential vendors without the contractor.
• Access and audit logs show no unexplained activity after containment.
• Outstanding work, unknowns, customer commitments, and legal follow-ups have named owners and dates.

After recovery

Separate the continuity review from any employment or contract dispute. Record which access, knowledge, ownership, or documentation gaps caused the disruption. Confirm data return or deletion using the contract and qualified legal advice rather than relying on technical access removal alone.

Prepare now

Access

• Every contractor uses a named account with only the access required for current work.
• Shared credentials are avoided; unavoidable shared secrets have a documented rotation procedure.
• Contractor access has an owner, purpose, start date, and review or expiry date.
• Critical services are registered to the business, not a contractor’s personal email, phone, card, or company.
• At least two trusted people can administer each critical service.

Backups and evidence

• Source, documents, designs, infrastructure configuration, and customer work are continuously stored in business-controlled systems.
• Critical work can be restored without access to a contractor’s device or personal account.
• The business retains access logs and an up-to-date inventory of accounts, keys, devices, and service owners.

Contacts and ownership

• The contract covers intellectual-property ownership, confidentiality, security, incident notice, handover, credential return, data return or deletion, and termination.
• A backup contact and a handover expectation are agreed before critical work begins.
• Every ongoing responsibility has both a primary owner and a documented fallback.
• Billing, renewal, support, and recovery contacts belong to the business.

Practice

• Someone other than the contractor can use the documentation to deploy, roll back, restore a backup, find credentials, and explain the current architecture.
• A recent access review removed a test contractor and verified that sessions, tokens, keys, apps, and shared secrets no longer worked.

Common mistakes

• Deleting the account before transferring its data. Email, files, calendars, automation, and audit context can disappear with it.
• Removing only the visible user account. Tokens, keys, sessions, shared passwords, apps, and local copies may remain.
• Assuming disappearance means sabotage. A personal emergency and malicious activity require different communication, even when the access response is similar.
• Trying to log in as the contractor. Accessing personal accounts can create legal and evidentiary problems.
• Hiring a replacement before securing ownership. A new contractor cannot safely operate services still controlled by the old one.
• Treating documentation as a final-week deliverable. Continuity requires business-controlled work and handover information throughout the engagement.

Sources

• NIST SP 800-171 Rev. 3: Personnel termination and transfer
• NIST SP 800-171A Rev. 3: Assessment of access disablement, credential revocation, and property return
• GitHub: Removing an outside collaborator
• GitHub: Managing deploy keys