Construction firms have finished the argument about whether project data belongs in the cloud. Cloud accounted for roughly 64% of construction management software revenue in 2025, according to Mordor Intelligence, with construction ERP at about 61%. Cloud is the majority in both.
The move was sensible. A server in the office is exactly as secure as the person maintaining it, and at most firms that person is also handling jobsite connectivity and the accounting system.
What hasn’t kept pace is how contractors evaluate the vendors holding that data. Nearly every construction software product describes itself as enterprise-grade or bank-level secure. Neither phrase means anything. No standards body defines them, no audit awards them and there is no penalty for using them. They appear on the websites of companies with mature security programs and on the websites of companies with none.
That gap matters more in construction than in most industries. Drawings, submittals, RFIs, contracts and pay applications move among designers, trades, suppliers, owners’ reps and lenders for the length of a job and often years after. Every handoff lands in somebody’s cloud tenant, so a contractor’s exposure extends well past the platforms it bought. Ransomware groups have noticed. Construction moved from the sixth most targeted industry to the fourth in a year, with 131 victims in the first quarter of 2026 by GuidePoint Security’s count, up 44% year over year.
The Questionnaire Usually Asks the Wrong Things
Most vendor security reviews open by asking whether data is encrypted at rest. Every vendor says yes, because it has been standard for a decade. Encryption at rest defends against someone carrying a drive out of a data center, which is not how project data gets lost. It gets lost through a valid credential held by someone who shouldn’t have one anymore.
The penetration testing question has the same problem. Everyone does. The answer means something only with three follow-ups: what was in scope, how long remediation took and whether findings were retested.
Five questions have answers that either exist on paper or don’t:
Is there a SOC 2 Type II report, and what’s in the exceptions?
Type I describes controls at one moment. Type II tests whether they operated over three to 12 months. The section that matters is the auditor’s list of exceptions, not the cover page. A report with a few exceptions and clear management responses often beats a spotless one, because it shows the auditor looked. Check the scope statement too, on the SOC 2 and on any ISO 27001 certificate. Certified boundaries are sometimes narrower than the product being bought, and leaving out the mobile app or the integration layer is legitimate when it’s disclosed. Almost nobody reads that far.
Where does the data live, and who else touches it?
Vendors run on subprocessors: hosting, backup, analytics, support tooling. Each is another party holding project data. A current subprocessor list and the storage regions should be available on request. Firms on Canadian or European projects often carry residency obligations they have never traced through to their software.
Which vendor employees can read project files?
Support staff often need access to troubleshoot. The right answer isn’t that nobody can. It’s that access requires approval, expires and gets logged where the customer can see it.
What are the default settings?
Almost no one asks this one. Shared responsibility means the vendor secures the platform and the customer controls access, which any vendor will confirm. What they rarely volunteer is that defaults tend to be permissive. External guest access may not expire unless somebody sets it to. Link sharing may be on until turned off. Nothing is hidden, and nobody points at it either.
What do the contract terms say about incidents and exit?
Breach notification should be stated in hours, with a named obligation to notify rather than a promise to act reasonably. Exit terms should cover what format data comes back in, how long the vendor keeps it and what proof of deletion looks like. Both get negotiated at signing and are nearly impossible to add later.
A Purchase-Time Control on a Continuous Problem
Even a rigorous review has a structural limit. It happens once, at purchase, run by IT and procurement. The decisions that create exposure get made every week afterward by project coordinators deciding who to invite to a job and at what permission level.
Those two groups rarely talk. A firm can complete a demanding vendor review and then grant broad access to 14 outside companies over the following month, and nothing in the review would catch it. Vendor diligence and access governance get treated as one subject. They are two, and only the first one has a clear owner at most firms.
For Federal Work, This Stops Being Optional
DFARS clause 252.204-7012 requires any external cloud service used by the contractor which handles covered defense information to meet the FedRAMP Moderate baseline. FedRAMP’s Consolidated Rules for 2026 redesignate that baseline as Class C,. A Defense Department CIO memorandum dated Dec. 21, 2023 set the terms for equivalency: an independent FedRAMP-recognized assessor tests the full baseline and the service must show no open findings, though operational items arising later are treated separately. Cloud services which already carry FedRamp Class C Certification require no additional assessment.
The risk allocation deserves attention from anyone signing software contracts. The obligation sits with the contractor rather than the provider, so a vendor’s shortcomings become the contractor’s compliance problem. And when a cloud incident happens, the contractor carries the reporting duty.
None of this moved when the Department of War suspended CMMC Phase 2 on July 13, 2026. That pause covers third-party certification. Phase 1 self-assessments, the annual affirmation, NIST SP 800-171 Rev. 2 and DFARS 252.204-7012 all continue to apply.
CMMC also happens to be the one regime that addresses multi-party risk directly. Requirements flow down from primes to subcontractors that handle covered information, and the level a sub needs follows the data it touches.
What an Access Audit Turns Up
Firms that inventory external access to a live project tend to find the same things. External accounts outnumber internal ones, often by a wide margin, and nobody has seen the full list in one place. Accounts stay active for jobs that closed years ago. Logins get shared, so the audit trail can’t say who did what. People who changed employers still hold access granted under a previous firm’s invitation. Permission levels sit frozen at kickoff, so a detailer who needed one folder in month two can still see the whole job in year three.
The part that surprises people is that the platform is usually not where data leaked. It left by email, forwarded out of the system by somebody with legitimate access, and no permissions audit will show that.
Two lists close most of the gap. First, every cloud service that currently holds project data, which runs longer than expected once email and file sharing are counted. Second, which of those relationships have a SOC 2 Type II on file, a subprocessor list, and negotiated notification and exit terms. The distance between those two lists is the real security posture.
SEE ALSO: CONNECTED RENTAL TECHNOLOGY IS RESHAPING CONSTRUCTION OPERATIONS
