Skip to main content
Basker

Security

Security

Last updated August 9, 2026

Basker is a multi-tenant content management system and website platform for arts and cultural organisations. It runs the public websites of some of the most recognised performing arts organisations in the world, and it is regularly assessed by enterprise IT and security teams as part of procurement.

This page sets out how we host, secure, and operate the platform. If you have a security questionnaire you would like us to complete, or a question this page does not answer, contact us at security@basker.io.

Certifications and Assessments

Basker does not currently hold a SOC 2 Type II or ISO 27001 certification. The controls described on this page are in place today, as we work towards formal certification.

We support security reviews in the following ways:

  • We complete security questionnaires and will take your IT team through our architecture in detail on request.
  • Every layer of our infrastructure runs on providers that hold independent certifications, listed under Infrastructure Providers below. Audit reports for each are available through their trust centres.
  • Our Data Processing Agreement is published openly, including the full list of sub-processors and the terms governing international transfers.
  • Our Service Level Agreement sets out support coverage, severity classification, and response-time commitments.

What Basker Holds

Basker stores the following categories of data on your behalf:

  • Website content. Pages, posts, articles, announcements, layouts, and reusable content blocks, including unpublished drafts and full version history.
  • Event data. Events, instances, seasons, series, works, venues, people, and organisations. Where you use a ticketing integration, this is the public event information synchronised from your ticketing system.
  • Media. Images, video, documents, and fonts uploaded to your sites, together with records of where each is used.
  • Design and theme data. Themes, colour schemes, component patterns, and deployment history.
  • Site configuration. Domains, redirects, search configuration, access restrictions, and site-level settings.
  • Accounts and access. Admin user accounts (name, email address, hashed credentials, multi-factor enrolment), roles, permissions, and collaborator records.
  • Operational records. Administrative activity logs, preview links, and subscription and billing records.

Basker does not store:

  • Cardholder data. Basker does not process, store, or transmit payment card data at any point.
  • Patron, member, or donor records. Ticketing, membership, and fundraising data stays in your ticketing system or CRM.
  • Form submission content. Responses submitted through forms you publish are delivered by email to the recipients you configure and are not retained in Basker.

Where a website embeds a checkout or donation flow, that flow is served by your ticketing provider and payment details pass directly between the visitor and that provider. Basker never receives them. We monitor the scripts served on pages carrying these embeds for unauthorised change, consistent with PCI DSS v4.

Hosting and Infrastructure

All production workloads and customer data are hosted on Amazon Web Services in the United States, with MongoDB Atlas as the managed database, itself running on AWS. Content is delivered worldwide through CloudFront's edge network.

  • Compute: AWS Lambda. The platform is fully serverless, with no long-running servers and no remote access to production hosts.
  • Content delivery: Amazon CloudFront.
  • Storage: Amazon S3 for media, themes, and assets.
  • Database: MongoDB Atlas, reachable only over AWS PrivateLink from within our private network. It is not exposed to the public internet.

Compute scales automatically with demand, with no manual provisioning.

Platform Security

Several security properties are structural to how Basker is built rather than added afterwards:

  • Separation of planes. The admin CMS and the public website are separate systems. The public site serves read-only traffic: only GET, HEAD, and OPTIONS requests are accepted at the CDN.
  • Isolated form handling. Website forms submit to a single dedicated endpoint with server-side validation, input sanitisation, and reCAPTCHA bot protection available per site.
  • Tenant isolation. Every query in the platform is scoped to your tenant, and staff access can be restricted to individual sites within your organisation.
  • Network isolation. Platform components run in a private network, with database and internal services unreachable from the public internet.
  • Denial of service protection. Network and transport layer DDoS protection is provided by AWS Shield, included with CloudFront across all sites.
  • Web application firewall. AWS WAF is deployed in front of public traffic, with AWS managed rule sets covering common web exploits and known bad inputs, IP reputation filtering, scanner and probe detection, and per-IP rate limiting. Rules are calibrated against live traffic in monitoring mode first, with enforcement and coverage rolled out in stages.
  • Rate limiting. Programmatic API access is authenticated and rate limited.
  • Encryption in transit. All traffic is served over HTTPS, with certificates managed through AWS Certificate Manager and plain HTTP redirected.
  • Encryption at rest. Data is encrypted at rest in both MongoDB Atlas and Amazon S3.
  • Secrets management. Credentials are held in a managed secrets store, encrypted at rest, and are never committed to source control or embedded in configuration.
  • Email authentication. Outbound mail is authenticated with SPF and DKIM, with a DMARC policy enforced against spoofing of our domains.
  • Infrastructure as code. Every environment is defined in code and deployed through the same tooling, so environments are reproducible and infrastructure changes are reviewed like application changes.

