SixSides

SixSides Security Policy

As an event and community platform that serves organisers, attendees, speakers, sponsors and the organisations behind them, we know we’re looking after important community data, not just “app content”.

This page summarises how we consider security across our web and mobile apps, public API and marketing site. For information on what data we collect and why, please see our Privacy Policy.

General practices

  • Access to production infrastructure, source code and third-party tools is protected with strong authentication (including multi-factor authentication wherever supported).
  • We use strong, randomly generated passwords via a password manager and never reuse passwords across systems.
  • Team members are granted the minimum level of access they need to perform their role (principle of least privilege).
  • Only a small subset of staff can access production systems and data, and such access is logged.
  • We do not copy production data to personal devices. Any use of production data for support or debugging is time-bound and logged.
  • We use automated tools to alert us to known security vulnerabilities in our dependencies and keep our stack patched.

Access control and organisational security

Personnel

  • Employees and contractors sign confidentiality agreements (NDAs) before they can access sensitive systems or data.
  • We follow a structured onboarding and offboarding process to grant and revoke access to our systems.
  • Access to production infrastructure is restricted to specific roles (for example, a small engineering and operations group).

System access

  • Access to AWS, Cloudflare, source control, CI/CD, analytics and error monitoring is protected with individual accounts.
  • Multi-factor authentication (MFA) is enforced wherever the provider supports it.
  • Shared accounts are avoided; where a shared credential is unavoidable (for example, legacy integrations), it is stored in a shared password manager.

Devices

  • Company laptops use full-disk encryption and OS-level authentication (password and/or biometrics) with automatic screen lock.
  • Team members are required to keep operating systems and browsers up to date with the latest security patches.

Authentication & account security

SixSides supports different types of users, including organisers, sponsor and speaker contacts and event attendees.

  • Users authenticate to the SixSides dashboard and apps using email-based logins (for example email + password or secure email links).
  • Where passwords are used, they are hashed with industry-standard password hashing algorithms. Passwords are never stored in plain text.
  • Sessions are time-limited and will expire after a period of inactivity, requiring the user to log in again.
  • Changing an account password invalidates existing sessions.
  • Within a customer organisation, role-based access controls (RBAC) are used so that:
  • Organiser admins can manage events, attendees and configuration.
  • Organiser staff can manage event-level operations with narrower permissions.
  • Sponsor users are limited to the events and data they have been granted access to (for example, attendees who have engaged with their sponsor presence or expressly opted in).
  • Attendees can only see their own profile, their interactions and the content made available to them by the organiser.

Infrastructure & hosting

Core application

  • The SixSides application is built on a Laravel backend running on AWS Lambda via Vapor, behind Cloudflare.
  • We currently operate in ap-southeast-2 (Sydney) and eu-central-1 (Frankfurt) AWS regions for our core application and MySQL databases.
  • All external traffic is proxied through Cloudflare Workers, which operate at Cloudflare’s global edge locations.

Data storage

  • Relational data (for example, events, user profiles, attendance, engagement data) is stored in serverless MySQL databases on Amazon RDS.
  • Media (such as photos and videos captured at events) is stored in Cloudflare R2 object storage.
  • We use Amazon ElastiCache Redis in each region for caching and short-lived session or queue data.

Environments

  • We maintain separate development, staging and production environments, with separate resources for each environment.
  • We do not copy production data into lower environments. Test data is used instead.

Encryption

In transit

  • All communication between clients (web, mobile, API consumers) and SixSides services is encrypted in transit using HTTPS (TLS).
  • Traffic from the edge (Cloudflare) to our AWS infrastructure is also encrypted.

At rest

  • Databases hosted on Amazon RDS are configured with encryption at rest using AWS-provided mechanisms.
  • Media stored in Cloudflare R2 is encrypted at rest using Cloudflare’s storage encryption.
  • Backup snapshots are encrypted at rest.

Data we collect and how we use it

SixSides is designed around the five sides of an event community: organisers, attendees, speakers, sponsors and the head organisation. We only collect data needed to deliver and improve the service.

Attendees

We may store:

  • Name and email address
  • Optional profile information (bio, role, organisation, social links)
  • Optional phone number
  • Session registrations, check-ins and attendance history
  • Questions, poll responses, ratings and survey responses
  • Media they upload (such as photos) or appear in
  • Interest flags (for example, indicating interest in a particular sponsor, track or topic)
  • Optional 1:1 meeting notes between attendees and sponsors/organisers where the feature is used

Speakers

In addition to attendee-style data, we may store:

  • Speaker profiles (bio, headshot, links)
  • Session information (talk titles, abstracts, timings)
  • Links to external content such as slides or repositories

Sponsors

For sponsors we store:

  • Sponsor organisation details
  • Named contacts (name, email, optional phone and role)
  • Sponsor presence at specific events (booths, activations, offers)
  • Interactions and leads generated through SixSides (for example, attendees who scan a QR code, join a session or express interest)

Organisers and host organisations

We may store:

  • Admin and staff accounts (name, email, role and access level)
  • Event configuration, branding and content
  • Aggregated analytics on event performance and community engagement

What we do not do

  • SixSides does not handle payments or ticketing at this time, and we do not process card data.
  • We do not sell personal data or use it for third-party advertising networks.

Data flows (high-level)

