Trust and Privacy
Trust and privacy at Shedams
Shedams measures engagement, not fitness performance. We built the platform so that employers and creators can see that their people are building healthy habits without ever seeing how any individual trains, where they go, or anything about their health.
This page explains what your organisation can and cannot see, who helps us run the service, how to get a Data Processing Agreement, and how to report a security concern.
What your organisation sees, and what stays private
When your employer or community provides Shedams, they get a dashboard built for one purpose: to understand whether people are building healthy habits as a group. That dashboard is aggregate-only. It is designed so that no statistic can be traced back to an individual. Here is the line we draw, and we enforce it in the database itself, not just in the screens you see.
What your organisation can see (aggregate only)
Total seats: used vs available
How many licences are in use, for billing and planning
Number of active members
How many people are engaging, as a count, never a list of names
Organisation-wide participation rate
A single habit-formation figure for the whole organisation
Active challenges and completion rates by team
How challenges are going, summarised per team
Engagement trend over time
Whether engagement is rising or falling, as a curve
Team comparison (teams of five or more only)
How teams compare, but only where a team has at least five members
What stays private, always
Your name against any activity
The dashboard carries no individual names against activity data
Any single activity, route or session
No run, walk, ride or session is ever shown to your organisation
Where you go
No GPS, no location, no maps reach the organisation dashboard
Your health data
No heart rate, no PAR-Q health-screening answers, nothing of the kind
Distance, pace, calories or scores for you as an individual
Performance metrics are never traceable to a named person
Anything about a team smaller than five people
Small teams are suppressed entirely so no one can be re-identified
How we enforce this
This is not a setting an administrator can switch off. The protections are built into how the data is stored and queried.
- Aggregation at the database boundary. Organisation dashboards read from views and procedures that return counts and averages only. The raw, individual data is never exposed to the organisation query layer.
- A five-member suppression threshold. Any team or group statistic that would describe fewer than five people returns no result at all. This stops anyone working backwards to identify a single person from a small group.
- Audit logging on every read. Every dashboard query is logged, so access to organisation data can be reviewed.
- A privacy promise you can see at any time. When you claim your seat we show you exactly what your organisation can and cannot see, and you can return to that summary from your profile at any point.
Our subprocessors
To run Shedams we rely on a small number of trusted service providers, called subprocessors, who may process personal data on our behalf. We keep this list public and current. If you are a customer under a Data Processing Agreement with us, we will give you at least 30 days' advance notice before we add or replace a subprocessor that processes your data, so you have time to review the change.
| Subprocessor | Purpose | Data processed |
|---|---|---|
| Supabase | Database, authentication, storage, edge functions | Account identifiers, organisation membership and role, aggregated and individual activity and scoring data, encrypted PII |
| Stripe | Subscription billing and payments | Billing contact, payment metadata, subscription and seat status |
| Firebase / Google | Push notifications and mobile messaging | Device push tokens |
| Vercel | Web application and admin portal hosting | Request metadata for the web surfaces |
| Slack | Slack integration: digests and notifications, where the organisation enables it | Aggregate engagement summaries, challenge and leaderboard content |
| Microsoft / Teams | Microsoft Teams integration, where the organisation enables it | Aggregate engagement summaries, challenge and leaderboard content |
| Support tooling | Customer support ticketing | Support contact details and ticket contents |
| Email delivery provider | Transactional and invitation email | Recipient email address, invitation and notification content |
Customers under a Data Processing Agreement are notified of subprocessor changes in line with that agreement. To receive these notices, keep your administrator contact details current, or write to privacy@shedams.com to be added to the notification list.
Data Processing Agreement (DPA)
If your organisation is in the European Economic Area or the United Kingdom, or you simply want the protections in writing, we offer a Data Processing Agreement. It sets out how we process personal data on your behalf as your processor, and it incorporates our GDPR Article 28 obligations. For most customers our standard DPA is ready to sign as published, with no negotiation needed.
Request the Shedams DPAHow to put a DPA in place
- Request the DPA above and review it with your team.
- If our standard terms work for you, counter-sign and return to dpa@shedams.com.
- We will counter-sign and send you a fully executed copy for your records.
We honour our GDPR Article 28 processor obligations for EEA and UK customers from the day they start using Shedams, whether or not a separate DPA has been counter-signed yet.
Your individual data rights
Individual members can export their data or delete their account at any time from within the app. These tools let organisations meet data subject access and erasure requests without a manual process. If you need help, contact privacy@shedams.com.
Reporting a security vulnerability
We welcome reports from security researchers and from anyone who finds a potential security issue in Shedams. If you have found something, please tell us. This policy explains how to report it and what you can expect from us.
How to report
Email security@shedams.com with enough detail for us to reproduce and understand the issue. Where possible, please include a clear description of the vulnerability and the affected product, URL, endpoint or app version, step-by-step instructions to reproduce it, a proof of concept if you have one, and the potential impact as you see it.
What we ask of you
- Give us a reasonable amount of time to investigate and fix the issue before disclosing it to anyone else or to the public.
- Do not access, modify, or delete data that does not belong to you, and only interact with accounts you own or have explicit permission to test.
- Do not run attacks that degrade, disrupt, or take down our service, including denial-of-service, spam, or social-engineering of our staff or members.
- Do not exploit the issue beyond the minimum needed to prove it exists.
- Keep the details of any vulnerability confidential until we confirm it has been resolved.
- Comply with all applicable laws.
Safe harbour
If you make a good-faith effort to follow this policy when researching and reporting a vulnerability, we will treat your activity as authorised. We will not pursue or support legal action against you for accidental, good-faith violations of this policy, and we will work with you if a third party brings action against you for activity that complied with it. This safe harbour does not apply to activity that is malicious, that intentionally harms our members or their data, or that breaks the law.
What you can expect from us
We acknowledge reports, triage them with an indication of severity, give you regular updates while we work on a fix, and credit you with your consent once the issue is resolved. We do not currently run a paid bug bounty programme, though we may recognise significant reports at our discretion.
How we protect data, day to day
We do not display compliance badges or audit certificates, because at this stage we have not pursued formal certification. We would rather tell you plainly what we actually do.
- Encryption. Personal data is encrypted, and sensitive personal information is protected at the database layer so that day-to-day queries do not expose it.
- Least-privilege access. Staff access to systems is role-based and granted only where it is needed. We use single sign-on and enforce multi-factor authentication on our internal systems and vendor accounts.
- Strong engineering hygiene. We require code review before changes ship, run automated dependency vulnerability scanning, keep secrets out of code, separate our development, staging and production environments, and log administrative actions.
- Careful hiring. We carry out background checks at hire where lawful, and our staff complete a security orientation and sign a code of conduct.
- Vendor diligence. We review the security of any vendor that touches customer data before we onboard them, and we keep our subprocessor list public and current.
- Incident response. We maintain a documented incident response plan with customer-notification commitments, and we review our risks at least once a year.
Talk to us about security and privacy
- Report a security vulnerability: security@shedams.com
- Privacy questions, DPA requests, data subject requests: privacy@shedams.com
- General support: support@shedams.com