You have won a place on a tender, or you are about to, and the information requirements ask you to work to ISO 19650. Somewhere in that document is a line about a common data environment, and the job of meeting it has landed on your desk. This guide explains what the standard actually asks for, what a common data environment has to do to satisfy it, and how to tell a compliant setup from a shared folder with good intentions.
What ISO 19650 Actually Is
ISO 19650 is an information management standard for building and infrastructure work. It sets out how the information about an asset gets produced, checked, approved, and handed over across the whole life of a project and the asset that follows. It does not describe a 3D model, and it does not tell you which software to buy. It describes a process.
The standard grew out of British practice. BS 1192 set the original conventions for collaborative production of information, PAS 1192 extended them for building information modelling, and ISO 19650 took the same ideas international. If you have worked to BS 1192 before, most of ISO 19650 reads as familiar ground with new labels. It is often introduced alongside building information modelling, though the two are not the same thing: BIM is a way of producing and structuring information, and ISO 19650 is the discipline for managing it.
Two roles run through the standard. The appointing party is the client, usually the asset owner, who sets the information requirements and receives the finished record. The appointed parties are the consultants, contractors, and suppliers who produce information against those requirements. Parts 1 and 2 are the ones you will meet most often. Part 1 sets out the concepts and principles, and part 2 covers the delivery phase of an asset, which is where most tenders sit.
If you already run a drawing management system, the move to a common data environment is more of a step than a leap, because you have the naming and revision discipline in place. What changes is the formality around it: the states, the gates, and the requirements the appointing party sets at the start. Our guide to transitioning to BIM within a CDE walks through that path from the appointing party's side.
What ISO 19650 Asks of a Common Data Environment
At the centre of the standard sits the common data environment. ISO 19650-1 describes it as
an agreed source of information for any given project or asset, for collecting, managing and disseminating each information container through a managed process.
Read that definition slowly, because every phrase in it is a requirement. An agreed source means one place that everyone accepts as authoritative. A managed process means information moves under rules, not by drag and drop. The rest of this section unpacks what those rules are.
Information Containers, Named and Coded
An information container is any structured set of information: a drawing, a model, a document, a spreadsheet, or a report. ISO 19650 treats the container as the unit that gets managed, and it asks that every container carry enough metadata to be found, trusted, and placed in context.
Three pieces of metadata do most of the work. A consistent naming convention gives each container a predictable identifier, so people and systems can locate it. A revision code records which iteration you are looking at, so nobody works from a superseded version. A status code, sometimes called a suitability code, records what the container may be used for, for information, for review, for coordination, or for construction. Get these three right and most of the standard follows.
The Four States
ISO 19650 moves every information container through four states, and the discipline of the standard is really the discipline of the transitions between them.
Work in progress holds information that a single task team is still developing. It is private to that team, and nobody outside relies on it.
Shared holds information that a team has checked and released for others to see and use, but that carries no formal approval yet. Coordination between disciplines happens here.
Published holds information that has been reviewed and authorised for a defined purpose, tender, construction, or handover. This is the record other parties commit decisions to.
Archived holds superseded and historical containers, kept as a record of what was issued and when.
The states matter less than the gates between them. A container does not drift from work in progress to shared: a check moves it there. It does not appear as published because someone renamed a folder: a review and an approval authorise it. Each transition is a decision with a name against it, and the standard expects that decision to be recorded. For a worked example of a review and approval sequence, see understanding document workflow.
Audit Trail and Controlled Access
Two more requirements sit underneath the states. The first is an audit trail. Because each container carries a history of who changed it, who reviewed it, and when it moved state, you can reconstruct the record months or years later. That history is what turns a claim of compliance into something you can demonstrate, whether the question comes from an auditor, a dispute, or the next project team inheriting the asset. The second is controlled access. Appointed parties see the containers their role requires and no more, and information leaves the environment to external parties through a controlled issue rather than an open link.
Workflow Versus Solution
ISO 19650 talks about a CDE workflow and a CDE solution, and the difference is the thing most tender responses get wrong. The workflow is the process: the states, the gates, the naming, the status codes, and the audit trail. The solution is the platform you run that process on.
You can buy a solution and still fail the workflow. A shared folder with good intentions, a tidy naming convention, and a well-meant email rule looks organised, but it cannot enforce a state transition, it cannot stop someone editing a published container, and it keeps no reliable record of who approved what. The moment two people copy the same file to their desktops, the agreed single source is gone. The standard asks for a managed process, and a folder manages nothing on its own.
A compliant common data environment is a solution that carries the workflow inside it, so the process holds even when people are busy. Modelling those state transitions is exactly what a configurable workflow is for.
What This Looks Like Day to Day
Set the standard aside for a moment and picture the week.
You book a document in. It arrives with a name that follows the convention, a revision, and a status code, and it lands in work in progress under the team that owns it. When that team has checked it, they move it to shared, and the coordinating disciplines pick it up. A reviewer reads it against the requirements, and if it passes, an approver authorises it and it becomes published. If it fails, it goes back with a comment, and the revision increments when it returns.
When information has to go to a party outside the environment, a subcontractor pricing a package, or a consultant who is not yet on the project, you issue it as a transmittal: a controlled package with a cover sheet, a recipient, a reason, and a record of what was sent and when. The recipient does not need standing access to the repository to receive it.
At project close, the published information becomes the handover record. The handover is validated against the requirements, checked for completeness, and issued to the appointing party. The project information model becomes the asset information model, and the asset owner keeps it.
That last step is the one teams forget. ISO 19650 does not end at practical completion. The owner has to hold the record for the life of the asset, ready for the next project, the next audit, or the next tender. If the record lives only in a contractor's system, the owner does not really have it. For more on how that record keeps developing after handover, see how the common data environment evolves.
Where Lunr Fits
Lunr supports an ISO 19650 information workflow. It is not certified as anything, and no software can make you compliant on its own, because compliance is a property of how you work. What a platform can do is carry the workflow so the discipline holds. Here is where Lunr lines up with the requirements above.
Configurable workflows model the state transitions directly. You define the states your project uses, the reviews and approvals that move a container between them, and the roles that can act at each gate, so work in progress, shared, and published mean the same thing to everyone.
Transmittals and collaborator access handle the appointed parties. Issue a controlled package to an external party without granting repository access, or invite a party into a project workspace with the access their role requires. Every issue is recorded.
Revision control, status metadata, and a full audit trail come as standard. Every container carries its revision, its status, and its history, and the record of who changed and approved what is kept automatically.
The owner keeps the record after handover. Because the environment belongs to the appointing party, the published information stays with the asset owner when the project team leaves, ready for the next appointment. Lunr already holds more than 10 million documents under management, and the University of Canberra moved more than 20,000 documents off SharePoint into a single managed record.
A Checklist to Take to Procurement
When you assess a common data environment against ISO 19650, take these questions with you:
- Does it model the four states, and does it enforce the gates between them, or does it only label folders?
- Can a review and an approval move a container between states, with the decision and the reviewer recorded?
- Does every container carry a naming convention, a revision code, and a status code as first-class metadata?
- Is there a complete audit trail for every container, covering changes, reviews, and state transitions?
- Can you issue information to external parties as a controlled transmittal without opening the whole repository?
- Can you control access so appointed parties see only what their role requires?
- Can you validate a handover package against the information requirements before you issue it?
- After handover, does the record stay with you, the asset owner, rather than the contractor?
- Is the platform hosted where your data has to live, and does it support single sign-on for the people who use it?
Score a platform against those nine questions and you will know quickly whether it carries the ISO 19650 workflow or just stores your files. To see how Lunr answers them, book a demo.