Open Registers (Java) is software written by GDS to host their Open Registers. For example, https://country.register.gov.uk/records.
By buying this service we will host and run this software for you so that you can run your own Open Register on your own domain.
- Host your existing, open, register.gov.uk Register.
- API access conformant with the GDS specification.
- Audit every change to data with complete, transparent verifiable logs.
- Choice of GOV.UK or GOV.UK-style branding (depending on domain name).
- It's the same software that currently hosts your register.
- "Plug-compatible" with your existing Register integrations.
- Real-time APIs automate away costs from expensive database change requests.
- Fully standards-compliant with the Government standard for GDS Registers.
- Reuse existing Open Registers of reference data from around Government.
£8500 per instance per month
- Pricing document
- Skills Framework for the Information Age rate card
- Service definition document
- Terms and conditions
|Software add-on or extension||No|
|Cloud deployment model||Public cloud|
|Service constraints||This software is only supported in the same configuration as originally deployed on register.gov.uk.|
|Email or online ticketing support||Email or online ticketing|
|Support response times||For all customers, we provide support within standard business hours (Mon-Fri 8:00am-6:00pm, excluding English public holidays). We respond to P1 (loss of service) and P2 (loss of update) incidents within 2 hours. We respond to P3 (degraded experience) incidents within 4 hours. We respond to P4 (manual configuration or training) requests within 1 business day. Support outside of standard business hours or with agreed shorter resolution time is available as a paid add-on.|
|User can manage status and priority of support tickets||No|
|Web chat support||No|
|Onsite support||Yes, at extra cost|
For all customers, we provide support within standard business hours (Mon-Fri 8:00am-6:00pm, excluding English public holidays). We provide agreed response and resolution times depending on the priority of the support request.
For P1 (loss of service) incidents, we will respond within 2 hours and resolve within 4 hours.
For P2 (loss of update) incidents, we will respond within 2 hours and resolve within 8 hours.
For P3 (degraded experience) incidents, we will respond within 4 hours and resolve within 2 business days.
For P4 (manual configuration or training) requests, we will respond within 1 business day and resolve within 4 business days.
Please see our service definition document for our description of these standard support tiers.
Support outside of standard business hours or with agreed shorter response or resolutions times is available as a paid add-on.
All customers are assigned a Technical Account Manager.
|Support available to third parties||Yes|
Onboarding and offboarding
For all customers, tutorials are available to provide users with information on how to upload their Register data using the API. A specification for the API is available.
Onsite training is available as a paid add-on.
|End-of-contract data extraction||
All user data is available via API or user interface at all times, so users can export all their data before the contract ends as desired.
If requested, customers can also have their data e-mailed to a named account e-mail address free of charge at the end of the contract.
|End-of-contract process||At the end of the contract, online hosting of the Registers ceases immediately. Customers can request a copy of their data or resumption of the service for up to 30 days after the end of the contract. After this time the data is deleted.|
Using the service
|Web browser interface||Yes|
|Application to install||No|
|Designed for use on mobile devices||No|
|What users can and can't do using the API||
Using the API, users can:
• append changes to any of their Registers.
• read data, access root hashes and metadata information for any of their Registers.
Users cannot create, remove or rewind Registers using the API.
The API is documented at https://github.com/openregister/specification
|API documentation formats||HTML|
|API sandbox or test environment||No|
|Description of customisation||
When the site is hosted on a domain ending in .gov.uk, users can use GOV.UK branding, including The Crown and GDS Typeface.
When the site is hosted on any other domain, an alternative, GOV.UK-like style is available.
The customisation is done automatically.
|Independence of resources||We operate in a cloud environment and scale our resource usage in real-time to meet demand.|
|Service usage metrics||Yes|
|Metrics types||Customers can provide a Google Analytics token so that analytics data can be fed into their existing Google Analytics Dashboard.|
|Reporting types||Real-time dashboards|
|Supplier type||Reseller providing extra support|
|Organisation whose services are being resold||GDS's https://github.com/openregister/openregister-java|
|Staff security clearance||Conforms to BS7858:2012|
|Government security clearance||Up to Developed Vetting (DV)|
|Knowledge of data storage and processing locations||Yes|
|Data storage and processing locations||
|User control over data storage and processing locations||No|
|Datacentre security standards||Managed by a third party|
|Penetration testing frequency||At least once a year|
|Penetration testing approach||‘IT Health Check’ performed by a CHECK service provider|
|Protecting data at rest||Physical access control, complying with CSA CCM v3.0|
|Data sanitisation process||Yes|
|Data sanitisation type||Deleted data can’t be directly accessed|
|Equipment disposal approach||In-house destruction process|
Data importing and exporting
|Data export approach||Users can export all Registers and environments from the system via API calls or from the user interface.|
|Data export formats||
|Other data export formats||
|Data import formats||Other|
|Other data import formats||
|Data protection between buyer and supplier networks||TLS (version 1.2 or above)|
|Data protection within supplier network||
Availability and resilience
|Guaranteed availability||For SaaS usage, we guarantee 98% availability Mon-Fri 8am-6pm, excluding English public holidays. Please see our service definition document for full details of our SLAs and refund policy.|
|Approach to resilience||We make use of cloud hosting with multiple availability zones and distributed database technology to provide resilience of our service. Details of our specific design are available on request.|
|Outage reporting||Outages are communicated via a human and machine-readable status page and are distributed via e-mail.|
Identity and authentication
|User authentication needed||Yes|
|Other user authentication||Buyers can optionally supply a white-list of IP addresses that are authorised to append changes to the Registers.|
|Access restrictions in management interfaces and support channels||
Access to support channels and admin role modification is limited to a set of named account email addresses. Only emails that are received with domain verification and from an account email address are able to manage support tickets and request admin role changes.
Only users given an admin role via an account email address are able to grant write access to other users.
|Access restriction testing frequency||At least once a year|
|Management access authentication||
|Description of management access authentication||Buyers can optionally supply a white-list of IP addresses that are authorised to append changes to the Registers.|
Audit information for users
|Access to user activity audit information||You control when users can access audit information|
|How long user audit data is stored for||At least 12 months|
|Access to supplier activity audit information||You control when users can access audit information|
|How long supplier audit data is stored for||At least 12 months|
|How long system logs are stored for||Between 1 month and 6 months|
Standards and certifications
|ISO/IEC 27001 certification||No|
|ISO 28000:2007 certification||No|
|CSA STAR certification||No|
|Other security certifications||No|
|Named board-level person responsible for service security||Yes|
|Security governance certified||No|
|Security governance approach||We have assessed ourselves to be compliant with CCM CSA v3.0. We have security policies that outline the governance requirements on all our systems, infrastructure and staff, and we can share these on request.|
|Information security policies and processes||Our Security Policy requires that change management, vulnerability assessment, data security and incident management processes are followed, and governs how we undertake datacentre security, key and encryption management, access management and audit. We designate a named Director who is responsible for ensuring that processes are sufficiently rigorous and are being implemented fully. Governance is delegated to an Operational Security Group (OSG) who have responsibility for implementing and reviewing our security governance processes, and for undertaking review of our deployed systems and infrastructure. All staff with access to sensitive information report how they are meeting the requirements of the policy to OSG.|
|Configuration and change management standard||Conforms to a recognised standard, for example CSA CCM v3.0 or SSAE-16 / ISAE 3402|
|Configuration and change management approach||Our change management approach complies with CSA CCM v3.0. Any new development or acquisition of application, operational resource or development tool is approved and tracked. Access to security keys or passwords for any accounts through which these resources are acquired is limited to named individuals. Releases of software or infrastructure components are assessed for risks, possible impacts, and possible vulnerabilities and require approval. Backout plans are defined. All changes are tested and validated in a test environment prior to being pushed to production. Appropriate software and hardware protection is utilised to protect devices and infrastructure with access to sensitive information.|
|Vulnerability management type||Conforms to a recognised standard, for example CSA CCM v3.0 or SSAE-16 / ISAE 3402|
|Vulnerability management approach||Our vulnerability management approach complies with CSA CCM v3.0. New resources and changes are assessed for vulnerability and potential compromise as above. Infrastructure and devices have platform-appropriate malware and mobile code protection installed or deployed. Best-practice user authentication to infrastructure (e.g. public key, 2FA) is used where available. Use of third-party dependencies is limited to trusted sources. Changes to third-party dependencies are applied regularly are assessed, approved, tested and released as above. External vulnerability announcements for all third-party dependencies are monitored and corrective action taken if appropriate. Penetration assessments are carried out at least annually by an external accredited organisation.|
|Protective monitoring type||Conforms to a recognised standard, for example CSA CCM v3.0 or SSAE-16 / ISAE 3402|
|Protective monitoring approach||Our protective monitoring approach complies with CSA CCM v3.0. Systems and infrastructure are analysed thoroughly to ensure potential compromises are understood and all vectors have sufficient audit information collected and stored using platform-appropriate technology. Access to sensitive audit information is limited to a named list. Regular and frequent analysis of audit information occurs automatically or manually as appropriate to the nature of the potential compromise. Potential compromises have an incident management process defined (as outlined below) that ensures timely communication with customers and resolution of incidents. Protective monitoring approaches are reviewed regularly both internally and externally by an independent body.|
|Incident management type||Conforms to a recognised standard, for example, CSA CCM v3.0 or ISO/IEC 27035:2011 or SSAE-16 / ISAE 3402|
|Incident management approach||Our incident management approach complies with CSA CCM v3.0. Possible security incidents have a defined incident management process (including steps for triaging the potential impact of the incident, identifying and communicating with affected stakeholders in a timely and regular manner, identifying affected information, and taking immediate steps to resolve the incident and secure any affected systems). Possible and past incidents are reviewed regularly to identify where implementing additional security controls would prevent the incident from occurring. Points of contact (email and phone) are actively maintained and made available for customers to report potential incidents and for liaison with external enforcement.|
|Approach to secure software development best practice||Conforms to a recognised standard, but self-assessed|
Public sector networks
|Connection to public sector networks||No|
|Price||£8500 per instance per month|
|Discount for educational organisations||No|
|Free trial available||No|