Open Systems Lab

PlanX

Plan✕ is a content management system (CMS) for digital services. It enables local authorities to create, share and operate smart, dynamic-form services that make complex rules easy to navigate. Plan✕ is an open source tool, developed with local authorities and DLUHC. The aim is to make planning simpler for everyone.

Features

• Simple, seamless planning services for applicants and their agents
• Works in browser on desktop computers and mobile devices
• Themed for your council identity
• Accessible-as-standard
• Dynamic, 'smart' content that responds to users inputs
• Pulls in GIS data from Digital Land API
• Editor interface for content management by planning officers
• Includes shared service content, e.g 'Do I need planning permission?'
• Has shared service templates for all main planning services
• Service analytics and feedback

Benefits

• Makes planning simpler and more transparent for applicants
• Increases user satisfaction and improves accessibility
• Reduces the volume of telephone and email enquiries
• Reduces the number of invalid planning applications
• Reduces application processing time downstream
• Reduces number of applications that need to be refused
• Gives planning authorities control over their services and their outcomes
• Allows planning authorities to better understand service usage
• Feedback and analytics reveal where improvements to guidelines are needed
• Ensures consistency of guidance and decisions

£5,000 an instance a year

• Free trial available

Service documents

• Pricing document

  PDF

• Service definition document

  PDF

• Terms and conditions

  PDF

Request an accessible format

If you use assistive technology (such as a screen reader) and need versions of these documents in a more accessible format, email the supplier at helen@opensystemslab.io. Tell them what format you need. It will help if you say what assistive technology you use.

Framework

G-Cloud 14

Service ID

748096929311324

Contact

Helen Lawrence
07745112756
helen@opensystemslab.io

Service scope

• Software add-on or extension: No
• Cloud deployment model: Public cloud
• Service constraints: The main constraints are:; 1. Availability of data (eg GIS) data for planning constraints. Planning authorities will need to publish their GIS data via planning.data.gov.uk; 2. Availability of integrations with back-office systems. ; 3. Customers will need to create a GOV.UK Pay account to receive payments.
• System requirements: Any modern web browser (Chrome, Safari, Edge, Firefox, IE11+)

User support

• Email or online ticketing support: Email or online ticketing
• Support response times: Email and Slack support for admins only. We will reply within 24 hours. ; Urgent issues we will usually respond to more quickly.
• User can manage status and priority of support tickets: No
• Phone support: No
• Web chat support: No
• Onsite support: Yes, at extra cost
• Support levels: Customer admins can contact us by email or via a community Slack channel to ask questions or report or resolve issues.; ; Within working hours (Mon-Fri 9am-5pm, excluding bank holidays) we aim to respond to: ; ; Critical issues within 2 working hours and put an at least temporary fix within 24 hours.; Major issues within 8 working hours, and we aim to put in place an at least temporary fix within 5 working days.; Minor issues we aim to respond within 16 working hours, if a reply is appropriate. ; ; Additional support services such as training, co-writing and planning information and data auditing are available for an additional cost (see pricing). We may from time to time also provide these for free to the community, including support drop-ins.
• Support available to third parties: Yes

Onboarding and offboarding

• Getting started: We can provide:; ; - An onboarding checklist, listing everything you need to do to launch your service.; - Additional help and advice if needed during onboarding.; - Assistance adding content related to your Article 4 directions; - Basic training for officers; - Shared scenarios library for testing
• Service documentation: Yes
• Documentation formats:
  • HTML
  • Other
• Other documentation formats:
  • Documentation is built into the interfaces
  • Video tutorials available for editors
  • Code repositories contain documentation for developers
• End-of-contract data extraction: Admins will be able export all of the data relating to their Plan✕ services in a structured format (eg csv, json). In the case of data that is available but cannot yet be exported automatically, customers can request this data, and it will be made available to them for no charge.
• End-of-contract process: A Council can request to terminate their Plan✕ subscription at any point in line with the termination terms, by notifying us by email. They can extract any and all data available via the API, and request reasonable assistance in facilitating this. ; ; Any additional assistance – for example, working with a team to help them set up a replacement service – will have a cost based on a reasonable day-rate, to be agreed at the time.

Using the service

• Web browser interface: Yes
• Supported browsers:
  • Microsoft Edge
  • Firefox
  • Chrome
  • Safari
  • Opera
