Protect project access when subcontractors join and leave

List the document environment, BIM tools, planning, ERP, reporting, file-sharing and relevant site systems. Identify the organisation that administers each, the information it holds and the user or service identities that connect it to others. Include external portals operated by clients or subcontractors.

Classify access by purpose and scope. A supplier submitting one package may not need visibility of all current designs or tender prices. A site supervisor may need approved work information while having no reason to see commercial bids. The project sponsor and data owner should define the business need; the security and system owners implement it.

Record integration accounts and automated exports as well as people. Removing a person's login does not necessarily remove a shared link, cached session, local export or service credential. The appropriate treatment of each needs to be part of the approved access process.

In this fictional case, the subcontractor's package is complete. The project owner initiates the agreed access change. The document account is disabled, but a test using the former user's authorised test identity reveals that the reporting portal still exposes current bid information.

Keep the exit task open and route the failed revocation to the security and portal owners. They investigate the actual access path, apply the authorised correction and verify the result across the relevant systems. Preserve evidence of the original request, implementation and verification.

The example is an access-control test, not permission to use a real former worker's credentials or inspect unrelated private material. Use approved test accounts and representative records for the exercise. Any suspected real exposure follows the organisation's incident process and evidence-handling requirements.

Named accounts help attribute activity and manage role changes. Apply the organisation's authentication policy, including stronger authentication where required, and limit permissions to the approved purpose. Review privileged roles separately from ordinary project access.

NIST's Cybersecurity Framework 2.0, particularly PR.AA-05, addresses managed and reviewed permissions with least privilege and separation of duties. It provides a risk-management basis for these controls. It does not certify a project platform or establish compliance with every Indian requirement.

Where a shared or service identity is necessary, assign an accountable owner, permitted use and review process. Avoid letting an unnamed permanent administrator account become the default integration method. Credential storage, rotation and recovery belong to the authorised security process, with access limited accordingly.

A person can change package, employer, responsibility or project before leaving entirely. The new assignment may require some permissions and make others unnecessary. Record the effective change and review both additions and removals.

At package closeout, distinguish access needed for ongoing defect work from access to current tender information. A supplier may need a limited service route after its construction role ends. Preserve that scope explicitly rather than leaving the original broad account active indefinitely.

Test search, notifications, downloads and APIs as well as the main application screen. A restricted document remains exposed if its contents appear in an unrestricted report or notification. Keep historical author attribution when removing current access so earlier approvals remain understandable.

Backups are useful only when the organisation can restore the records it needs with their integrity and access controls intact. NIST CSF 2.0 includes tested backups and verified restoration in PR.DS-11 and RC.RP outcomes. Define the exercise around the project's actual recovery needs.

Use a controlled environment and approved recovery procedure. Select representative drawings, approval history, asset information and commercial records. Check versions, links, permissions and retrieval after restoration. A successful file count does not prove that the restored package is operationally usable.

Agree recovery objectives and ownership from the business requirement rather than inserting a universal number of hours. If the system cannot provide current approved records during an outage, the project must use its established work-control and continuity arrangements. A stale cached drawing should not be presented as current approval.

A compromised-account exercise should show who receives the alert, who can contain access, how evidence is preserved and who assesses the affected information. Use an authorised simulation with test records; do not disrupt live project access merely to prove that a response button exists.

The responsible security, legal and compliance owners determine applicable notifications, contractual duties and reporting deadlines from the actual event and current requirements. Keep that assessment distinct from technical containment. A generic dashboard timer cannot determine every obligation.

After correction, verify the access boundary again and reconcile any affected records. Preserve the change history and lessons from the exercise. Do not close the issue solely because the original account was disabled if the connected portal or sharing route remains open.

An existing identity platform and disciplined system-owner process may be sufficient when integrations are manageable. A central access-governance tool can help when many organisations and applications change frequently. Compare actual propagation and verification, not the number of systems listed in a brochure.

Test a joiner, a package transfer, an exit, a privileged role and a service identity. Measure the time from an authorised change request to verified enforcement, with failed or pending systems visible. Keep approved exceptions time-bounded and owned under the organisation's policy.

The site-data privacy guide covers the related purpose and processing boundaries. This access workflow focuses on who can reach project systems, how that changes and whether the organisation can recover its evidence.

A dependable result is a verified access position and a tested recovery path that the next project team can understand.

1. Map project systems, owners, data scopes and connected identities.
2. Test the subcontractor exit across documents, reporting, links and integrations.
3. Resolve failed revocation and verify ordinary-account access before closing the task.
4. Rehearse controlled restoration and incident handoff with the responsible security team.