Skip to content

Privacy & Security

This page answers the questions most often asked in IT and security reviews of Busroot.

1. Solution overview

Name of solution and vendor

  • Solution: Busroot.
  • Vendor: a private limited company registered in England and Wales. Company registration and VAT numbers are available on request.

Purpose of the solution

  • Busroot is a software platform that improves manufacturing performance and efficiency by turning raw shop-floor data into standard, actionable insights.
  • It measures performance at workstation level (each workstation is called a "Station") for both discrete and continuous processes. It provides real-time metrics, quantified inefficiencies, root-cause insights, and support for corrective and automated actions.

Type of solution

  • Multi-tenant, browser-based SaaS hosted in AWS.

Business processes supported

  • Real-time visibility of manufacturing performance and losses.
  • Quantification of inefficiencies in monetary terms, and tracing of root causes at station, shift, plant and SKU level.
  • Review, approval and automation of corrective actions and continuous improvement workflows.

Criticality of processed information

  • Busroot processes operational manufacturing signals and contextual production data. The availability and integrity of this data are important for production planning, performance management and continuous improvement.

2. Ownership and access

Business or project owner

  • The customer names its own business owner, for example Operations, Manufacturing Excellence or IT.

Technical implementation and administration

  • The vendor provides implementation support. Day-to-day administration (configuration, user management, integrations) is usually done by the customer's operations or IT teams.

Who needs access, and roles

  • Each user has one of these roles (see Users):
    • Admin: manages configuration, users, access codes, devices and API keys.
    • Member: views and edits all areas, including the admin section and schedules.
    • Supervisor: adds, edits and uploads schedules, edits downtime reasons, adds notes and completes Tasks.
    • Read Only: views all data and settings, and downloads data, but cannot change anything. New users get this role when they first log in.
    • Blocked: cannot use Busroot.

Is access limited and password protected?

  • Users log in with their work email address, using a passwordless login link or Microsoft SSO.
  • Access is role-based and limited to authorised users. Access to the hosting environment and infrastructure requires multi-factor authentication (MFA).

3. IT and technical requirements

Hardware (where applicable)

  • Data acquisition units (DAUs): Arduino Opta (model AFX000002) devices connected to equipment. See Machine connectors.
  • DAUs need little bandwidth (less than 1 MB per minute per device) and send data over MQTT on ports 1883 and 1885.
  • Optional peripherals: energy meters, operator screens for operator input, and large screens such as TVs for display.

Software (client requirements)

  • Any modern web browser.

Infrastructure and networking

  • Devices connect in one of two ways (see Shop floor network):
    • The site's own Wi-Fi. The customer must allow outbound MQTT (TCP 1883 and 1885) from the DAUs to the vendor's MQTT endpoint. Host details are provided during onboarding.
    • A dedicated wireless network with 4G gateway routers, supplied by the vendor. The devices do not connect to the customer's site network, so no firewall change is needed.
  • Web app: users' networks must allow outbound HTTPS (TCP 443) to Busroot's domains.

Architecture and data flow (high level)

  • DAUs send machine and production signals over MQTT to the cloud.
  • Every minute, Busroot combines real-time station data with contextual information (plant, shift, station, SKU, schedules) and builds "station windows" that hold all metrics for that 1-minute interval.
  • Aggregations of station windows drive dashboards, reports and alerts.

Hosting and network security

  • Busroot is hosted in AWS data centres in UK regions.
  • Network security uses AWS Security Groups and Network ACLs in place of traditional firewalls, configured on least-privilege principles.
  • Audit and security logs are collected centrally with AWS CloudTrail and CloudWatch Logs.

4. Identity and access control

User account and role management

  • Users log in with their work email address, using a passwordless login link or Microsoft SSO. See Microsoft SSO.
  • Access is role-based. The roles are listed in section 2.

Permissions and access enforcement

  • Access is controlled by role-based access control (RBAC), so only authorised people can change production configuration and data.
  • Least privilege is applied to system and infrastructure accounts.

Single sign-on (SSO) and multi-factor authentication (MFA)

  • SSO: Microsoft SSO is supported for Busroot user authentication.
  • MFA:
    • MFA is enforced for remote access to corporate infrastructure through Tailscale.
    • MFA is required for administrative and root-level access to infrastructure.
    • MFA is required for access to the corporate email accounts used for support and administration.

