How Slate protects your data.

Data in transit and at rest

All communication between your browser or API client and Slate travels over TLS 1.3. There is no unencrypted path into the application. Data at rest, including role definitions, application text, and screening reads with reasons, is encrypted with AES-256 across every storage layer. Encryption keys are managed per-workspace.

Access controls and least privilege

Workspace access is role-based. On Team and Scale plans, administrators can add members, assign roles, and revoke access at any time. On the Scale plan, SAML 2.0 single sign-on is available so seat access is governed by your identity provider: deprovisioning in your IdP terminates Slate access without a separate step.

Slate staff hold no standing read access to customer workspaces. Elevated access for support or debugging requires an explicit, time-bounded grant approved by a second staff member and reviewed after the fact. Audit logs of workspace actions are available on Scale and can be exported in JSON format.

Your data is not used to train models

Your roles, applications, and reads are yours. We do not sell workspace data. We do not use your workspace to train language models, including the models Slate routes through to produce a read. Your screening data does not improve the model for other customers. Anonymised, aggregate telemetry about reliability and latency is kept separately and is not tied to workspace content.

Model providers as sub-processors

Slate is model-agnostic. It routes reading tasks across a small set of leading language model providers, choosing the right model for each application at each point in the screen. The content sent to a model provider is the application text and the role definition, the minimum needed to produce the read. Account information, billing data, and workspace metadata are not sent.

Model providers receive application content only to generate the screening read. Under the API terms of each provider we use, content submitted via API is not used to train their models. Customers who need a named sub-processor list may request it from security@slatescreening.com. We provide advance notice of material changes.

Tenant isolation

Each workspace is logically isolated at the application and storage layers. Reads, candidates, role definitions, and screening history are scoped to your account and are not accessible to or queryable by other customers. There is no cross-workspace data exposure by design.

Retention and deletion

Workspace data is retained while your account is active. You can delete individual candidates, reads, or entire roles from within the application at any time without contacting us. If you close your account or submit a deletion request to security@slatescreening.com, we delete your workspace data within 30 days and send written confirmation on completion. Backups that include your data are rotated out within the same window.

Secure development

Code changes go through peer review before merging. Dependencies are tracked and updated regularly. We test for common web application vulnerabilities as part of the development process and will move to a formal penetration testing schedule as we approach SOC 2 completion.

Availability

All services are monitored continuously. Current operational status, including uptime history and recent updates, is available at slatescreening.com/status.

Compliance posture

SOC 2 Type II is in progress with an accredited third-party auditor. We have not yet completed the audit and do not claim certification. We will share the completed report with customers on request once it is issued. Current controls documentation is available on request to security@slatescreening.com.

Customers with specific compliance requirements, such as HIPAA or regional data residency, should contact us before signing up so we can give an honest account of where we stand and what we can accommodate.

Responsible disclosure

If you find a security issue in Slate, please send the details to security@slatescreening.com. We acknowledge every report within one business day, provide status updates at 30-day intervals, and aim to resolve confirmed issues within 90 days. We do not take legal action against researchers who disclose in good faith and give us reasonable time to respond before publishing.

We do not yet operate a formal bug bounty programme. We appreciate every report and acknowledge meaningful contributions publicly where the researcher consents.

Related pages

For how we handle personal data under applicable privacy law, see the Privacy Policy. For how the screening read is structured to reduce bias, see Fairness.