• Application to install: No
• Designed for use on mobile devices: Yes
• Differences between the mobile and desktop service: Public users will have the same experience on mobile and desktop.; ; Although the editor interface used by planning authorities will work on mobile device to some extent, its design is not optimised for them. The editor interface is primarily designed for use on desktop devices.
• Service interface: Yes
• User support accessibility: WCAG 2.1 AA or EN 301 549
• Description of service interface: The main public interface is typical of many digital service interfaces, and uses patterns and components broadly in-line with those used on, for example GOV.UK, but themed with each council's visual identity. Users are asked a series of questions or for specific pieces of information. Their path through the service then depends on the information they provide. The interface is simple, legible, with help text available where users request it.
• Accessibility standards: WCAG 2.1 AA or EN 301 549
• Accessibility testing: Service has been tested and audited April 2024, complies with WCAG 2.2 AA. However some non-essential components, specifically maps, may be difficult for some users with accessibility requirements.
• API: Yes
• What users can and can't do using the API: PlanX has an API that allows users to:; ; – Access and interrogate the content and structure of digital services; – Request enquiry / application data from the database (if they have permission to do so).
• API documentation: Yes
• API documentation formats: Open API (also known as Swagger)
• API sandbox or test environment: Yes
• Customisation available: Yes
• Description of customisation: Customers can customise their PlanX channel with their brand / web theme colours and logo, to provide end users with a clear, seamless experience when navigating from and to other council web pages. You will also need to add a privacy notice and help / contact information for users.; ; You can also use your own council subdomains. eg planningservices.council.gov.uk; ; The content of all flows is controlled by editors within the PlanX editor. Editors can also use flows that are written and maintained by others for use within their own flows.

Scaling

• Independence of resources: Plan✕ procures hosting from AWS (or equivalent) which can scale in response to spikes in user demand. ; ; Data (such as mapping or GIS) that is pulled in from third party sources will, as far as possible, be pulled in from sources that are also able to scale. In the event that demand spikes beyond the scaling capacity of these services, Plan✕ can continue to function independently without these data until demand normalises again.

Analytics

• Service usage metrics: Yes
• Metrics types: – Traffic; – User activity through flows (revealing, for example, the most common enquiry types, balance of responses, and revealing which areas of guidance / policy are proving to be key barriers to users)
• Reporting types:
  • Real-time dashboards
  • Reports on request

Resellers

• Supplier type: Not a reseller

Staff security

• Staff security clearance: Staff screening not performed
• Government security clearance: None

Asset protection

• Knowledge of data storage and processing locations: Yes
• Data storage and processing locations: United Kingdom
• User control over data storage and processing locations: No
• Datacentre security standards: Complies with a recognised standard (for example CSA CCM version 3.0)
• Penetration testing frequency: At least once a year
• Penetration testing approach: Another external penetration testing organisation
• Protecting data at rest: Physical access control, complying with CSA CCM v3.0
• Data sanitisation process: Yes
• Data sanitisation type:
  • Explicit overwriting of storage before reallocation
  • Deleted data can’t be directly accessed
• Equipment disposal approach: Complying with a recognised standard, for example CSA CCM v.30, CAS (Sanitisation) or ISO/IEC 27001

Data importing and exporting

• Data export approach: Some documents and data will be available by means of an export button within the interface. Data can also be exported via the API, subject to permissions.; ; Any data that the user controls but that is not available for direct export can be requested.
• Data export formats:
  • CSV
  • Other
• Other data export formats:
  • JSON
  • PDF (in the case of documents)
• Data import formats:
  • CSV
  • Other
• Other data import formats: PDF (in the case of documents)

Data-in-transit protection

• Data protection between buyer and supplier networks: TLS (version 1.2 or above)
• Data protection within supplier network: TLS (version 1.2 or above)

Availability and resilience

• Guaranteed availability: The service is currently hosted on AWS and therefore benefits from their availability (99.9% uptime) and resilience. In the unlikely event that the PlanX service should go down, our team will be alerted automatically (or by the customer) and seek to restore the service as quickly as possible. ; ; No refunds are currently agreed in the event of service downtime as part of the SLA.
• Approach to resilience: Alongside the security and load-management measures we have in place, critical data is also backed-up regularly to minimise loss and restore the service as quickly as possible in the event of an incident.; ; Where PlanX services rely on integrations with third party data sources (such as Ordnance Survey or planning.data.gov.uk in the case of data), or back-office systems, these are separated. This means Plan✕ is designed to continue to function without that third party data, and failed submissions to back-office systems will be resent once that system comes back online again.
• Outage reporting: Customers will be notified of any planned outages by email in advance, and such outages will be timed to minimise disruption. In the event of any unplanned outage, the Customer will be informed as quickly as possible by email or through the community forum.

Identity and authentication

