Stronger protections for sensitive intake data

Health screenings, signed waivers, date of birth, intake placement photos and finished-tattoo photos are encrypted at rest using AES-256-GCM, with a data key that is unique to your studio. Everything travels over encrypted connections. Other records and content types may be protected differently depending on their function in the service.

Encrypted sensitive intake content is intended to be viewable only by authenticated members of your studio through the product's authorised workflows, subject to role-based permissions — you, your managers, your front desk, and the artist on the booking. Your accountant's finance access can't see it. And Linebook's ordinary product, admin and support tooling is designed without a routine workflow to open that sensitive intake content — there is deliberately no ordinary screen, export or support function for Linebook personnel to browse your clients' health forms or intake placement photos.

To be clear: this is a statement about product architecture, access controls and ordinary operator tooling. It is not a claim that encrypted data is mathematically inaccessible to hosted systems whenever the service needs to process and display that data back to the authorised studio user — it's a claim about the access-control design and the absence of ordinary product, admin or support workflows for Linebook personnel to read that sensitive intake content.

Intake placement photos are automatically stripped of location and device metadata (EXIF/GPS), re-processed, then stored in encrypted form rather than at a public link. When you view an intake placement photo, it's decrypted on the fly through an authenticated route scoped to your studio. Clients are asked to frame the placement area only, without faces.

Finished-tattoo photos are handled the same way: re-encoded (which drops embedded metadata), encrypted at rest under a studio-scoped key, and served only through an authenticated route that re-checks permission on every request. A studio's client gallery link is authorised rather than public, so ending the share or deleting a photo also ends access through links already issued. Other image features — including portfolio and flash images, and client reference images — are different data classes and may follow different storage and delivery paths, including public blob URLs where a studio configures public display or sharing. In particular, client reference images may be stored substantially as uploaded and should not be treated as metadata-stripped unless Linebook expressly implements that processing for the relevant workflow.

We deliberately do not store photos of government ID — the highest-liability thing a studio could hold. Instead, your client attests they're 18 or older and that valid ID was shown; you record that check without keeping the document. Less risk for your clients, and for you.

Consent is captured as separate, specific opt-ins — health information, the waiver, and photos are each agreed to on their own, never bundled into one checkbox. That's designed to line up with laws like Washington's My Health My Data Act and Quebec's Law 25. You are the controller of your clients' data and Linebook is your processor; a Data Processing Agreement is available on request.

By default, sensitive intake is kept for about 7 years from a client's last service — aligned to the liability and limitation windows most studios need — then deleted; a studio can change this in its intake retention settings. Other data classes may have different retention periods. You can export your records anytime, and honour a client's erasure request. Because sensitive intake content is encrypted with studio-scoped keying, deletion can include key retirement or deletion as part of the deletion process, making the affected encrypted intake content no longer readable through the service once the applicable deletion steps complete.

Linebook relies on a small set of service providers for hosting, storage, security, email delivery, payments, analytics and optional integrations. Rather than duplicating or freezing that list here, we publish the current provider list, roles and available region information on our Subprocessors page.

We never sell your data and never use your clients' data for advertising or to train models.

If we identify a potential security incident affecting customer data, we assess and respond under our internal incident-response procedures and, where applicable, provide notices required by our contractual breach-notice obligations in the Data Processing Agreement.

We run a responsible-disclosure policy — if you're a researcher, that page has our scope, safe-harbour promise and how to reach us (also machine-readable at /.well-known/security.txt). We'd genuinely rather hear it from you.