At a high level:

  • Users access SixSides via the web, mobile apps or links embedded in event communication.
  • All requests go through Cloudflare’s edge network and Workers, which handle TLS termination, routing and security protections.
  • Requests are forwarded to the SixSides backend in AWS, where the application logic runs on Lambda (Vapor).
  • The backend reads and writes event data to MySQL on RDS and stores/retrieves media from Cloudflare R2.
  • Analytics and error events are sent to:
  • Sentry for error tracking
  • Fathom Analytics for privacy-friendly web analytics
  • Internal logs (for example, CloudWatch and Cloudflare logs) for operational monitoring

Data retention & deletion

  • We retain event-related data (including content, engagement and analytics) for at least 12 months after an event.
  • Where a customer remains active and subscribed, we retain historical data to:
  • Help them understand year-on-year trends
  • Support re-use of content
  • Make it easier to configure and launch future events
  • Individual users can:
  • Edit their profile information
  • Delete media they have uploaded
  • Organisers can request:
  • Deletion of an event’s content
  • Removal of specific media assets that no longer have a legitimate purpose

We will work with customers who have specific contractual or regulatory retention requirements.

Logging, monitoring & IP addresses

  • We log application and infrastructure events in AWS CloudWatch and through Cloudflare Workers to help us operate, secure and improve the platform.
  • Logs may include IP addresses, user identifiers and device/browser information.
  • Log data is retained for a finite period and then automatically deleted. We aim to retain logs long enough to investigate incidents and detect abuse, but not longer than necessary.
  • Security-relevant events (for example, elevated error rates, deployment issues) are monitored and alert the team.

Software development practices

  • All changes to our codebase go through version control and pull requests.
  • Changes are reviewed by at least one other team member before being merged.
  • Automated tests and checks (such as unit and integration tests, linting and static analysis) run in continuous integration.
  • Code is deployed via automated deployment pipelines to staging and then production.
  • The production environment is configured using infrastructure-as-code wherever practical, so it can be reproduced and audited.

Secrets management

  • Secrets such as API keys and database credentials are stored in managed secret stores or encrypted environment variables provided by our cloud platform.
  • Secrets are never committed to source control.

Vulnerability management

  • We use automated tooling (for example, dependency scanners and security alerts in our source control platform) to detect libraries with known vulnerabilities.
  • When a critical or high-severity issue is identified in our stack, we prioritise upgrading and redeploying the affected services as quickly as possible.
  • We keep our operating environment (for example, runtime versions, base images) reasonably up to date.

Penetration testing & third-party review

  • As a growing team, we are working towards regular third-party penetration tests of the SixSides platform.
  • In the meantime, we follow secure-by-default practices in our architecture (for example, managed cloud services, least-privilege IAM roles, limited network surface).

Reporting vulnerabilities

If you believe you’ve found a security issue in SixSides, please contact us at security@sixsides.co (or your preferred security contact email). We ask that you:

  • Provide enough detail for us to reproduce the issue
  • Give us a reasonable time to investigate and address it before any public disclosure

Mobile apps & permissions

SixSides is designed to be used on-site at events, so our mobile apps play a big role.

  • Our mobile apps are distributed via the official app stores for iOS and Android.
  • On device, we store only the minimum information needed for the app to function and rely primarily on the server for data storage.

Permissions

Depending on the feature set in use, SixSides may request permissions such as:

  • Camera – to allow attendees and staff to scan codes or capture photos and videos in-app.
  • Photo library – to allow users to upload existing photos.
  • Push notifications – to notify attendees about important event updates, schedule changes, or engagement prompts.

We do not request precise location or contact list access for normal operation of the app.

Compliance & legal

  • SixSides is not currently certified under frameworks such as SOC 2 or ISO 27001.
  • We design our controls with industry best practices in mind (for example, secure development practices, least-privilege access and encryption in transit and at rest).
  • Our handling of personal information is guided by applicable privacy laws and regulations in the markets we serve (for example, Australian privacy law and, where applicable, GDPR-style principles).
  • We act primarily as a data processor for event data, with event organisers acting as the data controller. For our own marketing and sales operations, we act as a controller.

If you are an enterprise customer and require specific contractual commitments (for example, data processing agreements or regional hosting guarantees), please contact us.

Third-party providers

SixSides uses reputable third-party providers to deliver our service, including:

  • Amazon Web Services (AWS) – hosting of our core application, databases, cache and logging.
  • Cloudflare – global edge network, DDoS protection, TLS termination, Workers and R2 media storage.
  • Sentry – application error monitoring.
  • Fathom Analytics – privacy-focused analytics for our marketing site and, where configured, parts of the app.

We maintain an up-to-date internal list of subprocessors. Enterprise customers can request this list as part of their vendor assessments.

Frequently asked questions

Where is our data stored?

Our core application and databases run in AWS regions ap-southeast-2 (Sydney) and eu-central-1 (Frankfurt). Media files are stored in Cloudflare R2 and served globally via the Cloudflare edge network.

Who can see attendee data?

Within a given event:

  • The event’s organisers and authorised staff can see attendee data relevant to running the event (such as registrations, check-ins and engagement).
  • Sponsors only see the attendees and interactions that relate to their sponsor presence (for example, people who scan their QR code, visit their booth page or explicitly indicate interest), according to the configuration chosen by the organiser.
  • Attendees can see and control their own profile and content.

Do you sell our data?

No. SixSides does not sell customer or attendee data and does not share it with third-party advertisers.

Can we delete an event and its content?

Yes. Organisers can request deletion of an event and its associated content and engagement data. We will honour such requests in line with contractual and legal obligations.

Individual users can also delete their own uploaded media and update or remove profile information.

How do I report a security concern?

Please email security@sixsides.co with details of the issue. We’ll review it, prioritise it appropriately and get back to you.

Any further questions?

Great! Please email us and we’ll happily update this doc.