Department for Business, Energy and Industrial Strategy

Open Regulation Platform Project – Beta

16 Incomplete applications

11 SME, 5 large

1 Completed application

1 SME, 0 large

Important dates

Thursday 16 June 2022
Deadline for asking questions
Thursday 23 June 2022 at 11:59pm GMT
Closing date for applications
Thursday 30 June 2022 at 11:59pm GMT


Off-payroll (IR35) determination
Contracted out service: the off-payroll rules do not apply
Summary of the work
We are seeking a partner supplier for the Beta phase of this project to create a step change in how Government publishes information on UK regulation, to help improve understanding of the regulatory environment and enable a new era of RegTech tools and services to develop across the whole economy.
Latest start date
Monday 22 August 2022
Expected contract length
Incl. break clause: Private Beta 8 months (by end March 2023); Public Beta 3-4 months
No specific location, for example they can work remotely
Organisation the work is for
Department for Business, Energy and Industrial Strategy
Budget range
We have funding for supplier support up to £1.1m (inc. VAT) for private Beta development until March 2023 to build this platform.
We expect this to cover service and UX design, development, user research, data architecture, data science support, domain and project management support
You should provide a full breakdown of the costs for private beta, including personnel day rates. The breakdown of cost should be by role and seniority.

About the work

Why the work is being done
The UK regulatory landscape is complex and difficult to navigate. As a result, businesses have to spend a lot of resource identifying which regulations they are expected to comply with. This is before they start to understand what they have to do to comply. Our present estimates from BEIS’s Business Perception Survey 2020 suggest that businesses spend, on average, around eight staff days per month complying with regulation. Economic analysis suggests that the ORP could create benefits to the UK economy of up to £500m, largely through reducing information search costs.

The Open Regulation Platform (ORP) aims to improve the regulatory environment by curating publicly available data about the UK regulatory landscape. By making relevant standardised data on regulation available, for example by making it machine readable, we expect the ORP to enable a new market of regulation technologies to develop at lower cost. This in turn should improve the products and services business have access to, which support cheaper and more effective compliance processes.

