1.Overview & Attestation Status

SlabOS is a multi-tenant SaaS platform for countertop fabricators. Every shop ("Tenant") stores its accounts, quotes, jobs, crew schedules, slab inventory, and — most sensitively — its pricing on the SlabOS platform. We treat that data as if our business depended on protecting it, because it does.

Our security program is built and operated against the AICPA SOC 2 Trust Services Criteria (2017). The criteria break into five categories; Sections 2–6 of this document map our controls to each.

Regardless of report timing, the controls in this document are in operation today. Sections 2–10 describe what we actually do, not aspirations.

2.Security (Common Criteria)

The Common Criteria (CC-series) are the backbone of every SOC 2 engagement — the controls that protect the system against unauthorized access, whether logical or physical.

Authentication & Credentials

• Passwords are hashed with bcrypt (work factor 10) and never stored, logged, or transmitted in plaintext.
• Sessions are issued as signed JWTs with short-lived access tokens and rotating refresh tokens.
• Brute-force protection: five failed sign-in attempts lock an account for fifteen minutes; lockout and failed-attempt counters reset on a verified administrative password reset.
• Administrative password resets clear lockout state so a recovering user can sign in immediately without a residual block.

Authorization

• Every API endpoint is guarded server-side. Role-based access control (RolesGuard) enforces granular per-tenant permissions (e.g. quotes:read, jobs:write); the platform's cross-tenant administrative surface is gated separately by a SuperAdminGuard restricted to an explicit allow-list of operator emails.
• Owner-only financial surfaces (revenue, pipeline analytics, company health) are gated at the controller layer, not merely hidden in the UI.

Application-Layer Hardening

• A strict Content Security Policy is set on every response, with a tightened policy for administrative routes that permits no third-party origins.
• frame-ancestors, object-src 'none', base-uri, and form-action directives constrain clickjacking, injection, and exfiltration vectors.
• All traffic is served over TLS; HTTP is upgraded via upgrade-insecure-requests.
• The API enforces CORS to known origins and applies security headers via Helmet.

Change Management & Code

• All code changes flow through version control with reviewable history.
• Static analysis (CodeQL) runs against the repository to surface security-relevant defects.
• Production secrets are held in the deployment platform's encrypted environment store, never in source.

3.Availability

SlabOS targets 99.9% monthly uptime, formalized in the Service Level Agreement (Document 07) with automatic service credits when we miss.

• Managed infrastructure: the application runs on a managed cloud platform with horizontal scaling; the database is managed PostgreSQL with connection pooling.
• External uptime monitoring pings public and authenticated health endpoints on a sub-minute interval from multiple regions; on-call operators are alerted on sustained failure.
• Public status page at status.slabos.org communicates incidents and maintenance.
• Daily automated database backups are retained on a rolling window, with point-in-time recovery available through the managed database provider.
• Edge caching with short revalidation windows keeps the application responsive while ensuring deploys propagate within roughly one minute.

4.Confidentiality & Pricing Secrecy

A fabricator's price list is its most competitively sensitive asset. SlabOS treats pricing confidentiality as a first-class control, reinforced contractually in the Data Processing Agreement (Document 04).

• Encryption in transit: TLS on all connections, internal and external.
• Encryption at rest: database and object storage are encrypted at rest by the underlying managed providers.
• Pricing data never crosses tenant boundaries. A Tenant's materials, price groups, and rules are scoped to that Tenant; no API path returns another Tenant's pricing.
• Operator access is least-privilege and logged. SlabOS staff do not browse Tenant data except as required for support requested by the Tenant, or to investigate a security event.
• File attachments (slab photos, quote PDFs, customer documents) are stored in object storage and served through scoped, expiring URLs.

5.Processing Integrity

Quotes and invoices are only useful if the math is right and the data is complete and timely.

• The pricing engine is deterministic: the same layout and price list always produce the same quote. Area is computed by exact polygon geometry (shoelace formula), not estimated.
• An audit log records security- and data-relevant events, attributable to a user and Tenant where applicable.
• Data migrations from legacy platforms run with dry-run validation and explicit execution flags; destructive operations are never the default path.
• Financial surfaces reconcile to source data; discrepancies surface in the platform rather than failing silently.

6.Privacy

SlabOS processes the personal information of our customers' staff and their end customers (names, addresses, phone numbers, email). Our handling is described in the Privacy Policy (Document 03) and is PIPEDA-, CCPA-, and US state-privacy-law-aware.

• We collect only the personal information required to operate the fabrication workflow.
• We do not sell personal information.
• Data subject rights (access, correction, deletion) are supported; requests are routed through the Tenant as data controller.
• On termination, Tenant data is exported in a portable format and then deleted per the DPA's retention schedule.

7.Tenant Isolation Architecture

SlabOS is multi-tenant by design. Isolation is enforced in the data model, not bolted on:

• Every business record carries a tenantId. Queries are scoped to the authenticated user's Tenant at the service layer.
• A user authenticated to one shop has no API path to another shop's accounts, quotes, jobs, inventory, or pricing.
• Cross-tenant operations are reserved exclusively for the SuperAdmin operator surface, which is restricted to a named allow-list and used for provisioning and support.
• Shared physical infrastructure (one database cluster) with logical row-level isolation is the standard model for modern multi-tenant SaaS and is fully consistent with SOC 2.

8.Subprocessors

SlabOS relies on a small set of vetted infrastructure providers. Each is bound by its own security commitments; the current list is maintained in the DPA and reproduced here for transparency.

Material changes to this list are communicated to customers per the DPA's subprocessor-notification clause. Replace provider names with your contracted entities before publishing if you prefer to name them explicitly.

9.Incident Response & Business Continuity

• Detection: error monitoring and uptime alerting surface anomalies to on-call operators in real time.
• Response: incidents are triaged by severity (mirroring the SLA's four tiers). Severity 1 events trigger immediate operator engagement.
• Communication: affected customers are notified, and material incidents are posted to the status page. Security incidents involving personal data are handled per the DPA's breach-notification timeline.
• Recovery: daily backups plus point-in-time recovery support restoration. Restore procedures are documented and periodically exercised.
• Post-incident: Severity 1 events receive a written post-mortem with root cause and corrective actions.

10.Reporting a Vulnerability

We welcome good-faith security research. If you believe you've found a vulnerability, email security@slabos.org with details and reproduction steps. We commit to acknowledge within two business days, keep you updated through remediation, and not pursue action against researchers acting in good faith under a standard safe-harbor.