# 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.output.industries/technical-onboarding/privacy-and-security.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.