Further information on our problem statement and BRE’s thinking to date on a reasonable approach can be found in the Beta supplementary information pack.
Problem to be solved
This project aims to make UK regulatory data available that will support RegTech tools and services to develop reducing the cost of navigating a complex regulatory environment for UK businesses.
Currently, The National Archives already publishes all primary legislation and some secondary legislation (see There is not, however, a similar source of data on UK regulatory information in a format that is machine-readable (and therefore will be structured in a standardised way). UK regulation is published across multiple web locations and is published in multiple formats.
This project aims to curate a useful data source on UK regulation to improve understanding of the regulatory environment for a variety of interested stakeholders. To start development of this product, we will focus on balancing the requirements of two key primary users:
• The first primary user is the publishing authority; the regulator, regulating authority or publishing platform, for example many regulators publish on and;
• the RegTech community.
At this stage we want to improve our User Research on this problem and develop an MVP to demonstrate the value of the project and improve understanding of the challenges.
Further information on this can be found in the supplementary information pack.
Who the users are and what they need to do
The two primary users for the ORP project are the data providers (regulators), and the data users, (third party RegTech developers) that will develop RegTech tools and services from this data or improve existing services at lower cost. Further information on these user personas can be found in the supplementary information pack.
In the long-term we are interested in providing data that will ultimately serve all stakeholders interested in regulatory information such as legal & regulatory advisors, academics, businesses, consultancies. However, at this stage in the project we will prioritise meeting the needs of the RegTech Developers which should reflect business demand and interest.
The priority user needs are:
1. As a RegTech Software Developer, I need to have access to regulatory data in a standardised format, so I can create bespoke digital products that help business to support compliance and regulatory processes.
2. As a Regulator, I want the ability to navigate regulations and help improve business and citizen experience with the regulatory landscape.
Early market engagement
Prior to the publication of this tender, we conducted a market engagement exercise. We invited suppliers for their feedback on our scope and requirements, while sharing our latest thinking and publishing documents from previous phases The documents used and distributed during this exercise are available upon request at, and include:
- Discovery report
- Alpha summary slidepack
- Alpha UR report
- Early-market engagement info session slidepack
- Beta supplementary information slidepack – this document details primary user personas and BRE’s thinking on an MVP.
The results of this engagement have informed changes to our scope , including:
- A greater emphasis on user research to ensure primary user persona needs are fully realised – this has now become a workstream .
- Re-configuration of the scope to better accommodate ‘start small, build up’ approach.
- Precise, strategic targeting of up to three sectors to test the ORP over the private Beta.
We have increased the upper limit to the proposal word count, so shortlisted suppliers can better provide technical and strategic detail on their approach. In addition, time allocated to suppliers to complete their proposals has been increased.
Any work that’s already been done
The ORP Discovery showed that there was a clear user need for the ORP and ORP Alpha work demonstrated that the concept is technically deliverable.
A separate economic analysis BRE conducted alongside the Discovery estimated economic benefits of the ORP of around £400m over the next 10 years.
This project is also related to BEIS’s Digital Regulation Navigator project aimed at making it easier for businesses to navigate the regulatory landscape. We would expect any supplier to be able to consider future interaction between the ORP and this product.
Existing team
The successful bidder will be working with an internal BEIS team of civil servants:
• The senior responsible owner (SRO) for the project
• A service owner
• A policy project lead /product manager
• A senior digital delivery manager
• An economist analytical lead
• A technical architect
• Supporting officers
We have connections with regulators and other subject matter specialists. We receive policy support from other government departments and public bodies which we can use for advice where necessary. We also have a network of experts through which we can test ideas and approaches.
Current phase

Work setup

Address where the work will take place
We expect the supplier to follow BEIS’ hybrid model of working – a balance of remote and office working. This is dependent on the relevant COVID-19 restrictions at the time, though we hope to conduct certain meetings at our central London office, 1 Victoria Street SW1H 0ET. Potentially members of the BEIS team could co-locate with the supplier’s team for the kick-off process, and on an ongoing basis for face-to-face meetings such as show and tells, key decision points, and quality assurance.
Working arrangements
The supplier should collaborate with the BEIS team, continuously sharing information, agreeing structures and processes at the start of the project with the BEIS Delivery Manager. This includes daily stand-ups, sprint planning, show-and-tell presentations at key milestones, and presenting at internal assurance processes (including Government Digital Service governance process).
Plans should consider the context of hybrid working. BEIS uses the Microsoft suite including Microsoft Teams for instant messaging and virtual meetings. Additional meeting/collaboration tools should be accessible without requiring custom software. Suppliers may need to occasionally travel to the 1 Victoria Street London office. Travel expenses will not be reimbursed.
Security clearance
All government contractors must have a valid Baseline Personnel Security Standard (‘BPSS’) check, and all personnel working on the project have passed by the intended start date.
The BPSS comprises verification of:
• Identity
• Nationality and Immigration Status
• Employment history (past 3years)
• Criminal record (unspent convictions only)

Additional information

Additional terms and conditions

Skills and experience

Buyers will use the essential and nice-to-have skills and experience to help them evaluate suppliers’ technical competence.

Essential skills and experience
  • Demonstrate knowledge and experience of data integration, including developing and designing a common data-model bringing multiple different datasets into a standardised, connected, shared format. (5 points/2.5%)
  • Demonstrate skills in making disparate diverse datasets connected in a navigable and organised format (taxonomies and ontologies). (5 points/2.5%)
  • Demonstrate expertise in open access software design and practices (for example APIs). (5 points/2.5%)
  • Demonstrate experience designing and building data infrastructure, tools and services to meet user needs of varying complexity. (5 points/2.5%)
  • Demonstrate experience of community-building around a project, capability to maintain a constant feedback loop between user needs and product development to support iterative design changes. (5 points/2.5%)
  • Demonstrate skills, strategic understanding and implications of data governance. (5 points/2.5%)
Nice-to-have skills and experience
  • Demonstrate experience of working within business regulation, RegTech, LegalTech, or ‘legislation as data’ as a topic. (4 points/2%)
  • Demonstrate experience working on and promoting open data and open source projects (3 points/1.5%)
  • Demonstrate experience working to the Service Standard overseen by Government’s Central Digital and Data Office and delivering a Beta phase. (3 points/1.5%)

How suppliers will be evaluated

All suppliers will be asked to provide a written proposal.

How many suppliers to evaluate
Proposal criteria
  • Detail how user research and engagement approach will provide full comprehension of challenges and opportunities of the project. Outline overall strategy, key deliverable, and methods of engagement. (15 points/7.5%)
  • Detail considerations and approach to building an MVP for Curating the ORP dataset – e.g. generating ORP mark-up language, enriching data, and making overall data navigable (15 points/7.5%)
  • Detail considerations and approach to building an MVP by Codesigning management and Engagement – e.g. engaging regulators and developers, and management and recruitment of beta testers. (15 points /7.5%)
  • Detail considerations and approach to building the ORP MVP data infrastructure – e.g. building a cloud hosted repository, ingestion pipeline, API and other relevant tools supporting publishing. (15 points /7.5%)
  • Demonstrate an understanding of how your proposal will contribute to achieving the long-term scalability of the ORP and achieving the ORP strategic goals. (12 points/6%)
  • Detail the team structure, technical skills and experience to deliver on project goals in a project plan. Provide estimated role allocations, experience/seniority and time commitment detail (16 points/8%)
  • Detail key risks and approaches for mitigating against them. (12 points/6%)
Cultural fit criteria
  • Proposal demonstrates a transparent and collaborative working style, taking into account the varying level of digital literacy across both the public and private sector. (4 points/2%)
  • Proposal ensures effective knowledge transfer to the BEIS BRE team, allowing setting direction at key decision points, facilitating effective quality control of work and risk escalation procedures (4 points/2%)
  • 3. Proposal involves taking an effective agile, user-driven approach, using research and evidence to challenge underlying assumptions and making design changes based on evolving user and business needs. (3 points/1.5%)
  • Describe how your organisation will use this contract to create opportunities for entrepreneurship and help new organisations to grow, supporting economic growth and business creation. (3 points/1.5%)
  • Describe the actions your organisation will take to identify and tackle inequality in employment, skills and pay in the contract. (3 points/1.5%)
  • Describe organisational strategy supporting in-work progression to help people, including disadvantaged/minority groups, move into higher paid work by developing new skills relevant to the contract. (3 points/1.5%)
Payment approach
Fixed price
Additional assessment methods
Evaluation weighting

Technical competence


Cultural fit




Questions asked by suppliers

1. How do I get the supplementary information pack?
Please email and you will receive the aforementioned documents
2. I have pre-existing technology that I believe is appropriate for this project - how will this be considered?
Please refer to the supplementary information pack (which can be requested at

You will need to demonstrate how this pre-existing technology/product will be used or adapted to meet the open-source requirements of this project
3. We are one of two companies that plan to jointly respond to this requirement. Is it acceptable for one of these companies to take the lead and respond jointly on behalf of both?
Yes, if you represent both organisations appropriately. Both organisations must be a registered supplier on the platform.
4. Who is the incumbent?
There is no incumbent, but the previous supplier was analytic engines for alpha.
The Alpha phase finished in January 2022. Details about the Alpha supplier can be found here:
5. How do you want us to provide the rate cards for the roles you are looking for this BETA phase?
Short-listed suppliers will be asked to present a technical proposal, including a project plan. The project plan would be the place to provide rate cards.
6. Whilst we appreciate this is a Beta service, your questions are focused around ORP for the stage 2 proposal. What’s the feasibility of suppliers suggesting a different architecture in terms of consideration?
We remain open to supplier suggestions on technology stack, as long as they meet user needs and keep on track with project timelines. However, we would require the build to be fully open source. We would additionally expect that the final build would be deployed and hosted (preferably via infrastructure as code) onto BEIS internal cloud services and to do so using best practice methodology. BEIS have both Azure and AWS services and we’re open to the supplier’s preference.
7. How many use cases there are? Is there an area where you see those use cases coming from. Is there anything that you steering towards yourselves?
Our plan is to have three use cases, with two primary users. It's about demonstrating the value of the data set and the minimum of three use cases is because we think that there are many ways that one would be able to use this data and improve decision making.

Some examples we have considered:
1) Allowing regulators to see how their content is linked to others, potentially showing conflicts or requirements to update.
2) Providing data sources to help RegTech companies quickly develop or scale up tools and services.
3) Provide notifications to users indicating the regulation has changed.
8. How does curation of data set relate to technology infrastructure? Is there a dependency between the first and the second workstream?
There is a dependency between the two workstreams We expect the c uration of data and technology infrastructure to be developed side by side and tested with users. For example, we expect there might be overlap in the generation of ORPML and the data ingestion process.
9. Is primarily API driven or are we looking something on top of the API? Or is this something we should be discussing as part of the project?
The primary output of the ORP is the API and the primary purpose of the Beta is to build this API and showcase its value. We have other projects (such as the Digital Regulation Navigator) that will focus on building anything from the API.

