Privacy & Security
1. Solution overview
Name of solution and vendor
Solution: Busroot.
Vendor: Private limited company registered in England and Wales (company registration and VAT numbers available on request).
Purpose of the solution
Busroot is a software platform dedicated to improving manufacturing performance and efficiency by transforming raw shop-floor data into standardised, actionable insights.
It measures workstation-level performance (called “Stations”) for both discrete and continuous processes, providing 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.
Subscription / licence model
Annual subscription (contract term 1 year), invoiced either monthly or annually.
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; availability and integrity of this data are important for production planning, performance management, and continuous improvement.
2. Ownership and access
Business / project owner
To be completed by the customer (e.g., Operations, Manufacturing Excellence, or IT).
Technical implementation and administration
Vendor provides implementation support; day‑to‑day administration (config, user management, integrations) is usually handled by the customer’s operations/IT teams.
Who needs access and roles
Typical roles:
Admin: manages configuration, stations, integrations, access, and global settings.
Member: views dashboards and reports with scoped access to plants/lines and limited configuration capabilities.
Is access limited and password protected?
Users authenticate with their work email; passwordless login links and Microsoft SSO are supported.
Access is role-based and limited to authorised users; environment and infrastructure access 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.
DAUs require Wi‑Fi with low bandwidth (< 1 MB/min per device) and outbound MQTT over port 1883 only.
Optional peripherals: energy monitors, tablets for operator input, large TV screens for visualisation.
Software (client requirements)
Modern web browser; Busroot supports Chrome and Safari.
Infrastructure / networking
Web app: customer must allow outbound HTTPS (TCP 443) to Busroot’s domain(s).
Data ingestion: customer must allow outbound MQTT (TCP 1883) from DAUs to the vendor’s MQTT endpoint (IP/host details provided during onboarding).
Architecture and data flow (high level)
DAUs send machine/production signals via MQTT to the cloud.
Every minute, Busroot combines real-time station data with contextual information (plant, shift, station, SKU, schedules) and materialises “station windows” representing 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; for this deployment, UK regions are used.
Network security uses AWS Security Groups and Network ACLs in place of traditional firewalls, configured on least‑privilege principles.
Audit and security logs are centrally collected via AWS CloudTrail and CloudWatch Logs.
4. Identity and access control
User account and role management
Users sign in via work email; magic link (passwordless) or Microsoft SSO may be used.
Role-based access: “Admin” and “Member” roles, with granular scoping to plants/lines where required.
Permissions and access enforcement
Access to production systems is controlled via role-based access control (RBAC), ensuring only authorised personnel can modify 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 via Tailscale.
MFA is required for administrative/root-level access to infrastructure.
MFA is required for access to corporate email accounts used in support and administration.
5. Data management
Types of data collected and processed
Real-time shop‑floor signals (e.g., machine states, cycles, counts, downtime events) per station.
Contextual configuration: plants, shifts, stations, SKUs, production and non‑production schedules.
Aggregated performance metrics (“station windows”) computed every minute per station.
No Personally Identifiable Information (PII) of EU citizens is required or processed.
Data transfer between systems
Contextual data (e.g., SKUs, schedules, orders) can be managed via UI or synchronised via APIs from ERP/MRP/MES and other third‑party systems.
Data storage (location and provider)
Data is stored in AWS (UK region for this deployment), using services such as Amazon RDS/PostgreSQL, EBS, and S3.
All data stored in AWS is encrypted at rest using AWS server-side encryption options (e.g., SSE‑S3/SSE‑KMS).
Data stored within customer systems
Customers may maintain their own copies of configuration and production data in ERP/MES/BI systems; Busroot does not dictate customer-side storage.
Data minimisation
Only signals connected during installation and configuration are collected; these correspond to relevant production and manual processes.
Data retention and deletion
Databases use WAL and snapshot backups, allowing roll‑back and recovery to previous points in time.
A formal secure deletion process exists, with confirmation reports describing date, time, actor, and data deleted, including checksum-based verification of completeness.
Encryption at rest and in transit
At rest: all data in AWS is encrypted at rest via AWS-native encryption mechanisms.
In transit: client and API communication uses HTTPS/TLS; MQTT connections are restricted to required ports and secured per AWS and network standards.
Secure protocols and OS hardening
Operating system baselines are hardened to expose only 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 via MQTT.
Contextual master data (plants, SKUs, schedules, orders) is created via UI or synchronised via secure APIs over HTTPS.
Storage, protection, disposal on 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 centrally stored in AWS CloudTrail/CloudWatch, with retention periods configured for regulatory and contractual needs.
Vendor access to data
Support engineers may access customer environments and data for onboarding, troubleshooting and optimisation, under least‑privilege, logged access.
Customers have full access to the data points configured during installation; certain signals may be filtered in calibration (e.g., minimum cycle‑time thresholds).
7. Security risk and impact
Impact of unauthorised disclosure
Unauthorised disclosure could expose sensitive operational data (production rates, downtimes, product mixes).
In such an event, the customer is notified promptly with incident details; monitoring tools are in place to detect anomalous data access.
Impact of data modification or destruction
Data modification or loss could impact KPI calculations, historical benchmarking, and decision‑making.
Databases employ WAL and snapshot backups supporting roll‑back to earlier points; restoration procedures mitigate impact.
Impact of service or data unavailability
Disruption could reduce real‑time visibility of performance but does not directly control equipment.
Hosting can be rapidly redeployed to alternative environments using backups should there be prolonged disruption.
8. Updates, monitoring, and logs
Known vulnerabilities and management
Security threat detection systems (signature, list, behaviour-based) are regularly updated across infrastructure components, with continuous monitoring of emerging 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 / configuration tasks for customers
No specific recurring maintenance is required by customers beyond keeping local networks and devices functional and patching corporate endpoints.
Security monitoring and log aggregation
A SIEM system aggregates, correlates and analyses logs from network devices, servers, applications and cloud services for real‑time monitoring and alerting.
Audit logs are centrally stored, regularly reviewed, and integrated with automated monitoring for anomaly detection.
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 global privacy laws such as GDPR and similar frameworks.
Security standards (ISO, SOC, etc.)
The company is actively preparing for ISO 27001 verification with the support of a specialised security and compliance provider.
Preparation includes automated compliance monitoring, continuous monitoring, documentation management, and support for audits.
Ongoing compliance
Security policies and the ISMS are reviewed at least annually and on significant changes (infrastructure, systems, services).
10. Integration and connectivity
Supported integrations
Busroot exposes HTTP APIs over HTTPS for integration with ERP/MRP/MES and other systems.
Authentication and security for integrations
Integrations use scoped API keys served over HTTPS; keys are used for both authentication and authorisation.
Credential storage and management
API keys are stored in secure PostgreSQL databases and can be revoked or set to expire.
Keys are scoped to limit access to only the resources required by the application/integration.
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 tools are integrated into the CI/CD pipeline to detect security defects before production.
Manual code reviews by senior technical staff complement automated analysis.
Regular vulnerability scans are performed at network, OS, application, database, and web application levels.
Third-party testing and assessments
Third-party penetration tests and security assessments are performed on the application and network, especially around major releases and significant changes.
Red-team style exercises may be conducted based 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 automatically monitored.
Third‑party providers are subject to annual security reviews/audits and contractual security clauses (confidentiality, data protection, incident response, audit rights, etc.).
12. Security operations
Threat monitoring
Endpoint protection includes behavioural detection capabilities.
Threat detection systems (signatures, lists, behaviour) are updated regularly, with continuous monitoring of emerging threats.
Alerting and defect detection
SIEM and logging provide real‑time alerts for critical events.
Both automated and manual source-code analysis are used to detect security defects prior to 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 annually (e.g., tabletop exercises, simulations) with improvements fed back into the plan.
The company conducts annual reviews of security controls and the information supply chain, including all third‑party dependencies.
13. Vendor personnel security
Background checks
Pre‑employment checks include employment and education verification, conducted under applicable laws and handled confidentially.
Employment agreements and policies
Employment contracts require adherence to information governance and security policies, and must be signed before access to facilities and systems is granted.
Security awareness
Information security awareness is maintained through periodic 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 access removal to avoid orphaned accounts.
14. Exit strategy and offboarding
Data handling on contract termination
On contract end, data is deleted according to contractual retention and deletion commitments using the secure deletion process.
Confirmation reports documenting secure deletion are available upon request.
Data export and certificates
Customers can obtain final data exports (via UI/API) and, on request, documentation/certificates confirming secure deletion.
Post‑exit support
Limited post‑exit support may be provided for final exports and self‑service migration, subject to contract.
15. Physical and cloud infrastructure security
Data centre locations
Data is hosted in AWS data centres, currently in UK regions for this deployment.
Physical security measures
Physical security is provided by AWS data centres (access control, surveillance, environmental controls) consistent with AWS certifications; Busroot relies on these controls as part of its 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 / ML capabilities
Use of AI / ML
The Busroot solution does not currently use or expose Artificial Intelligence or Machine Learning capabilities (such as predictive analytics, chatbots, or automated decisioning) for customer data.
Last updated