Version 1.1 · Last updated: September 07, 2026
This overview explains how Linton Business Solutions, LLC ("LBS") protects data processed through Work-A-Beez. It is intended to provide customers with a practical description of current data-handling practices. It does not create a guarantee of absolute security, replace the Data Processing Addendum (DPA), or promise controls that are not currently implemented.
For workforce data entered by a customer, the customer generally determines why the data is collected, who may access it, how it is used, and how long employment or business records should be retained. In that context the customer generally acts as the controller, business, or equivalent responsible party, and LBS generally acts as a processor, service provider, or contractor as applicable.
LBS may act independently for limited information used to operate its own business, such as account administration, billing records, security records, legal-compliance records, and direct customer-support communications.
Depending on customer configuration and use, Work-A-Beez may process organization information, administrator contact information, employee identifiers and contact information, schedules, time and attendance records, PTO information, payroll-related data entered by the customer, internal communications, device information, IP addresses, session/security information, push-notification tokens, support communications, and limited billing metadata.
Work-A-Beez is not a payroll processor and should not be used as a repository for full payment-card numbers or CVV values. Subscription payment-card processing is handled by Stripe.
Customer business records remain the customer's data. LBS receives the limited rights necessary to host, process, transmit, back up, secure, troubleshoot, and support the Service as described in the Terms of Service and DPA. LBS does not claim ownership of customer workforce records and does not sell Customer Personal Data.
Work-A-Beez is operated primarily from the United States. The production application and managed PostgreSQL service are currently hosted through U.S.-based cloud infrastructure arrangements. Customer-selectable data residency regions are not generally available today, and customers should not assume that data will remain in a particular state, country, or economic area unless LBS expressly agrees to that requirement in writing.
Authorized subprocessors may process limited data in other jurisdictions as needed to provide their services. Customers with legal data-localization requirements should review the Data Residency Statement and Subprocessor List before deployment.
Supported communications between users and the production web service are protected using HTTPS/TLS. The application also uses production security headers and secure-cookie settings designed to reduce common browser/session risks.
Work-A-Beez relies on provider-managed storage/database protections for hosted data and uses one-way cryptographic hashing for administrator passwords, employee clock-in PINs, trusted-device tokens, and server-side mobile refresh credentials. Work-A-Beez does not represent that every individual customer database field is separately encrypted at the application layer, nor does it currently offer customer-managed encryption keys or BYOK.
The platform uses logical organization scoping and authorization checks to separate customer records in its multi-tenant architecture. The current service distinguishes employee access, organization-administrator access, and separate platform-level system administration. Work-A-Beez does not currently represent that each customer has a physically separate application stack or dedicated database.
Customers remain responsible for assigning appropriate access, removing inactive users, protecting administrator credentials, controlling authorized workplace devices, and ensuring that only appropriate personnel can view workforce information.
Administrator passwords and employee PINs are not intentionally stored in plaintext. The current organization-admin signup flow enforces a stronger password standard, and the application uses rate limiting and session protections on selected sensitive paths. Customer-facing MFA and SAML/OIDC SSO are not generally available today.
Work-A-Beez records selected security, administrative, and operational events. Logging supports troubleshooting, abuse detection, incident investigation, and accountability, but the Service does not represent that every data access or customer action is captured in a customer-visible immutable audit log.
Customer Data is generally retained while needed to provide the Service and for legitimate contractual, security, accounting, dispute-resolution, fraud-prevention, and legal purposes. Customers are responsible for determining the employment, payroll, tax, and records-retention periods that apply to their organizations.
Work-A-Beez does not promise a single universal retention period for every category of data. More detail is provided in the Data Retention Summary.
Organization-level deletion is a reviewed process rather than an immediate automated purge. A deletion request may require identity/authority verification, assessment of billing or legal obligations, and coordination with backup lifecycle processes. Some information may be retained where required or permitted for legal compliance, accounting, security, fraud prevention, dispute resolution, or enforcement of agreements.
Data in backups may persist until the applicable backup is overwritten, expires, or is otherwise removed through normal provider and recovery processes. The Data Deletion Process describes the current workflow.
When an individual asks LBS to access, correct, delete, or export workforce data controlled by an employer/customer, LBS may direct the request to that employer/customer or notify the customer, unless applicable law requires LBS to respond directly. The customer is generally responsible for deciding whether a request is legally valid and for giving LBS appropriate instructions.
Material providers used in the current service include cloud hosting/database services, Stripe for subscription payment processing, Postmark for transactional email where configured, Microsoft services for reporting/integration functions where configured, and Expo for mobile push notification delivery. Provider use can change over time. Current information is maintained in the Subprocessor List.
Customers outside the United States are responsible for determining whether a transfer mechanism or other safeguard is required for their use of the Service. Where applicable law requires a specific transfer mechanism, the parties may need to execute additional contractual terms. The public DPA does not by itself promise a specific localization arrangement or automatically establish every jurisdiction-specific transfer mechanism.
If LBS confirms a Security Incident affecting Customer Personal Data, LBS will provide notice to the affected Customer without undue delay as required by applicable law and contract. Customers remain responsible for their own notices to employees, regulators, or other third parties where the law places that duty on the customer/controller.
This overview is informational. Binding obligations are governed by the applicable Terms of Service, DPA, Order Form, and any other written agreement between the parties.