Securing External Collaboration and Project Access

Nobody set out to build an access model around uncontrolled sharing links. It happened because it works. A consultant needs a drawing, you send a link, they open it, the work continues. There is no friction, no delay, no setup. The tools encourage it — SharePoint, OneDrive, Teams, email attachments all make sharing a single click, and none of them prompt you to think about when the share should end.

The alternative — setting up a guest identity, scoping permissions, defining an expiry — has usually never been established. There is no template for it, no process that says this is how we onboard an external party, no step in the project workflow that says access is granted at this point and removed at this point. So people do what works in the moment, and the moment passes without anyone closing the door.

This is not a failure of the people doing the sharing. A site manager who sends a drawing link to a subcontractor is trying to keep the project moving. The failure is that the business has never given them a better way to do it — a way that is just as fast but also controlled, just as easy but also scoped, and just as immediate but also time-limited.

The result is that external access accumulates silently. Every link shared, every guest account created, every file forwarded is a small decision that made sense at the time. Together they form an access surface that the business cannot see, cannot audit, and cannot answer for if something goes wrong.

Sharing links that never expire. A link sent to a consultant eighteen months ago still works. The project finished, the consultant moved on, but the link is still live and still reaches the same folder with the same drawings, correspondence and commercial details.

Guest accounts from projects that finished years ago. The engineer who reviewed structural drawings in a completed project still has a guest identity in your Microsoft 365 environment. Nobody disabled it because nobody was assigned to, and nobody checked because there was no list to check against.

Consultants who changed firms but kept access. A consultant was invited using their work email, then moved to a different firm. The guest account still works, still reaches project information, and now sits in an inbox controlled by a different employer. The access was tied to a person, not a project, and the person moved on.

Subcontractors who can see commercial information they were never meant to see. A subcontractor was given access to a project folder to retrieve drawings, but the folder also contains the contract, the variations, the cost breakdown and the correspondence with the client. The permission scope was the folder, not the specific files the subcontractor needed.

And the question that nobody can answer: who currently has access to what? If you asked your team to produce a list of every external identity with access to your project information, how long would it take, and would it be accurate? For most construction businesses, the honest answer is that the list does not exist, and if it did, it would be out of date the moment it was written.

Projects end. Access rarely does. Handover is treated as a document milestone — the drawings are finalised, the close-out pack is assembled, the certificates are signed — but it is not treated as an access milestone. The guest accounts, the sharing links, the external identities all survive the project they were created for.

This is the point where the gap between the project team and the business becomes visible. The project team knows the work is done. The IT environment does not, because nobody told it. The guest account is still active, the sharing link is still live, the permissions are still in place. The project ended in the minds of the people who delivered it, but not in the systems that hold the information.

The fix is to make access removal a deliberate step in project close-out, not an afterthought. When the project is handed over, access is reviewed, scoped down and removed. External parties are told their access has ended. Guest identities are disabled. Sharing links are revoked. The project closes in the systems the same way it closes in the minds of the team.

This requires someone to own it. Close-out is busy, and access removal is invisible — nobody notices it was not done until something goes wrong months or years later. Assigning the step, making it part of the close-out checklist, and confirming it was completed is what turns a good intention into a practice that actually happens.

Access is granted per project, not per person. When a consultant joins a project, they receive a guest identity scoped to that project's SharePoint site and Teams channel — not to your entire environment. When the project ends, that identity is disabled. The next project they work on creates a new identity with a new scope and a new expiry, because the access belongs to the project, not the individual.

Every external identity has a defined expiry. Not a theoretical one — a real date, set when the access is granted, that the system enforces. When the date arrives, the access is reviewed or removed automatically. Nobody has to remember to do it, because the system does the remembering. If the project is still running, the expiry is extended with a reason. If it is not, the access closes on schedule.

External parties reach what they need and nothing else. A subcontractor can open the drawing set for their package but cannot see the tender pricing, the margin breakdown, the variations log or the correspondence with the client. The permission boundary is the role, not the folder. Commercial information sits behind a separate access boundary that subcontractors and consultants never cross.

There is a reviewable list of who has access to what. Not a spreadsheet someone maintains by hand, but a live view in the Microsoft 365 environment that shows every guest identity, every sharing link, every external collaborator and the project they are associated with. When someone asks who can see a particular project's information, the answer comes from the system in minutes, not from a search across inboxes and memory.

And removal happens as part of project close-out, not as something that has to be remembered afterwards. Close-out has a step — alongside finalising drawings, assembling handover packs and signing certificates — that says external access is reviewed, scoped down and removed. The guest identities are disabled, the sharing links are revoked, the external parties are notified. The project closes in the systems the same way it closes in the minds of the people who delivered it.