5. Data management

Types of data collected and processed

  • Real-time shop-floor signals per station, for example machine states, cycles, counts and downtime events.
  • Contextual configuration: plants, shifts, stations, SKUs, and production and non-production schedules.
  • Aggregated performance metrics ("station windows"), computed every minute for each station.
  • No personally identifiable information (PII) of EU citizens is required or processed.

Data transfer between systems

  • Contextual data (for example SKUs, schedules and orders) can be managed in the user interface, or synchronised through the API from ERP, MRP, MES and other third-party systems.

Data storage (location and provider)

  • Data is stored in AWS in UK regions, using services such as Amazon RDS (PostgreSQL), EBS and S3.
  • All data stored in AWS is encrypted at rest with AWS server-side encryption (for example SSE-S3 or SSE-KMS).

Data stored within customer systems

  • Customers may keep their own copies of configuration and production data in ERP, MES or BI systems. Busroot does not dictate customer-side storage.

Data minimisation

  • Only the signals connected during installation and configuration are collected. These correspond to the relevant production and manual processes.

Data retention and deletion

  • Databases use WAL and snapshot backups, which allow roll-back and recovery to earlier points in time.
  • A formal secure deletion process exists. Its confirmation reports give the date, time, actor and data deleted, with checksum-based verification of completeness.

Encryption at rest and in transit

  • At rest: all data in AWS is encrypted with AWS-native encryption.
  • In transit: browser and API communication uses HTTPS/TLS. MQTT connections are restricted to the required ports and secured to AWS and network standards.

Secure protocols and OS hardening

  • Operating system baselines are hardened to expose only the required ports, protocols and services, with antivirus, file integrity monitoring and logging enabled.

6. Data lifecycle and protection

Data transfer from customer to vendor

  • Real-time equipment signals are sent from DAUs to Busroot over MQTT.
  • Contextual master data (plants, SKUs, schedules, orders) is created in the user interface or synchronised through secure APIs over HTTPS.

Storage, protection and disposal on the platform

  • Data is stored in encrypted AWS services with access controls, logging and least-privilege IAM policies.
  • Secure deletion is supported, with auditable confirmation reports.

Log retention

  • Security and audit logs are stored centrally in AWS CloudTrail and CloudWatch, with retention periods set to meet regulatory and contractual needs.

Vendor access to data

  • Support engineers may access customer environments and data for onboarding, troubleshooting and optimisation, with least-privilege, logged access.
  • Customers have full access to the data points configured during installation. Some signals may be filtered during calibration, for example by minimum cycle time thresholds.

7. Security risk and impact

Impact of unauthorised disclosure

  • Unauthorised disclosure could expose sensitive operational data, such as production rates, downtime and product mix.
  • If this happens, the customer is told promptly, with incident details. Monitoring tools are in place to detect unusual data access.

Impact of data modification or destruction

  • Changed or lost data could affect KPI calculations, historical benchmarking and decision-making.
  • Databases use WAL and snapshot backups that support roll-back to earlier points. Restore procedures reduce the impact.

Impact of service or data unavailability

  • A disruption could reduce real-time visibility of performance. Busroot does not control equipment directly.
  • Hosting can be redeployed quickly to other environments from backups if a disruption lasts a long time.

8. Updates, monitoring and logs

Known vulnerabilities and management

  • Security threat detection systems (signature, list and behaviour-based) are updated regularly across infrastructure components, with continuous monitoring of new threats.

Patching and updates

  • Regular patching of:
    • operating systems (servers, workstations, laptops)
    • applications (browsers, productivity tools, communication tools, databases, collaboration tools, endpoint security)
    • servers, network devices and web applications

Routine maintenance or configuration tasks for customers

  • Customers have no regular maintenance to do, other than keeping local networks and devices working and patching their own corporate endpoints.

Security monitoring and log aggregation

  • A SIEM system collects, correlates and analyses logs from network devices, servers, applications and cloud services, for real-time monitoring and alerting.
  • Audit logs are stored centrally, reviewed regularly and monitored automatically for anomalies.

9. Compliance and standards

PII processing

  • Busroot does not process PII of EU citizens for its intended manufacturing performance use.

