Data Security and Compliance for Construction Software

Data security and compliance for construction software means protecting drawings, BIM models, contracts, commercial data, workforce information and asset records from unauthorised access, alteration, loss or destruction, while demonstrating alignment with applicable laws, standards, contracts and internal policies. In practice, that requires more than selecting a vendor with a SOC 2 report or ISO 27001 certificate: the common data environment (CDE), permissions, workflows, integrations, users and project closeout process must also be governed and evidenced.

What Data Security And Compliance For Construction Software Means in Practice

Data security covers the technical and organisational safeguards applied throughout the project lifecycle. For a construction owner, this includes who can view a tender, download a design model, approve an RFI, change a contract record or retain access to as-built information after handover.

Compliance is the demonstrable connection between those safeguards and an obligation. The obligation may come from GDPR, US state privacy laws, a public-sector security baseline, an owner–contractor agreement, ISO 19650 information-management requirements or the organisation’s own retention and access policies.

Construction creates a particular governance problem because one CDE may be accessed by owners, developers, PMCs, designers, general contractors, subcontractors, regulators and suppliers. The data is also unusually varied: worker and subcontractor PII, BIM files, tender pricing, contracts, site photographs, safety information and critical asset data may sit within connected workflows. ISO 19650-1:2018 and ISO 19650-2:2018 explicitly address information management and information security around BIM-enabled environments; PAS 1192-5 and related UK guidance describe security-minded BIM practices such as role-based access and information classification.

SOC 2 and ISO 27001 are useful evidence, but they are not interchangeable labels or guarantees of perfect security. SOC 2 is an AICPA attestation report against Trust Services Criteria covering Security, Availability, Processing Integrity, Confidentiality and Privacy. Type I considers control design at a point in time; Type II considers design and operating effectiveness over a minimum of six months. ISO/IEC 27001:2022 is an international standard for an information security management system (ISMS), with 93 Annex A controls across organisational, people, physical and technological themes. Certification is performed by an accredited third party, with surveillance audits typically annual and recertification typically every three years.

The practical question is therefore not “Does the platform have a badge?” It is “Does the evidence cover the service we will use, and can our project configuration demonstrate that contractual and regulatory controls operated as intended?”

Why This Matters for Compliance Officers & Legal/Governance Leads

Construction is a material cyber-risk environment. Check Point Research reported construction as the most heavily attacked industry in the second half of 2023, with organisations facing an average of 2,507 attacks per week, up 31% year on year. Kroll’s 2022/23 construction analysis reported that 73% of surveyed construction organisations experienced a cyber incident in the previous 24 months and 30% reported ransomware. These figures are sector-level findings, not a breach rate for construction software, but they establish why project data cannot be treated as an administrative concern.

The UK National Cyber Security Centre identifies design and intellectual-property theft, tender manipulation and disruption to project schedules as construction-sector risks. A ransomware event affecting drawings, schedules, RFIs or submittals can become a programme-control issue. For critical infrastructure, as-built information and asset data may also carry safety or national-security implications.

Regulatory exposure is equally specific. GDPR applies when personal data relating to EU or EEA residents is processed, including information about employees, subcontractors or occupants in connected building systems. Under Articles 83(4–5) of the consolidated 2023 text, maximum administrative fines can reach €20 million or 4% of global annual turnover, whichever is higher. The IAPP’s tracker, updated in 2024, recorded at least 19 US states with comprehensive privacy laws. The applicable duty depends on the organisation, individuals, data and jurisdiction; legal review remains necessary.

Contracts create a second control layer. FIDIC, NEC, bespoke EPC/EPCM and other agreements may define the information manager, CDE manager, document ownership, approval status and permitted access. A configuration that lets a subcontractor download or edit information beyond the agreed role can create a contract-versus-configuration mismatch. It may also make it harder to establish which drawing was authoritative, who saw it and when in a dispute.

Evidence matters. Compliance and legal teams should be able to retrieve an access record, approval history, version history and relevant notification record without reconstructing events from email, local drives and disconnected tools. The control objective is not merely prevention; it is defensible governance.

The Traditional/Manual Approach — and Where It Breaks Down

Many organisations begin with a procurement questionnaire, a vendor security review and a policy stored as a PDF. Project teams then combine email, network drives, generic file-sharing services, spreadsheets, BIM tools, ERP systems, safety applications and messaging. Each tool has different authentication, permissions, retention defaults and audit capabilities.

