How to Define Access Revocation Rules for Departed Subcontractors Before Project Data Stays Open

When a subcontractor finishes their scope and leaves a jobsite, the physical departure is visible. The digital departure often is not. Field collaboration platforms, document control systems, BIM viewers, and project extranets carry accounts that were created at onboarding and are rarely reviewed at offboarding. The result is lingering access to cost data, safety records, RFI histories, and sometimes live model files, held by users who have no current relationship with the project.

This is not a hypothetical edge case. Most general contractors manage dozens of active subcontractor accounts per project, and most projects run multiple platforms simultaneously. Multiply that across a portfolio and the number of stale credentials grows quickly. Addressing it requires a written revocation policy that travels with every subcontractor agreement, not a cleanup effort that happens when someone remembers to ask.

Why Revocation Deserves Its Own Written Policy

Access management during onboarding gets attention because it is tied to a visible event: a subcontractor starting work. Revocation gets less attention because offboarding is uneven. Some scopes end on a defined substantial completion date. Others trail off as punch list items close over weeks. Some subcontractors return for warranty work months later. Without a written policy, each situation gets handled differently by whoever happens to be managing that platform that week.

A written revocation policy removes the judgment call. It defines exactly what triggers a revocation review, who performs it, on which platforms, and within what timeframe. That specificity is what makes the policy executable under project pressure.

Triggers Worth Defining

Rather than tying revocation to a single event, consider defining a short list of triggers that each starts a review. Practical candidates include: the subcontractor's scheduled scope completion date as recorded in the project schedule, issuance of final payment, expiration of the subcontract term, a formal notice of default or termination, and any personnel change at the subcontractor that affects the named account holders.

Schedule-based triggers are particularly useful because they connect revocation review to information the project team already tracks. When a subcontract milestone closes in the project controls system, that event can prompt a notification to whoever owns platform administration.

Warranty access is worth addressing separately in the policy. If a subcontractor will need to return to the project for warranty or service work, define in advance which platforms they retain access to, at what permission level, and for how long. A read-only view of relevant submittals is different from full write access to an active field platform.

Platform Scope in the Policy

A revocation policy that covers only the primary field collaboration platform will miss the others. A typical project might involve a document management system, a BIM coordination viewer, a punch list or quality platform, a safety observation tool, and possibly a drone data portal. Each has its own user directory. A subcontractor may hold accounts in several of them.

The policy should list the platform categories in scope and assign a responsible administrator for each. In many organizations, IT manages identity infrastructure but individual platform administration sits with project teams or a BIM coordinator. The policy needs to reflect how your organization actually works, not an idealized structure.

If your organization uses a single sign-on system that federates access across multiple platforms, revocation may be achievable through one action. If each platform is administered separately, the policy needs to account for that sequence and confirm completion across all of them.

The Confirmation Step

Revocation without confirmation is incomplete. The policy should require that whoever performs the revocation documents what was removed, on which platform, and when. A simple log entry in a shared project administration file is sufficient. What matters is that someone can verify, at any later point, that access was actually removed rather than only requested.

This confirmation step becomes relevant if a security incident, a contract dispute, or a regulatory inquiry raises questions about who had access to project data at a specific time. An audit log in the platform itself is useful, but a separate confirmation record controlled by your team is more reliable evidence of your organization's intent and action.

Connecting Revocation to Subcontract Language

The most durable way to set expectations is to reference access revocation in the subcontract itself. This does not require lengthy technical provisions. A short clause noting that platform access is provided for the duration of the subcontract scope, that the subcontractor is responsible for notifying the general contractor of any personnel changes affecting account holders, and that access will be reviewed and adjusted at scope completion is sufficient to establish the obligation in writing.

This framing also shifts part of the responsibility to the subcontractor. Requiring them to report personnel changes gives your team an additional trigger for review and creates a documented basis for action if access issues arise later.

Practical Starting Point for Teams Without a Current Policy

If your organization does not have a written revocation policy today, a reasonable starting point is to audit one recently closed project. List the platforms that subcontractors accessed during that project, then check whether those accounts were deactivated after scope completion. The gap between what you find and what you would want to find is the scope of your policy problem.

From there, draft a one-page policy that names the triggers, the platforms in scope, the responsible administrators, and the confirmation requirement. Review it with whoever manages subcontractor agreements to make sure it aligns with how contracts are structured. Run it on the next project that onboards a new subcontractor.

The goal is not a perfect policy on the first attempt. It is a written standard that your team can follow, refine after each project, and point to when a question arises about why a former subcontractor does or does not still have access to your project data.