Security, privacy and data handling

Lanced is a hiring and casting platform for the performing arts. Companies publish opportunities; artists build a profile and apply; the two sides message, schedule, decide and contract inside the product.

The platform runs as a single API backed by a managed PostgreSQL database, with object storage for media and contracts, and browser applications for the public site, artists, companies, agencies and internal administration. Production is hosted on managed cloud infrastructure in Amsterdam, the Netherlands — the providers behind it are listed in the Sub-Processor Register (§ 9).

Lanced acts as processor for the applicant data a company handles inside its own workspace, and as controller for artist accounts, profiles and the artist-facing product.

Lanced does not store or ever receive user passwords. Authentication, credential hosting and identity management are delegated to a specialist authentication provider (listed in the Sub-Processor Register, § 9). The sign-in redirect is protected by a single-use nonce carried in a short-lived, HTTP-only state cookie, and the returning callback is rejected if the nonce does not match.

Sessions are server-side records, not self-asserting tokens. The session cookie is HTTP-only, marked Secure in production, and scoped to the Lanced domain. Every request re-reads the session record and rejects it if it has expired or been revoked, then re-checks that the underlying account is neither disabled nor deleted — so disabling an account takes effect on the next request, rather than whenever a token happens to expire.

Workspace access is checked on every request against an active membership record, and a workspace pending deletion stops granting access immediately.

External reviewers — the people a company invites to look at a shortlist without creating an account — hold scoped links rather than sessions. The token behind the link is stored only as a SHA-256 hash, compared in constant time, carries both an expiry and a revocation flag, and is bound to one organisation, one opportunity and an explicit list of permissions.

Media is uploaded directly to object storage through short-lived pre-signed links; file contents do not pass through the API. Once an upload completes, the server re-reads the stored file's actual type and rejects it if it does not match what was declared, so a client's claim about its own file is never trusted. Size limits are enforced per media type.

Uploaded media, including application materials and self-tapes, is stored in EU-jurisdiction object storage under long, randomly generated object keys that are not listed, indexed or publicly linked. Within the product, application materials are shown only to the artist and to users with access to the relevant workspace or review. Cross-origin access to media is restricted to Lanced production origins. Message attachments and private thumbnails are delivered through authenticated endpoints.

Executed contracts are held in a separate storage bucket from ordinary media, and the API refuses to start if the two are configured to the same place. Video and image processing is likewise refused for anything in the private scope, so sensitive originals are never exposed to a processing pipeline in order to be processed.

Object storage is pinned to the EU jurisdiction, and that is the built-in default rather than a deployment setting that can be forgotten.

Casting is an industry where background and physical characteristics are genuinely part of a brief. We treat that data accordingly.

• Account and identity — name, email address and authentication identifiers. Credentials themselves are held by our authentication provider (§ 9), not by Lanced.
• Artist profile — biography, location, disciplines, styles, skills, training, career record and external links.
• Special category data (GDPR Art. 9) — ethnicity. Held alongside date of birth, nationality and gender in a dedicated table, separated from the main profile, protected by enforced Row-Level Security, and never loaded as part of an ordinary profile read.
• Physical characteristics — comp-card measurements and sizes, in their own table, completed only where the discipline calls for it.
• Media — photographs, video, self-tapes and application materials.
• Applications — answers, decisions, review history and the consent record described in § 7.
• Messaging — conversations, messages and attachments.
• Contracts — engagement terms, signature records and the executed document.
• Billing — payment provider references only. No card data ever reaches Lanced systems.
• Operational — audit records including IP address and user agent, and session records.

Sensitive profile fields are not shared with a company simply because they exist on a profile. Each application records its own consent at the moment it is submitted, listing exactly which sensitive fields the artist agreed to share for that application, together with a fixed snapshot of what was shared.

The company sees that snapshot as it stood at submission. This also means a later profile edit cannot silently rewrite the record of a decision already made.

Separately, artists control whether their profile is public, unlisted or private, whether they appear in search results, and whether their location is shown at all.

Companies can export and erase applicant data themselves, from the Privacy & GDPR settings in their workspace. Artists can delete their account from their settings. Deletion takes effect after a 30-day grace period, during which it can be cancelled, and is then completed by the Lanced privacy team. Artists can request a copy of their data at any time by writing to privacy@lancedhq.com.

The only case in which erasure is held is while a contract is actively awaiting signature, because that identity is required to complete a live signature workflow. The artist is told which contract is blocking it and can proceed once that contract is signed, declined, withdrawn or expired.

Erasure removes a person's identity, not merely their display name. Profile and sensitive fields are cleared, all sessions are revoked, uploaded media and message attachments are marked for deletion and physically removed from storage, and the person's identity in conversations is replaced with a non-identifying placeholder for the other participants. Applications an artist has already sent to a company are held on that company's behalf and are not removed by deleting the artist account. Requests to delete them are forwarded to the company.

Lanced engages a limited number of third-party service providers to operate the platform. Each processes personal data only on Lanced's documented instructions, under a written data processing agreement, and subject to an appropriate transfer mechanism where processing takes place outside the European Economic Area.

The current list of sub-processors, including their purpose, processing location and transfer mechanism, is maintained in the Lanced Sub-Processor Register at lanced.tech/legal/subprocessors. The register also lists providers Lanced has committed to but not yet engaged, so that customers receive notice before any personal data is transferred to them. Customers are notified of changes in accordance with the Data Processing Addendum.

Platform changes follow a pull-request workflow with review before merge. Continuous integration runs type checking, the test suite and a deployment-readiness verification on every change. A separate staging environment runs the same stack and receives every change before production; it is additionally served with headers preventing search indexing.

Production deployments require explicit human approval and take a compressed database snapshot before any schema change is applied; the most recent fourteen are retained. Geographically separated backup storage is on our security roadmap.

Application errors are reported to our error-monitoring provider in its EU data region (§ 9). Request logs redact authorization headers, cookies and known credential fields. Every meaningful action writes an append-only audit record carrying the actor, workspace, target, IP address, user agent and — where applicable — the staff member behind an assistance session.

Incoming notifications from our payment, email and signature providers are all cryptographically verified using constant-time signature comparison. The signature provider is fail-closed: if it is configured without a verification secret, the API refuses to start rather than accept unverified contract events. Repeated verification failures raise an alert. The API is rate-limited per client.

A written incident-response procedure covering detection, triage, containment, customer notification, recovery and post-incident review is maintained internally and reviewed at least annually. It is available to customers under NDA on request.

Incidents are assessed and escalated by the engineering lead, who holds the standing escalation role. Where a personal-data breach is confirmed, affected customers are notified without undue delay and in line with the Data Processing Agreement.