Access is often provisioned manually for each project. A PM or administrator adds a consultant, supplier or site user, while another person later removes access when that individual changes role or leaves. Shared accounts may appear convenient for site teams, but they weaken attribution. Logs remain in separate systems, so an investigation requires matching usernames, timestamps and exported files across multiple sources.

Human error is a measurable weakness: Verizon’s 2023 Data Breach Investigations Report found that 74% of breaches involved the human element, including social engineering, privilege misuse or error. ENISA’s 2023 threat landscape and IBM’s 2023 breach report identify cloud misconfiguration as a significant exposure risk. Gartner has estimated that by 2027, 75% of employees will acquire, modify or create technology outside IT’s visibility, increasing the likelihood of shadow IT.

The failure is often operational rather than intentional. A field policy assumes continuous connectivity and desktop access, so teams send photographs through an unsanctioned channel. A tender folder grants broad download rights because the permission matrix was never updated. A project closes, but supplier accounts remain active and copies of as-built files sit in personal drives or unmanaged cloud storage.

Closeout deserves its own control. During handover, teams are exporting O&M information, models and asset records while licences expire and project participants change. A closeout playbook should revoke third-party access, confirm approved exports, document retention and destruction, and preserve chain-of-custody evidence for critical digital deliverables. Without that sequence, the highest-volume transfer point in the project can also become the least-governed.

Step-by-Step Framework

Step 1 — Assess current state

Start with a data and system inventory, not a software shortlist. List the CDE, BIM coordination tools, ERP and procurement systems, HR or payroll integrations, HSE tools, drone and timekeeping applications, personal-device workflows and temporary file-sharing channels. For each system, record the data categories it handles: PII, commercial confidentiality, design and IP, safety-critical information, financial data and regulated information.

Build a data-flow diagram for at least one representative project. Record where data enters, who can access it, where it is stored, which systems receive exports and what happens at closeout. Then document authentication, authorisation, SSO, MFA, RBAC, encryption in transit and at rest, logging, backup and disaster recovery, data residency, retention and vendor assurance evidence.

Use ISO 27001 risk-assessment principles and the NIST Cybersecurity Framework’s Identify, Protect, Detect, Respond and Recover structure to organise the review. The outputs should be a project data-flow diagram and a risk register with owners, affected obligations, current controls, gaps and treatment dates.

Step 2 — Define standards, templates & governance

Translate the assessment into a minimum control baseline. Depending on the project and jurisdiction, this may include SOC 2 Type II or ISO 27001 evidence, SSO, MFA, role-based permissions, exportable audit logs, defined retention and deletion, data-residency requirements, incident-notification terms and subprocessor controls. Public-sector and defence-linked work may also require NIST SP 800-171, CMMC or FedRAMP-related requirements; the applicable contract determines the threshold.

Create a SaaS security addendum covering data ownership, breach notification, audit rights, subprocessors, retention, deletion, business continuity and AI data use. Pair it with a due-diligence questionnaire aligned where useful to SIG or CAIQ, but include construction scenarios such as multi-party CDE access, bidder information barriers and project closeout.

Build a permission matrix before configuring the platform. Define owner, PMC, project manager, designer, contractor, subcontractor, supplier and regulator roles. Map each role to view, edit, upload, download, export and approval rights by data type or module. Assign a project information security or compliance lead for major programmes and document who approves tools, CDE configuration, exceptions and offboarding.

Step 3 — Select & implement supporting technology

Assess the scope of each vendor’s evidence. Confirm whether a SOC 2 report is Type I or Type II, the period covered, the services included and any complementary customer controls. For ISO 27001, verify whether the certificate covers the service, locations and relevant ISMS scope, and whether it refers to ISO/IEC 27001:2022 or an earlier version.

For the platform itself, test whether permissions support multiple organisations and project roles; whether SSO through SAML or OIDC, MFA and SCIM provisioning can connect to the organisation’s identity provider; and whether logs can be searched by user, document, action and time and exported for investigation or SIEM use. Review encryption, regional hosting, backup arrangements and stated recovery objectives against the project’s requirements.

Do not assess the flagship CDE in isolation. Map the controls of connected procurement, financial, BIM, safety and workforce systems. Run a pilot on one project using the intended permission matrix, approval workflow, retention settings and closeout process. The pilot should test a real onboarding, a role change, an access revocation, a high-volume export and an audit-record retrieval.

Step 4 — Roll out, train and monitor adoption

Turn the governance model into configuration runbooks. The runbooks should cover project creation, default roles, onboarding of organisations, approval routes, naming conventions, retention rules, incident escalation and project closeout. Version-control the runbooks so a change to the contract or information-management plan produces a corresponding configuration review.

