Security at Showrunner

Showrunner runs the production, advancing and ticketing workflows of live-music venues and promoters. That means we hold booking correspondence, contracts, riders — which can contain special-category personal data — and, through ticketing, the personal data of ticket buyers. This page describes, in technical terms, how that data is protected: where it lives, who can reach it, what we inherit from our infrastructure providers and what we build and enforce ourselves.

We keep this page honest rather than impressive. Where something is not yet in place, we say so and say what is planned. Changes are listed at the bottom.

Contact: security@showrunner.it · /.well-known/security.txt

1. Our approach: shared responsibility, stated precisely

We run on infrastructure providers that hold independent certifications (SOC 2 Type II, ISO 27001, PCI DSS). Their reports cover physical security, network, host patching, encryption at rest and platform availability. They do not cover our application — tenant isolation, access control, how we handle your files and who can see them are our responsibility, and that is what most of this page is about.

Vendor policy. Every subprocessor we use must (a) hold SOC 2 Type II or ISO 27001, (b) offer EU data residency where the service allows it, and (c) have a data-processing agreement in place. The current list, with regions and certifications, is in section 3 and mirrors the subprocessor list in our Privacy Policy.

2. Architecture and data residency

Data flow in one paragraph: a venue forwards a booking email to its Showrunner address; Google Workspace routes it to Mailgun (EU), which delivers it to our ingestion service (Railway, EU); the service verifies the sender, archives the raw message and attachments in Supabase Storage under the venue's own storage prefix, and — if the workspace has AI extraction enabled — sends the text and attachments to Amazon Bedrock in Frankfurt for structured extraction; the result becomes a draft record in the venue's workspace for a human to review.

On the CLOUD Act. Our infrastructure providers are US-headquartered companies operating EU regions. This is the same posture as essentially every EU-region hyperscaler workload; we do not claim it is a legal nullity, and we address transfers contractually in the DPA.

3. Subprocessors and inherited controls

Anthropic (the model vendor) does not receive customer data: on Amazon Bedrock, model providers have no access to the AWS accounts in which inference runs.

4. Our controls — tenant isolation

Isolation between venues is enforced at the database, not only in application code:

• Row-Level Security on 100% of tenant tables. Every table holding venue data carries an RLS policy bound to active membership (has_active_membership). A deactivated member loses read and write access the moment their membership is deactivated, including to contract requests, advance requests, invoices, tours and contract templates.
• Every SECURITY DEFINER function has a pinned `search_path`.
• Storage is venue-prefixed. Every object lives under venue/{venue_id}/…, and every read route requires the object path to fall under the caller's own venue prefix before it will sign a URL. This prefix is the isolation boundary for files.
• Service-role routes are venue-scoped and permission-checked. Server routes that use elevated database credentials resolve the caller's venue and named permission (records_delete, financials_edit_fees, …) before acting; companion deletes (audit log, notifications) are scoped to the same venue.
• Platform administration is a separate console. Impersonation sessions are audit-logged and expire after four hours; requests from the console to the ticketing service carry an explicit signed platform-admin claim.

5. Authentication and access

• Venue users authenticate with Supabase Auth (email + password). Roles are named permission sets; permissions are enforced server-side, not only in the UI.
• Platform administrators authenticate with Google SSO; all platform-administrator accounts have Google 2-Step Verification enabled.
• Multi-factor authentication for venue users is not yet available (see roadmap).
• Door scanning devices are provisioned by signed QR; per-device access can be revoked centrally; a global master PIN protects device setup.

6. Encryption and integrity

• TLS 1.2+ for all traffic; HSTS enabled. AES-256 encryption at rest (Supabase/AWS).
• Every inbound webhook (email ingestion, Stripe) is signature-verified with constant-time comparison and fails closed if the secret is missing.
• E-tickets carry an Ed25519 signature; scanners verify the signature before any lookup, so QR codes cannot be forged or enumerated.
• Secrets live only in platform environment configuration; no server secret is present in any client bundle.
• Browser security headers on every page: HSTS, X-Frame-Options, nosniff, Referrer-Policy, Permissions-Policy (camera only on scanner routes) and a Content-Security-Policy with per-request nonces — currently deployed in report-only mode during a monitoring window, with enforcement scheduled for 24 August 2026.