As part of the proposal stage, we’d also be interested in hearing what your approach might be.
10. Have you had any thoughts on a more batch download mechanism?
Our user research suggests that the best way to provide the ORP data is through the creation of the API. We think that a batch download mechanism might provide value, but currently do not see it as the main priority – unless further user research would indicate as such.
11. Have you given any consideration between the difference between say open source and open data whereby the data is going to be open and there's no cost for the APIs in the usage of that data?
We’re aware of this distinction – our view is that open data is non-negotiatiable, while we have a very strong preference towards open source for the following reasons:

1) There’s strong government impetus behind open-source projects, backed by the CDDO in the Technology Code of Practice.
2) Open-source projects encourage innovation and government transparency, which strongly aligns with the strategic objectives of the ORP.
3) We are trying to introduce new processes and infrastructures for regulators, and we think that the ORP will be less successful if we attach a heavy commercial bill to this engagement.
12. Would there be any regulatory frameworks that we need to stick to / is there any kind of restrictions on what the data and how it on the data and how it can be used?
No, all the data has already been published by the regulators. We are working directly with the regulators and will be able to clarify any restrictions right away.
13. Considering this question ‘Demonstrate experience designing and building data infrastructure, tools and services to meet user needs of varying complexity’. Please can you elaborate, if it is the complexity of user needs from an accessibility perspective or complexity of needs from an exploitation of the data perspective?
For the purpose of the sifting phase, both kinds of complexity would be considered as they both involving understanding user needs and iterating the service.