Access Control

  • Multi-factor authentication is available on all admin accounts, using authenticator apps (TOTP) or email one-time codes.
  • Role-based access governs what each team member can see and do, and access can be scoped to individual sites.
  • Credential protection. Passwords are stored hashed and salted, never in recoverable form, and repeated failed sign-in attempts temporarily lock the account.
  • Session expiry. Admin sessions expire automatically and require re-authentication.
  • Audit logging. Administrative actions are written to an append-only activity log recording the actor, action, affected resource, and timestamp. The log cannot be edited through the application.
  • Version history is retained for all editorial content, so changes can be attributed, reviewed, and rolled back.
  • Production access is restricted to named engineers on a least-privilege basis and reviewed when roles change.

Backups and Recovery

  • Database. MongoDB Atlas takes automated snapshots of the production database every six hours, retained on a rolling schedule: daily snapshots for 7 days, weekly for 4 weeks, and monthly for 12 months. Continuous backup additionally allows the database to be restored to any chosen point within the preceding 7 days, so worst-case data loss from an incident is measured in minutes rather than hours.
  • Media and assets. Held in Amazon S3, which is designed for 99.999999999% (eleven nines) durability across multiple facilities.
  • Recoverability. Because all infrastructure is defined as code, the platform can be rebuilt from source into a fresh environment, and backups are restored into an isolated environment when verification is required.

Monitoring and Incident Response

  • Monitoring. Sentry monitors errors and performance across all environments, with production isolated from development noise, and alerts routed to the engineering team.
  • Dependency management. Dependencies are monitored continuously for known vulnerabilities through GitHub Dependabot alerts, and prioritised for update by severity and exploitability.
  • Patching. Operating system and runtime patching is handled by AWS as part of the serverless platform. Security fixes are released outside the normal cadence when severity requires it.
  • Incident communication. If an incident affects your service or personal data, we will notify you without undue delay, as committed in our Data Processing Agreement. Emergency support is available 24/7 under our Service Level Agreement.

Secure Development Lifecycle (SDLC)

Security is handled throughout development rather than as a gate at the end:

  • Secure by design. New features are assessed for security and data protection impact as part of design, before implementation begins. Tenant isolation and access control are decided at that point, not retrofitted.
  • Peer review. Every change is tracked in version control and reviewed by another engineer before it reaches the main branch. Nothing is edited directly in production.
  • Automated security review by frontier AI models. Alongside human review, every change is analysed for security defects by dedicated AI security review tooling, using frontier models from Anthropic and OpenAI. These reviews look for injection flaws including SQL, command, and cross-site scripting; broken authentication and authorisation, such as a query that escapes tenant scoping; unsafe handling of user input; credentials or secrets committed in error; server-side request forgery; and unsafe cryptographic or dependency use. Findings are reported with the exact location and remediation guidance, for an engineer to resolve before merge.
  • Automated verification. Linting, type checking, unit tests, and end-to-end browser tests run against changes before release.
  • Environment isolation. Development, staging, and production run as fully isolated stacks with separate credentials and data. Changes are validated outside production before promotion.
  • Controlled releases. Releases are small and incremental, rolling out every few weeks. We avoid large consolidated releases, and do not deploy on Fridays or at weekends except for urgent fixes.
  • A single codebase. Every customer runs the same continuously updated codebase. There are no per-client forks left to drift, so a security fix reaches every customer at once.

Data Protection

Basker Ltd is registered in England & Wales (No. 15505527) and processes personal data in accordance with UK GDPR and the Data Protection Act 2018.

Our standard Data Processing Agreement governs how we process personal data on your behalf, and covers sub-processors, international transfers under the applicable Standard Contractual Clauses, breach notification, audit rights, and retention and deletion on termination. It is published in full on this site and available to sign as part of contracting. Everyone at Basker with access to customer data is bound by confidentiality obligations.

Separately from those contractual terms, your content remains portable throughout: you can export it at any time through the Basker API and the built-in export tooling, without needing to ask us.

Infrastructure Providers

Basker runs on providers that maintain industry-standard certifications:

  • Amazon Web Services (hosting, compute, storage, content delivery, email): ISO 27001, SOC 1/2/3, PCI DSS.
  • MongoDB Atlas (managed database): ISO 27001, SOC 2 Type II.
  • Stripe (subscription billing): PCI DSS Level 1, SOC 2.
  • GitHub (source control): SOC 2.
  • Sentry (error monitoring): SOC 2 Type II.
  • Intercom (customer support): SOC 2 Type II.
  • Google (reCAPTCHA bot protection): ISO 27001, SOC 2.
  • Loops (email delivery): SOC 2.
  • OpenAI (AI features): SOC 2 Type II.
  • Anthropic (AI features): SOC 2 Type II.

The authoritative list of sub-processors, including what each processes and where, is maintained in Appendix 2 of our DPA.

Reporting a Vulnerability

If you believe you have found a vulnerability in Basker, email security@basker.io. We will acknowledge legitimate reports promptly, keep you updated while we investigate, and prioritise fixes according to severity.