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.

Sensitive material — application materials, self-tapes, message attachments and contract documents — is held in a private scope. It is never given a public address, is served only through links that expire after ten minutes, and in the case of message attachments and private thumbnails is delivered through an authenticated endpoint instead. File identifiers are random. Publicly reachable media is limited to what an artist has chosen to publish on their own profile or portfolio.

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.

Export and erasure are self-service inside the product, not an email request queue. An erasure request is accepted immediately. The only case in which it 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 and authored content, not merely their display name. Messages they wrote are emptied and unlinked, their attachments are marked for deletion, and their participant identifier and read receipts are stripped from conversations. What remains for the other participants is a non-identifying placeholder.

Lanced engages a small number of sub-processors — for application hosting and the managed database, EU-pinned object storage and media delivery, authentication and credential hosting, payment processing, electronic signature, transactional and marketing email, error monitoring, and location autocomplete. Each processes personal data only on our instructions and under a written data processing agreement.

The full register — every engaged and planned sub-processor with its purpose, location and transfer mechanism — forms part of our Data Processing Agreement and is maintained in one place: the Sub-Processor Register in our Trust Center. That page is the authoritative and current list. Customers are notified before a new sub-processor is engaged, and planned providers are published there in advance, before any data moves to them.

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.