Version 1.1 · Last updated: September 07, 2026
Work-A-Beez is a cloud-based workforce management service operated by Linton Business Solutions, LLC ("LBS"). This overview describes security controls that are currently implemented or materially supported by the production service. It is intended for customer due diligence and does not represent a certification, audit opinion, warranty of absolute security, or commitment to controls that are identified as roadmap items.
Work-A-Beez uses a shared-responsibility model. LBS is responsible for operating and securing the application and the cloud resources under its control. Customers are responsible for controlling their users, protecting credentials and authorized devices, configuring the service appropriately, and complying with employment, privacy, payroll, record-retention, and other laws applicable to their organizations.
The production application is deployed on professionally managed cloud infrastructure and uses a managed PostgreSQL database. Production secrets and service credentials are supplied through protected environment configuration rather than being intentionally embedded in application source code. Physical data-center security, underlying host security, and portions of network and storage protection are provided by the applicable cloud provider.
Work-A-Beez does not currently promise a dedicated database for each customer, customer-selected hosting regions, geographic redundancy, or customer-managed encryption keys unless those capabilities are expressly stated in a separate written agreement.
Organization administrators authenticate with an account credential. Passwords are stored using one-way password hashing rather than reversible plaintext storage. Employee clock-in PINs are also stored using one-way hashing. Mobile access uses short-lived access credentials and rotating refresh credentials that are stored in hashed form on the server.
Current limitation: customer-facing multi-factor authentication and SAML/OIDC single sign-on are not generally available today. Customers should not represent to auditors or employees that those features are enabled unless LBS has confirmed otherwise in writing.
Work-A-Beez is a multi-tenant application. Customer records are logically separated by organization identifiers and authorization checks. The current application distinguishes organization employee access, organization administrative access, and separate platform-level system administration. Logical isolation is used instead of a dedicated database per tenant.
Customers are responsible for removing users who no longer require access, limiting administrative privileges, protecting company administrator credentials, and reviewing workplace device authorizations.
Where workplace-device authorization is used, Work-A-Beez stores device authorization tokens in hashed form. Device controls are designed to help organizations limit time-clock use to devices they have approved. Customers remain responsible for physical control and security of their devices.
Security controls in the current application include input validation, authorization checks, CSRF protections, session controls, rate limiting on selected sensitive endpoints, secure password/PIN hashing, and restrictions intended to prevent cross-organization access. The development repository uses automated testing, Python syntax/lint checks, dependency-audit reporting, and security-lint reporting as part of the CI workflow.
Automated tools reduce risk but do not prove that the Service is free of vulnerabilities. Findings are evaluated and remediated based on severity, exploitability, customer impact, operational risk, and available mitigations.
The platform records selected application and administrative events for operational, security, and accountability purposes. Logging coverage varies by feature; this overview does not represent that every read, write, API call, permission change, or user action is captured in a customer-visible immutable audit trail.
Work-A-Beez relies on managed database and hosting capabilities, operational procedures, and backups intended to support restoration after significant disruption. Backup availability, recovery windows, and restoration options may depend on the active hosting plan and provider capabilities. Standard self-service subscriptions do not include a fixed contractual recovery time objective (RTO) or recovery point objective (RPO) unless expressly agreed in writing.
LBS maintains an incident-response process designed to identify, contain, investigate, remediate, recover from, and document material security incidents. If LBS confirms a Security Incident affecting Customer Personal Data, LBS will notify the affected Customer without undue delay as required by applicable law and contractual obligations. Notification timing may depend on the facts, legal requirements, law-enforcement restrictions, and the need to avoid further harm.
Work-A-Beez uses third-party providers to operate portions of the Service, including cloud hosting/database services, subscription payments, transactional email, Microsoft-related reporting integrations where configured, and mobile push notifications. The current named-provider information is maintained in the Subprocessor List.
Security questions and responsible vulnerability reports may be sent to info@lbsconnect.net. Do not include passwords, full payment-card data, or unnecessary employee information in an initial report.
This document describes the general security posture of the Service as of the displayed update date. Controls, providers, and technical architecture may change as the Service evolves. Material customer commitments are governed by the applicable Terms of Service, DPA, Order Form, or other signed agreement.