Saying that, the ORP is primarily focused on complexity of needs from an exploitation of the data perspective.

We expect there to be multiple kinds of users (Regulators, Software Developers) for the ORP, each with very different user needs. The complexity here involves understanding the nuances and delivering data services that respond appropriately.
14. Can you please clarify what is meant by data infrastructure in this context -“user needs of varying complexity”?
We expect that certain features (e.g., a notification system for the API) might require certain kinds of data infrastructure and architecture.

We are looking for suppliers who can flex how they build their data services in accordance to varying and complex user needs.
15. CDDO guidance[When code should be open or closed] on open source code states that for databases, the schemas used should be open source. Is it correct to infer from this that it is acceptable to use a proprietary database such as Microsoft SQL Server or Marklogic, as long as the schemas/data are open source?
Our project endorses open-source principles, and our preference would be to use open-source database services.

Saying that, this is an area we’re relaxed about as we wouldn’t be providing (direct) access to the database. We would still expect the schemas and data to be open source.

One thing to note for compatibility reasons is that we’re expecting suppliers to support us in running the relevant data services on BEIS internal cloud infrastructure (e.g Azure / AWS).
16. Can you provide any examples of communities which you consider best-practice or comparable to what you are trying to achieve with this project?
Some examples of good practice we have identified include the Transport for London API, as well as the Company’s House API.

In general, we’re interested in communities of software developers based around open data services – we're looking to build a community that will benefit from the ORP data and can provide a feedback loop for us to iterate the development of our service.

The deadline for asking questions about this opportunity was Thursday 23 June 2022.