• User authentication needed: Yes
• User authentication: Identity federation with existing provider (for example Google Apps)
• Access restrictions in management interfaces and support channels: The Plan✕ editor uses role-based access control for admins and editors. Users will be authenticated using federated identities (e.g. Google or Microsoft vis OAuth 2.0 standard). Attempts to circumvent these restrictions (e.g. via the API) would return an error and the request will be logged.; ; Third party support channels used by OSL enforce industry standard authentication and require two-factor authentication whenever possible.; ; An access log is kept centrally, detailing permission levels. Management access by OSL staff is controlled by company Directors. Access to the servers is monitored using third party application services.
• Access restriction testing frequency: At least every 6 months
• Management access authentication:
  • Identity federation with existing provider (for example Google Apps)
  • Username or password

Audit information for users

• Access to user activity audit information: Users contact the support team to get audit information
• How long user audit data is stored for: At least 12 months
• Access to supplier activity audit information: Users contact the support team to get audit information
• How long supplier audit data is stored for: At least 12 months
• How long system logs are stored for: At least 12 months

Standards and certifications

• ISO/IEC 27001 certification: No
• ISO 28000:2007 certification: No
• CSA STAR certification: No
• PCI certification: No
• Cyber essentials: Yes
• Cyber essentials plus: No
• Other security certifications: No

Security governance

• Named board-level person responsible for service security: Yes
• Security governance certified: No
• Security governance approach: The Plan✕ tech lead is tasked with ensuring OSL security policies are complied with.
• Information security policies and processes: The CEO is a Director of OSL and is ultimately responsible for ensuring policies and processes are well-designed and followed. Directors receive a report from the Plan✕ tech lead at Board Meetings. OSL maintains a risk register and issue identification and escalation process. Company procedures are regularly reviewed to ensure best practice compliance.

Operational security

• Configuration and change management standard: Supplier-defined controls
• Configuration and change management approach: Whenever possible OSL provisions and manages infrastructure with code using services (such as Terraform). Configurations are stored in a Git repository so we can track changes in version control. All code deployments must pass a suite of Continuous Integration Tests before going live. We tag each build as part of the deployment process.
• Vulnerability management type: Supplier-defined controls
• Vulnerability management approach: OSL uses an automated service to constantly monitor for threats and identify attacks immediately. Whenever possible we intend to keep all dependencies up to date using an automated service (such as Dependabot).
• Protective monitoring type: Supplier-defined controls
• Protective monitoring approach: OSL uses monitoring tools to help identify potential compromises with reports on server activity and email alerts. All code deployments must pass a suite of Automated Tests before going live.
• Incident management type: Supplier-defined controls
• Incident management approach: Users can report incidents or issues at any time via email, community forum or in-service feedback. Many incidents may be automatically detected and logged. ; ; We maintain a detailed incident response plan, the purpose of which is to contain the incident, minimise its impact and communicate clearly and quickly. Significant incidents will be reported via community forum and/or email. This reporting will describe the incident, its impact, any relevant evidence, and steps we are taking to respond or prevent it reoccuring in future. Customers can also request reports if they want further information about an incident.

Secure development

• Approach to secure software development best practice: Conforms to a recognised standard, but self-assessed

Public sector networks

• Connection to public sector networks: No

Social Value

• Social Value:

  Social Value

  • Fighting climate change
  • Tackling economic inequality
  • Wellbeing

  Fighting climate change

  The built environment is directly responsible for 25% of the UK's carbon emissions; 42% if you also consider its influence on people's travel choices. This puts the planning system at the front line of the climate challenge. For example, almost all of England's 25 million homes will need to be upgraded. However, today the planning process is too difficult to navigate, and such a large volume of applications would overwhelm planning authorities. This makes technology like Plan✕ vitally important because only by making planning simpler, planning rules easier to understand, and applications easier to process will we be able to meet the challenge.

  Tackling economic inequality

  The complexity and opacity of the planning system is a significant – and often prohibitive – barrier to homeowners and small businesses. Making planning simpler helps address this.; ; It will also improve the productivity of not just businesses, but also council teams, for example by reducing failure demand, reducing repetitive demand, and allowing them to focus more resources on ; planning.

  Wellbeing

  The large majority of users of the planning system are homeowners seeking to make improvements to their home, including adapting homes to meet their spatial needs over time, including for their health, disability needs, improving the energy performance of homes and daylight. However, today, the complexity and opacity of the planning system is a barrier to doing this. Making planning simpler will reduce this barrier.

Pricing

• Price: £5,000 an instance a year
• Discount for educational organisations: No
• Free trial available: Yes
• Description of free trial: We can provide a trial instance for potential customers to explore and test Plan✕ before subscribing. This may not include all data integrations, and customers will not be able to go live with any services.

Service documents

• Pricing document

  PDF

• Service definition document

  PDF

• Terms and conditions

  PDF

Request an accessible format

If you use assistive technology (such as a screen reader) and need versions of these documents in a more accessible format, email the supplier at helen@opensystemslab.io. Tell them what format you need. It will help if you say what assistive technology you use.