Version 1.1 · Effective August 24, 2026 · Last updated: September 07, 2026
This Security Policy describes the administrative, technical, and operational safeguards Linton Business Solutions, LLC ("LBS") uses to protect the Work-A-Beez service and Customer Data. The policy is designed to support confidentiality, integrity, availability, accountability, and risk reduction. It is not a representation that any particular certification has been achieved or that all security risk can be eliminated.
This policy applies to production systems, application code, databases, cloud services, administrative access, personnel and contractors with authorized access, and third-party providers used to operate Work-A-Beez. Customer-managed devices, customer networks, customer identity practices, and customer employment/payroll processes remain outside LBS's direct control.
LBS uses a risk-based approach to security. Security decisions may consider likelihood, exploitability, data sensitivity, customer impact, business impact, regulatory obligations, available mitigations, and provider dependencies. Security controls and policies are reviewed periodically and may be updated as the product, threats, and business requirements evolve.
LBS is responsible for the security of the application and cloud resources under its control, including application maintenance, secure configuration, production secrets, security updates, incident response, and coordination with hosting/service providers. Customers are responsible for lawful use, user lifecycle management, credential protection, endpoint security, workplace-device control, internal networks, and proper configuration of workforce policies.
Access is granted based on business need and application role. The current service distinguishes organization employees, organization administrators, and separate platform-level system administration. Customer records are logically scoped to the applicable organization. Access to production or administrative systems is limited to authorized personnel and providers as necessary to operate or support the Service.
Customer-facing MFA and SAML/OIDC SSO are not generally available as of this policy version. LBS will not describe those controls as implemented until the production service supports them.
The current new-organization administrator signup flow requires a password of at least twelve characters including uppercase, lowercase, numeric, and special-character elements. Legacy accounts or other credential flows may have been created under earlier rules. Work-A-Beez does not currently represent that universal password expiration, history/reuse prevention, or customer-facing MFA is enforced across all account types.
Work-A-Beez uses logical multi-tenant isolation. Application queries and authorization checks are designed to restrict customer users to records associated with their organization and permitted role. Platform-level system administration is separated from ordinary customer access. Work-A-Beez does not currently provide a dedicated database or dedicated application stack for each customer unless expressly contracted.
Production user traffic is protected with HTTPS/TLS. The service uses production browser/session protections including security headers, HSTS where configured, HttpOnly/SameSite cookies, Secure cookies in production where applicable, and CSRF protections on protected web forms.
Work-A-Beez relies on managed cloud/database controls for storage protection and uses one-way hashing for credentials and selected security tokens. Secrets are supplied through protected environment configuration. LBS does not represent that every customer field is encrypted separately at the application layer and does not currently offer customer-managed keys or BYOK as a generally available feature.
Production services are hosted on professionally managed cloud infrastructure. The hosting provider supplies physical security and portions of network, compute, database, storage, and resilience controls. LBS configures and operates the application within that environment. Customer-selected hosting regions and geographic redundancy are not standard features currently promised by LBS.
Application changes are maintained in version control and are subject to automated CI checks. The current CI workflow includes Python syntax validation, linting for material coding errors, application boot verification against PostgreSQL, unit/template tests, security-lint reporting, and dependency-vulnerability reporting. Security considerations are evaluated during development and remediation work.
Automated tests and scans are one layer of control and do not constitute a penetration test, independent security audit, or guarantee that all vulnerabilities will be identified.
LBS evaluates software vulnerabilities, dependency issues, provider advisories, and security findings based on risk. Remediation priority considers severity, exploitability, exposure, customer impact, and available mitigations. Security updates may be deployed outside normal release timing when necessary. Unless a customer contract says otherwise, Work-A-Beez does not promise fixed vulnerability-remediation deadlines.
LBS may use application testing, code review, dependency scanning, security linting, and other validation techniques. Work-A-Beez does not currently represent that it has an annual independent third-party penetration-test report available for customer distribution. Any future penetration-testing statements will identify scope and date where appropriate.
Selected application, security, administrative, and operational events are logged for troubleshooting, security review, abuse detection, and incident response. Monitoring also relies on cloud-provider and application health capabilities. Logging coverage varies by component; this policy does not represent that every action is logged or that customer-visible logs are immutable.
LBS maintains procedures for security incident identification, triage, containment, investigation, eradication/remediation, recovery, communication, documentation, and lessons learned. If a Security Incident affecting Customer Personal Data is confirmed, LBS will notify the affected Customer without undue delay as required by applicable law and contract. LBS may preserve evidence and coordinate with providers, counsel, insurers, law enforcement, or regulators where appropriate.
Work-A-Beez uses managed hosting/database capabilities and operational procedures intended to support backup and recovery. Backup retention and point-in-time recovery availability depend in part on provider and plan capabilities. Standard self-service plans do not include a fixed contractual RTO or RPO unless expressly agreed in writing.
LBS maintains continuity and disaster-recovery planning intended to prioritize restoration of critical service functions after material disruption. Recovery decisions consider customer impact, data integrity, provider availability, security, and operational feasibility. Uninterrupted operation cannot be guaranteed.
LBS uses third-party providers where necessary for hosting, payment processing, email delivery, integrations, and mobile notification delivery. Providers are evaluated based on the nature of the service, data involved, operational dependency, security/privacy information available, and contractual considerations. Current material providers are identified in the Trust Center Subprocessor List.
LBS seeks to process data reasonably necessary to provide, secure, support, and administer the Service. Retention depends on active-service needs, legal requirements, accounting/security needs, dispute resolution, fraud prevention, and backup lifecycle. Customers remain responsible for their own legal retention obligations for workforce records.
Personnel and contractors with authorized access to confidential information are expected to protect it and use it only for legitimate business purposes. Access should be limited according to need and removed when no longer required. Security awareness and confidentiality expectations are communicated according to personnel responsibilities and organizational needs.
As of this policy version, LBS does not represent that Work-A-Beez has a SOC 2 Type I/II report or ISO/IEC 27001 certification. The Trust Center describes current readiness and roadmap work. Published roadmaps do not create a guarantee that a certification, audit, feature, or control will be completed by a specific date.
Security exceptions may be approved when justified by business need, risk, compensating controls, and operational constraints. LBS may update this policy as technology and risk evolve, provided changes do not override a specific signed customer commitment without following the applicable contract.
Security questions and responsible vulnerability reports may be sent to info@lbsconnect.net.