Training should be role-specific. Project managers need to understand permissions, approvals and exceptions. Site staff and subcontractors need practical guidance on secure uploads, approved channels and phishing. Administrators need procedures for identity, logging, incident response and deprovisioning. If the approved workflow cannot support field conditions, teams will create an unofficial one.

Monitor signals that indicate control drift: unusual download or export activity, new administrator accounts, logins from unexpected locations or devices, permission changes and activity by users assigned to closed packages. Review a sample of active projects quarterly for least-privilege access and sample closed accounts to verify timely revocation. Keep the review tied to named owners and closure dates.

Step 5 — Measure impact against baseline KPIs

Security and compliance belong in the project risk register and governance pack, not only in an IT dashboard. Establish a baseline before rollout and compare the same measures after implementation.

ISO 27004 provides guidance for information-security measurement, while NIST CSF provides a useful structure for organising control outcomes. The exact targets should reflect risk appetite, contract requirements and project type. A KPI without an accountable owner and review frequency is reporting, not control.

Common Mistakes to Avoid

• Treating certification as a tick-box. Review scope, dates, service coverage and customer responsibilities. A vendor’s attestation does not remove the customer’s responsibility for identity, permissions and configuration.
• Ignoring contract-to-configuration alignment. Compare the CDE permission matrix, document-status workflow and retention settings with the information-management and confidentiality clauses.
• Overlooking smaller tools. A temporary file-sharing service or site application may still process PII, tender data or design information. Include it in the data-flow map.
• Allowing access to decay. Tie account revocation to package completion, role changes and project closeout rather than relying on someone to remember.
• Designing for an ideal site. Test low-connectivity, mobile and subcontractor workflows. Controls that cannot be followed in the field tend to create shadow processes.
• Turning on AI without governance. Ask where prompts and outputs are processed, whether customer data is used to train shared models, how tenant isolation works, what data minimisation applies and how outputs are logged. Consequential decisions should remain subject to human review.

How AI-Native Platforms Like Zepth Change This Workflow

An AI-native platform changes the workflow when intelligence is part of the common data environment rather than a separate analysis layer. The value is not an assumption that AI makes a platform compliant. The value is that a governed project record can provide a more consistent context for controls, reviews and investigations.

Zepth Core is designed as a unified project record across documents, quality and safety, site operations, project controls and risk management. For an owner or PMC, keeping these project workflows connected can reduce the number of places where an RFI, submittal, drawing reference or risk record is separately copied and governed. The organisation must still configure roles, retention, approvals and integrations against its own obligations.

Zepth AI operates as the intelligence layer across Zepth Core, Zepth Vector and Zepth Edge. Its documented workflow capabilities include reviewing submittals and RFIs against drawings and specifications with a confidence score, drafting RFI responses with cited references, comparing tender bids line by line, three-way-matching invoices before payment and flagging risk early. A human is required to sign off on consequential actions. For compliance teams, that human sign-off is a governance point: the organisation can define who reviews an AI-supported finding or draft before it affects a contractual, financial or project decision.

The same principle extends to procurement and asset information. Zepth Vector covers tendering, three-way matching, contracts and vendors, while Zepth Edge covers CapEx, budgets and MIS reporting. Bringing procurement and financial records into the governed project and asset context can help an owner assess where vendor, contract and cost information is being used, rather than reviewing only the flagship document system.

Before procurement, legal and security stakeholders should validate the platform’s current security documentation directly. Confirm the available identity controls, role model, audit-log export, data residency, encryption, retention, subprocessors and AI data-use terms. The research dossier does not establish Zepth SOC 2 or ISO 27001 status, specific tenant-isolation arrangements or particular AI-training controls, so those items should be treated as due-diligence questions rather than assumed capabilities.

A practical AI-native operating model has five characteristics: one governed project record; standard permission and approval templates; AI-assisted classification and review with traceable references; searchable records for audits and investigations; and human approval for consequential outcomes. It complements, rather than replaces, the ISMS, privacy programme, contract controls and vendor oversight.

For the owner-side team, the test is operational: can you show which project data exists, who can access it, what changed, which control applied, who approved the outcome and what happened at closeout? If the answer still depends on assembling spreadsheets and inboxes, the governance model has not yet reached the project workflow.

Subscribe to Zepth Insights and download the related data-security framework and checklist to structure your assessment. When you are ready to review how a unified project record could fit your governance model, schedule a walkthrough.

FAQ