Data governance policy for engineering firms

What should an engineering firm's data governance policy cover?#

An engineering firm's data governance policy should cover classification, ownership, access, retention and external use approvals, written plainly enough that project managers can apply it without help. Most firms already make these decisions informally; the policy makes them consistent across offices, disciplines and project teams.

Keep the governance policy separate from the AI use policy but linked to it. The AI policy tells staff which tools they may use; the governance policy tells them which records may go into those tools and who decides.

• 1Classification: which categories exist and how records are labeled.
• 2Ownership and stewardship: who decides for each record set and who maintains it.
• 3Access: who can see what, and how access changes when people join, move or leave.
• 4Retention and disposal: how long records are kept, how legal holds work and how systems are retired.
• 5External use: how any use outside the firm, including AI tools and data licensing, is approved and recorded.

An AEC data classification table#

An AEC classification works best when it combines sensitivity with control, because the firm's freedom to use a record depends on who controls it as much as on how sensitive it is. A boring log the firm paid for and a boring log in a client's commissioned report may look identical but sit in different classes.

Label at the project or folder level where possible. Asking staff to label individual files rarely survives the first deadline.

Who owns which records?#

Ownership in a governance policy means decision rights, not copyright: the owner decides who gets access, how long records are kept and whether an external use is approved. A steward maintains the records day to day and flags problems to the owner.

Naming owners by role rather than by person keeps the policy valid when people change jobs, which in a growing firm happens constantly.

Access and retention rules#

Access rules should follow projects: staff see the projects they work on plus firm-internal standards, and lose access when they leave a project or the firm. Shared folders for consultants and contractors need an end date, and a regular review of who still has access catches what offboarding misses.

Retention is harder because several obligations overlap. Contracts may set record-keeping periods, professional liability insurers and counsel will have views on how long to keep project files given statutes of repose in the states where the firm works, and public clients often impose their own rules. Set retention by record class with counsel, and apply legal holds as soon as a claim or dispute looks possible.

Add one rule firms often miss: before retiring any system, export its history in a usable format and record what was kept. Old ERP, document management and markup archives are lost more often in migrations than through deliberate disposal.

How should external use be approved?#

External use should be approved by the owner of the record set, with a written record of what leaves the firm, the rights basis and the purpose. The same path applies to uploading records into an outside AI tool, sharing data with a research partner and licensing de-identified records to an AI developer.

Public standards can shape that record. The Use group in the Data & Trust Alliance's Data Provenance Standards has fields for a dataset's confidentiality class, where its consent records are kept, the license that permits use, the intended use and its copyright status, which line up closely with the approval fields below.

• 1Describe the records: class, systems, projects and date range.
• 2Confirm the rights: contracts, client consent where required and any carve-outs.
• 3Describe the preparation: what was stripped out, such as names, sites and client identifiers, and how the result was checked.
• 4State the purpose and limits: permitted use, term and who receives the records.
• 5Record the approval: who approved, when and under which version of the policy.

Illustrative: a multi-office firm writes its first policy#

Illustrative: a fictional civil and geotechnical engineering firm of about 260 people across four offices finds that each office stores boring logs, lab results and project correspondence differently, and that nobody can say who approves sharing records outside the firm. A university research group has asked for historical boring logs, and staff are already using AI tools to draft reports.

The COO drafts a policy with the five parts above, names the controller as owner of Vantagepoint data and each principal in charge as owner of project records, and classifies client-commissioned reports as client confidential. The university request goes through the new approval path; counsel finds that most reports belong to clients under the firm's agreements, so only records from firm-funded internal testing are shared.

The outcome is slower at first and faster afterward. Later requests, including a metadata-only assessment of whether QA and RFI records could be licensed, follow the same path and are settled by the named owner instead of by debate between offices.

How SourceX works with a firm's governance policy#

SourceX works inside a firm's governance policy rather than around it. The SourceX five-step transaction maps onto the external use approval: Supply describes the records from metadata, Rights confirms the contract basis, Preparation removes personal and confidential details, Approval is the record owner's sign-off, and Delivery happens only after it.

The SourceX Evidence Packet stores the same facts the policy asks for, including provenance, licensing rights, permitted use, the privacy record and release authorization, so the firm's governance file and the license record agree with each other.