7. Payments

Ticket sales run on Stripe Connect. The venue or promoter is the seller of record; Showrunner processes the tickets. Card data is entered into Stripe-hosted elements and never touches Showrunner's servers (PCI DSS SAQ-A posture). Prices and quantities are enforced server-side; the browser never supplies an amount.

8. AI processing

• What is sent: booking correspondence, attachments and images that a venue submits for extraction, and — for the in-app assistant — the conversation and the workspace data it is asked about. Never ticket-buyer data, payment data or your contact lists.
• Where: Amazon Bedrock, Frankfurt (eu-central-1), on an EU-geography inference profile. Processing does not leave the EU.
• Training: Per AWS: “With Amazon Bedrock, your content is not used to improve the base models and is not shared with any model providers.”
• Opt-out: every workspace can switch AI extraction off in Settings. Inbound mail is then received and filed with its attachments; no model call is made.

9. GDPR

• Roles. For venue and ticket-buyer data, the venue (or promoter) is the controller and Showrunner the processor. For your account and billing data, Showrunner is the controller.
• DPA: /dpa — general subprocessor authorisation with 30 days' advance notice and a right to object; flow-down of obligations; third-country transfers stated explicitly.
• Retention (summary — /privacy §5 is authoritative): raw inbound email is deleted 90 days after processing; files attached to a show follow that show's lifecycle; workspaces that lapse are archived and then erased on the schedule in the Privacy Policy; invoicing records are held by Stripe for 5 years under the Danish Bookkeeping Act.
• Erasure: venue deletion is a two-stage process that removes database rows and every stored object under the venue's storage prefix, with an audit record.
• Special-category data: riders can contain health information (allergies, medical needs). They are held under the same venue-prefixed isolation as contracts; downloads are logged.
• Breach process: we notify affected controllers without undue delay and within the 72-hour window in Art. 33; contact security@showrunner.it.

10. Operations

• Backups: manual pg_dump snapshots weekly and before every schema change; a restore drill was last run on 17 Aug 2026 against a production backup (all 75 tables row-count-verified). There is no point-in-time recovery yet; it arrives with our database plan upgrade at the first paying customer.
• Audit trail: significant actions are written to an append-only event log per venue.
• Logging: application logs are retained by the hosting provider for a short window; CSP violation reports are stored for 60 days without query strings or tokens.
• Change management: all changes ship through a review step and a staging deployment before production; production schema changes are additive and shipped with rollback scripts.
• Incident response: security@ is monitored; incidents are triaged, contained, and affected customers informed per section 9.

11. Security review before launch

Before onboarding any customer, we put the platform through two internal, adversarial security reviews (July and August 2026) covering the application, ticketing and ingestion codebases, plus read-only checks of the production database configuration — the same approach a penetration tester would take, run against a system that did not yet hold customer data. Every finding was remediated before launch, and the fixes are part of the controls described on this page (database-layer isolation, venue-prefixed storage, signed service-to-service calls, hardened webhooks).

We repeat this exercise on every major release. A third-party penetration test is the next planned investment.

12. Vulnerability disclosure

Report vulnerabilities to security@showrunner.it (/.well-known/security.txt). We commit to acknowledging within 3 business days and to keeping you informed. Good-faith research that respects user data and availability will not be met with legal action. Please do not access data that isn't yours, and do not run automated scans against production checkout.

13. Certifications and roadmap

Showrunner itself holds no certification yet — we are a small company and have chosen to spend on controls before badges. Our providers' certifications are listed in section 3. Planned, in order: enforce CSP; third-party penetration test; venue-user MFA; point-in-time database recovery; ISO 27001 when a customer's procurement requires it.

14. Changelog

• 17 August 2026 — first publication.