Global privacy laws

  • The solution is designed and operated to comply with applicable privacy laws such as GDPR and similar frameworks.

Security standards (ISO, SOC, etc.)

  • The company is preparing for ISO 27001 certification with the support of a specialist security and compliance provider.
  • Preparation includes automated compliance monitoring, continuous monitoring, documentation management and audit support.

Ongoing compliance

  • Security policies and the ISMS are reviewed at least once a year, and when infrastructure, systems or services change significantly.

10. Integration and connectivity

Supported integrations

  • Busroot has an HTTP API over HTTPS for integration with ERP, MRP, MES and other systems. See API and SDK.

Authentication and security for integrations

  • Integrations use scoped API keys over HTTPS. Keys are used for both authentication and authorisation. See API keys.

Credential storage and management

  • API keys are stored in secure PostgreSQL databases, and can be revoked or set to expire.
  • Keys are scoped so that each application or integration can reach only the resources it needs.

11. Secure development practices

Secure SDLC

  • The company follows industry-standard secure development practices aligned with OWASP SAMM and ISO 27034, including governance, design, implementation and verification activities.

Code review and security testing

  • Automated static source code analysis runs in the CI/CD pipeline to find security defects before production.
  • Senior technical staff also review code manually.
  • Vulnerability scans run regularly at network, OS, application, database and web application level.

Third-party testing and assessments

  • Third parties carry out penetration tests and security assessments of the application and network, especially around major releases and significant changes.
  • Red-team style exercises may be carried out, depending on risk profile, regulatory requirements and infrastructure changes.
  • Management reviews audit and penetration-test remediation plans regularly as part of security governance.

SBOM and third-party components

  • A Software Bill of Materials (SBOM) is maintained, and vulnerabilities in components are monitored automatically.
  • Third-party providers have annual security reviews or audits, and contracts with security clauses (confidentiality, data protection, incident response, audit rights and so on).

12. Security operations

Threat monitoring

  • Endpoint protection includes behavioural detection.
  • Threat detection systems (signatures, lists, behaviour) are updated regularly, with continuous monitoring of new threats.

Alerting and defect detection

  • SIEM and logging give real-time alerts for critical events.
  • Both automated and manual source code analysis are used to find security defects before production.

Incident response and SLA

  • A documented incident response plan covers identification, containment, eradication, recovery, communication and post-incident documentation.
  • Incident response plans are tested at least once a year (for example with tabletop exercises or simulations), and the results improve the plan.
  • The company reviews its security controls and information supply chain, including all third-party dependencies, once a year.

13. Vendor personnel security

Background checks

  • Pre-employment checks include employment and education verification, carried out under applicable laws and handled confidentially.

Employment agreements and policies

  • Employment contracts require staff to follow the information governance and security policies. Contracts must be signed before access to facilities and systems is given.

Security awareness

  • Information security awareness is kept up through regular communications, reminders and updates, rather than a heavy formal training programme.

Offboarding

  • Offboarding includes disabling SaaS accounts, revoking credentials and tokens, rotating shared passwords, recovering or remotely wiping company devices, and recording the removal of access so that no accounts are left orphaned.

14. Exit strategy and offboarding

Data handling on contract termination

  • When the contract ends, data is deleted with the secure deletion process, in line with the contractual retention and deletion commitments.
  • Confirmation reports of the secure deletion are available on request.

Data export and certificates

  • Customers can get final data exports (through the user interface or the API) and, on request, documents or certificates that confirm secure deletion. See CSV export.

Post-exit support

  • Limited post-exit support may be given for final exports and self-service migration, as agreed in the contract.

15. Physical and cloud infrastructure security

Data centre locations

  • Data is hosted in AWS data centres, currently in UK regions.

Physical security measures

  • AWS data centres provide the physical security (access control, surveillance, environmental controls), consistent with AWS certifications. Busroot relies on these controls under the shared-responsibility model.

Certifications

  • AWS data centres hold industry certifications such as ISO 27001 and SOC reports. The vendor is preparing for ISO 27001 for its own ISMS.

16. AI and ML capabilities

Use of AI and ML

  • Busroot does not currently use or expose artificial intelligence or machine learning capabilities (such as predictive analytics, chatbots or automated decision-making) for customer data.