Sharing, anonymisation and distributed benchmarking
ICMSCosts supports controlled sharing of benchmark data between organisations, regions and servers while helping protect commercially sensitive information.
Shared programme overview
A programme configured for controlled sharing to the benchmark network.
1. Why share benchmark data?
Benchmarking becomes more valuable as the quantity and diversity of comparable projects increases. Many organisations hold useful project information, but may be unable to share full project records because of commercial, contractual, confidentiality or jurisdictional restrictions.
ICMSCosts allows organisations to share structured benchmark information in a controlled way without exposing sensitive project details.
Organisations benefit from a reduction in subscription costs when sharing data. See our pricing information for more details.
Increase benchmark coverage
Access a wider pool of comparable projects across multiple regions and organisations.
Protect sensitive information
Share benchmark evidence without exposing confidential project details.
Support regional data control
Allow data to remain under local ownership while contributing to shared benchmarking.
2. Hub and spoke architecture
ICMSCosts operates using a distributed “hub and spoke” architecture. In this model, organisations or regions may operate their own local servers while still participating in shared benchmarking. We also provide regional servers for organisations that prefer not to host their own server but require data to remain under known jurisdictional control.
The architecture typically consists of:
| Component | Purpose |
|---|---|
| Local server (spoke) | Holds the organisation’s working project data and user activity. |
| Central hub | Receives approved shared benchmark packages and redistributes anonymised benchmark information. |
| Shared packages | Structured benchmark datasets transferred between servers. |
| Sandbox environment | A safe environment used for testing, validation or trial sharing. |
This approach allows organisations to maintain local control of their operational project information while still contributing to a broader benchmarking ecosystem.
Hub and spoke architecture
An example of local servers sharing anonymised benchmark packages through a central hub.
3. Local ownership of project data
In most cases, the original project records remain on the central server. Local users continue to manage, edit and review their projects within their own environment.
Shared benchmarking does not require organisations to expose their full project database to external users, only the costs rolled up to the level the sharing organisation is comfortable with.
4. Anonymisation and data protection
Before project information is shared, it can be anonymised to help remove or reduce commercially sensitive information.
The exact anonymisation approach depends on the organisation’s sharing policy, but may include:
Removing identifying information
- Client names
- Project names
- Addresses
- Contractor details
- Internal references
Sharing structured benchmark data
- Project type
- Location region
- Cost categories
- Area or capacity measures
- Benchmark attributes
This allows shared projects to remain useful for benchmarking while reducing the risk of exposing confidential project information.
Anonymised benchmark data
An example of shared benchmark information after anonymisation has been applied.
5. Programme-level sharing
Sharing is typically managed at programme level. This allows organisations to group related projects together and decide whether that programme should participate in shared benchmarking.
Shared programmes may contain:
- Benchmark projects
- Structured cost breakdowns
- Key project attributes
- Carbon and sustainability metrics
- Lifecycle cost information
- Location and date metadata
Organisations can choose which programmes are shared and which remain private. Shared projects are distributed to other participating servers as shared packages, while private programmes remain under local control.
6. Sandbox environments
Sandbox environments provide a safe area for testing and validation before benchmark data is shared more widely.
Organisations may use sandboxes to:
- Test anonymisation rules
- Validate benchmark quality
- Review shared package contents
- Train users
- Trial integrations
- Experiment with new sharing policies
Sandbox environments can not submit data for wider distribution, but they can be used to validate and review benchmark sharing before publication for individual users. When registering with ICMSCosts, a sandbox environment is created automatically for each user.
Sandbox environment
A sandbox environment used to validate and review benchmark sharing before publication.
7. Shared benchmark packages
Shared information is transferred between servers using structured benchmark packages. These packages contain the approved project and programme information needed for benchmarking and analysis.
Packages can be versioned and updated over time, allowing revised benchmark information to be distributed safely across participating environments.
- An organisation approves a programme for sharing.
- The programme is anonymised according to local policy.
- A benchmark package is generated.
- The package is securely transferred to the hub.
- The hub validates and redistributes the benchmark data.
- Other participating servers ingest the updated benchmark information.
8. Security and validation
Shared benchmark transfers can be validated to help ensure that packages are authentic, complete and approved for distribution.
Validation may include:
- Package integrity checks
- Server authentication
- Version tracking
- Duplicate protection
- Transfer audit logs
These controls help support trusted collaboration between participating organisations and regions.
9. Benefits of distributed benchmarking
Distributed benchmarking allows organisations to participate in wider market analysis without giving up control of their local project environments.
Improved benchmark quality
More comparable projects improve benchmarking confidence and coverage.
Regional flexibility
Different regions or organisations can maintain local governance rules.
Controlled collaboration
Organisations decide what is shared, when it is shared, and with whom.
Recommended approach
- Start with private local project management.
- Define organisational sharing and anonymisation policies.
- Use sandbox environments to test benchmark sharing.
- Enable programme-level sharing where appropriate.
- Review incoming benchmark data before relying on comparisons.
- Expand participation gradually as confidence in the process grows.