Security, HTTPS, incident plan & multi-tenant

1. HTTPS and encryption in transit

Production websites and the e-sourcing app are served over HTTPS only (TLS 1.2 or newer). We do not intend to serve the logged-in product over plain HTTP.

Server-to-server callbacks between our own components (for example the award optimizer and agent worker) must use HTTPS in production and are restricted to allowlisted Tail Sourcing / Base44 hosts. Cardholder data is entered on Stripe-hosted checkout; we do not receive full PAN on our servers.

Browser connections to esourcing.tailsourcing.com and www.tailsourcing.com should show a valid TLS certificate issued for those hostnames.

2. Encryption at rest and secrets

Application and database storage use the hosting provider’s encryption at rest. Selected highly sensitive supplier fields (for example banking details) are additionally encrypted at the application layer before storage. API keys, HMAC secrets and payment secrets live in server-side environment configuration and are not returned to the browser.

3. Multi-tenant isolation

Tail Sourcing is a multi-tenant SaaS: many customer organisations share one application, isolated by tenant.

• Every Customer Data record is scoped to a tenant_id. Authorisation loads the user from the database (not from the JWT alone) and requires a tenant before service-role reads or writes.
• Buyers in tenant A cannot list or mutate tenant B’s requisitions, suppliers, catalogs or invoices through the product APIs.
• The supplier portal is isolated by supplier ownership: a supplier user does not receive another supplier’s quotes, catalogs or orders.
• Platform operators (Tail Sourcing staff) use a separate console, must pass a platform-staff check, and privileged actions are written to an operator audit log.
• Debug or bootstrap functions that could list across tenants are restricted to platform staff.
• Logical isolation is our model (shared database, tenant filters and application asserts). We do not claim a dedicated physical database per customer on standard plans.

4. Access control inside a tenant

Roles (admin, buyer, approver, supplier, custom roles) gate which modules a user can open. UI hiding is not the security boundary — server functions re-check role and tenant. Session timeout can be configured per tenant. Password reset uses emailed one-time codes. Enterprise SSO/SAML is a plan feature where configured; it is not assumed for every workspace.

5. Data-incident (filtración) plan

If we confirm unauthorised access to, or accidental disclosure of, Customer Data (“incident”), we follow this customer-facing process:

• Detect: monitoring, audit logs, employee report, or a notice to info@alseatrading.com.
• Contain: revoke compromised credentials, isolate affected jobs, rotate secrets, and block the vulnerable path.
• Assess: identify tenants, data categories (account vs. procurement content vs. payment metadata), and whether personal data is involved.
• Notify customers: without undue delay, and within 72 hours of becoming aware where GDPR-style rules apply to us as processor/controller, unless a law-enforcement delay is legally required. Notice goes to the tenant admin email on file and describes what happened, what data, what we did, and what you should do (for example reset passwords).
• Notify authorities: when legally required (for example a personal-data breach under GDPR/UK GDPR or applicable US state laws).
• Remediate and review: close the hole, keep an internal incident record, and offer a reasonable post-incident summary to affected customers.

6. How to report a vulnerability or suspected leak

Email info@alseatrading.com. Do not attach live secrets or full dumps of customer data in the first message — describe impact and scope. We also publish a security.txt at https://www.tailsourcing.com/.well-known/security.txt. We do not run a paid public bug-bounty unless announced there.

7. Compliance posture

We design access control, logging and change management toward SOC 2 Security Trust Services Criteria and OWASP Top 10 (broken access control, cryptographic failures, SSRF, security misconfiguration). This page is not a SOC 2 report. If you need a report, DPA or SIG/CAIQ, request it under NDA from info@alseatrading.com.