There is a simple test for whether an access control will hold in a construction business: is it at least as fast as emailing the file? If the secure path takes ten minutes of setup and the insecure path takes ten seconds, people will choose the insecure path every time — not because they do not care about security, but because they are trying to keep the project moving and the secure option is in the way.

This is why access controls fail in practice. They are designed by people who think about the security outcome but not about the person on site at four in the afternoon who needs to send a drawing to a subcontractor before a pour tomorrow. If that person has to raise a ticket, wait for IT, fill in a form and then wait for approval, they will attach the file to an email and move on. The control exists on paper but not in practice.

The control has to be built into the workflow, not bolted on top of it. A project site in SharePoint with pre-configured permission groups means a site manager can add a subcontractor to the right group in seconds — the same seconds it takes to attach a file — and the access is scoped, logged and expiring by default. The secure path is the easy path, and the easy path is the one people actually use.

Guest access in Microsoft 365 can be configured so that inviting an external collaborator is a single action that carries the right boundaries with it: scoped to the project, time-limited, and recorded on the access list. The friction is in the setup of the template, not in every individual share. Once the template exists, sharing is as fast as it was before, but it is also controlled. That is the point at which a control stops being a policy and starts being a practice.

If the workaround is faster than the control, the workaround wins. Every time. Designing the control so that it is the fastest option — not the most secure option that people tolerate, but the option that people reach for because it is easy — is what makes it hold.

Tender pricing, subcontractor rates, margins and variations are not the same kind of information as drawings, specifications and RFIs. Drawings need to reach everyone working on the package. Commercial information needs to reach almost nobody externally, and the few people who do need it — the client, the quantity surveyor, the head contractor's commercial manager — need it under a different set of controls than the drawing set.

In practice, most construction businesses put both in the same place. A project folder contains the drawings, the specifications, the contract, the variations, the cost breakdown and the correspondence, all behind one permission boundary. Everyone who can see the drawings can also see the commercial detail, whether they need to or not. A subcontractor invited to retrieve a drawing set can also open the tender summary, the margin calculation and the variation log, because the access was scoped to the folder, not to the information.

The practical separation is to hold commercial information in a separate site, library or channel with its own permission boundary, accessible only to the people whose role requires it — the project manager, the commercial manager, the client's representative. Drawings, specifications and construction information sit in the project site that external collaborators can reach. Commercial information sits behind a separate door that they cannot. The two sets of information are related, but they are not the same, and they should not share the same access boundary.

This does not require a complex system. It requires a decision about what goes where, and a permission structure that reflects it. In Microsoft 365, that means a separate SharePoint site or document library with restricted access for commercial documents, and a project site with broader access for construction information. The structure is simple. The discipline is in deciding what belongs behind which boundary and then holding the line when someone asks for convenience.

LOOKUP works on the Microsoft 365 environment that surrounds your project and document platforms — configuring external sharing policies, designing guest access with scoped permissions and automatic expiry, applying conditional access to external identities, and building a close-out process that removes access as a deliberate step rather than an afterthought. We set up the permission boundaries that separate commercial information from construction information, and we configure the sharing settings so that the secure path is as fast as the workaround.

We coordinate with project management, estimating and drawing platforms rather than replacing them. The project system remains the system of record for drawings, RFIs and project correspondence. Microsoft 365 provides the governed collaboration layer — the SharePoint project sites, the Teams channels, the permission groups, the guest access — that controls who can reach what and for how long.

The Microsoft 365 environment is where most external access lives, and it is where most of the work happens. LOOKUP configures the sharing policies, the guest access settings, the conditional access rules and the site templates that make controlled sharing the default rather than the exception. The Essential Eight mitigation strategies published by the Australian Signals Directorate include restricting administrative privileges and applying access controls — both directly relevant to managing who can grant external access and what that access reaches.

The close-out process is where access removal becomes real. LOOKUP builds the step into the project workflow so that when a project is handed over, external identities are reviewed, scoped down and disabled as part of the close-out — not as a task that someone has to remember months later when nobody is thinking about it anymore.

Construction & Property Development — the industry context for these outcomes, covering who LOOKUP supports across builders, developers, head contractors, architects, engineers and project management firms.

Improving Project Information and Document Control — is everyone on site building from the current drawing? How to get one authoritative version of project information that reaches the site.

Preventing Invoice Fraud in Construction — supplier impersonation and payment redirection are recognised threats to construction businesses. How to stop an impersonated email redirecting a payment.