Privacy Policy

1. About this Policy

Inteleforge Limited, trading as The SBK Dance (“we,” “our,” “us”), is the data controller responsible for your personal data. This Privacy Policy explains how we collect, use, disclose and safeguard your information when you use our dance-event management platform, website and related services (collectively, the “Service”).

This is the enterprise edition of the Policy: Part 2 is organised by app module so the disclosures map one-to-one to features of the Service that you can verify for yourself in the public source code.

2. Who we are (legal entity, DPO, EU representative)

Companies Act 2006 §82 disclosure. Inteleforge Limited is registered in England & Wales under company number 16661156. Registered office: 34 moray close, Darlington, DL1 3TH, United Kingdom.

Data Protection Officer (DPO). We have not appointed a DPO. Our processing does not meet the threshold conditions in Article 37 UK GDPR. Privacy questions are handled by our Privacy & Compliance Officer at support@thesbkdance.com.

Territorial scope. The Service is operated from the United Kingdom and is available globally. The controller is established in the UK and is registered with the UK Information Commissioner’s Office; UK data-protection law (UK GDPR + Data Protection Act 2018) governs the controller’s processing. Where users are located outside the UK, additional national privacy laws may also apply to that user’s personal data (for example, EU/EEA GDPR for users in the European Economic Area, CCPA/CPRA for users in California, LGPD for users in Brazil, DPDP Act for users in India). We rely on the rights and protections in those laws in addition to UK GDPR; users may exercise their statutory rights directly with the controller using the contact details above. Users are responsible for ensuring that their use of the Service complies with any laws applicable to them locally.

3. Applicable laws

We process your personal data in accordance with:

• the UK Data (Use and Access) Act 2026 (the “2026 Act”);
• the UK General Data Protection Regulation (UK GDPR);
• the Data Protection Act 2018;
• the Privacy and Electronic Communications Regulations 2003 (PECR);
• the Consumer Rights Act 2015 and the Consumer Contracts Regulations 2013 (where you transact with us as a consumer);
• the Equality Act 2010 (accessibility, see §20);
• HMRC and Companies Act 2006 record-keeping rules (financial retention, see §13).

3a. What we do NOT do with your data

Some of the most important commitments we can make are about what your data is not used for. The paragraphs below apply across every app module described in Part 2.

3a.1 No AI / machine-learning training

We do not use your personal data to train any artificial- intelligence or machine-learning model - neither our own nor anyone else’s. Specifically:

• Account information (email, name, phone, role) is never used as AI training data.
• User-generated content (events, reviews, profile bios, photos) is never fed into LLM training datasets or generative-AI fine-tuning runs.
• Booking, payment and activity records (RSVPs, follows, saves) are never sold or shared with data brokers for training purposes.
• Our sub-processors (named in §11) are contractually prohibited under our Article 28 processing agreements from using the data they receive to train their own AI products beyond the specific service they perform for us.

If we ever introduce an AI- or ML-powered feature that would require this position to change, we will (a) publish a new version of this Policy describing the feature, the data involved, the lawful basis, and the third-party model; (b) obtain explicit opt-in consent from you before any of your data is used; and (c) continue to honour your right to object (Art. 21) and your right not to be subject to solely-automated decisions (Art. 22). The only automated risk-scoring on the Service today is Stripe Radar (see §6.5 / §21), processed by Stripe under their own Article 28 terms; we do not contribute training data.

3a.2 No third-party analytics, advertising or behavioural tracking

We do not run Google Analytics, Vercel Analytics, Hotjar, Mixpanel, Amplitude, PostHog, Meta Pixel or any equivalent tool. We do not perform automated profiling that has legal effects on you. We do not show advertising on the Service.

3a.3 Anonymised & aggregate statistics

We compute and publish aggregate statistics about the Service (total event count, total user count, total bookings since launch) on the homepage and at the public endpoint /api/stats. These figures are anonymised before publication: the aggregation step strips every personal identifier and the published numbers are pure counts that cannot be linked back to an individual.

Under UK GDPR Recital 26, truly anonymised data falls outside the scope of data-protection law. Even so, we disclose the practice here for transparency. We do not publish per-organiser, per-region or per-time-window breakdowns that could re-identify users at scale.

3a.4 No A/B testing or feature experiments on production users

We do not currently run A/B tests, feature flags or experimental rollouts that segment production users into differential-experience cohorts affecting substantive functionality (i.e. you and another user, on the same plan, see the same booking flow, the same pricing, the same Pro unlocks, the same Maps gate). Every product feature you see is the same feature every other user sees, with the disclosed exceptions of (a) role-based UI (Teacher vs. Attendee), (b) Pro subscriber unlocks, and (c) admin-only tools.

We may from time to time test wording variations on marketing emails, transactional email subject lines, or static-content layouts that do not affect the data we collect or the contractual experience - these marketing-optimisation tests are common across the web and do not segment users by personal data. If we begin A/B testing of substantive features, we will document the lawful basis, the data collected per-cohort and the opt-out path before running any experiment. We will not retroactively enrol existing users in a cohort without notice.

4. Account Registration & Data We Collect(Module: Identity & Profile)

What this section discloses. Exactly what profile information we collect when you sign up or update your account, who can see each field, and the technical measures protecting it.

4.1 What we collect at signup

• Email address (primary identifier).
• Password - never stored in plain text. Hashed using bcrypt at cost factor 10.
• OR Google OAuth profile data (name, email, profile picture) if you sign up with Google.
• Display name.
• Account role (Attendee / Teacher / Organizer / Admin) - chosen at signup.
• Phone number - required for Teacher/Organizer accounts; optional for Attendees. Verified via SMS OTP through Twilio.
• Marketing-consent flag - opt-in only at signup; off by default.
• Optional referral code (see §8).

4.2 What you can add later

• Avatar / profile photo.
• Bio (Teachers/Organizers only - see §5 for visibility).
• Dance styles, location, social-media links (Teachers/Organizers).
• Saved events, RSVP history, follow relationships.
• Reviews and 1–5 star ratings of events you attended.

4.3 Visibility matrix

4.4 Technical safeguards

• Session tokens (sb-access-token, sb-refresh-token) are stored in HttpOnly & Secure cookies - JavaScript on the page cannot read them, eliminating the most common XSS-based account-takeover vector.
• Passwords are hashed by Supabase Auth (the platform manages the bcrypt cost - currently 10 minimum; under a constant industry uplift programme). Plaintext is held only briefly during the request that authenticates you, then discarded. We never log plaintext passwords or the hashes themselves at any layer of our stack - verified by the redaction rules in src/lib/log-scrub.ts.
• CSRF protection: every state-changing request requires a double-submit token (csrf-token cookie + x-csrf-token header).
• Database access is restricted by Supabase Row-Level Security (RLS) policies - your row is only readable by the holder of your JWT.
• Audit logs capture authentication events (sign-in method, IP, user agent, timestamp). Retained 12 months (see §13). Available to you on subject access request (§17).
• Rate limiting on signup and login endpoints to prevent credential stuffing.

Security features not yet shipped (on our roadmap). The following industry-typical protections are not currently available on the Service. We disclose them here so you can make an informed choice and so a regulator can see we’re aware of the gap:

• Multi-factor authentication for non-admin users. Admin accounts are MFA-protected (§4.6 R9). Regular Attendee / Teacher / Organizer accounts are not yet offered TOTP or passkey enrolment. Roadmap: 2026.
• New-device / new-country sign-in alerts. Industry leaders (Monzo, Stripe) email or SMS users when a sign-in originates from an unusual location or device. We do not currently send such alerts. Until we do, the best mitigation available to you is to use a strong unique password (we check against the HIBP breach list), and to contact support@thesbkdance.com immediately if you suspect compromise.

4.5 Lawful basis

Account creation, authentication and profile management are processed on the basis of contract performance (Article 6(1)(b) UK GDPR) - without these data we cannot provide the Service you asked for. Phone-number verification is also contract performance. Marketing-consent flag is processed on the basis of your consent (Article 6(1)(a)).

4.6 Module risk register & mitigations

We publish below the full identity-and-account threat surface the Service has been designed against, with the mitigation in place for each. This is unusually transparent for a privacy notice - most operators keep this in an internal DPIA - but we believe it is the clearest way to show users (and any regulator reviewing this Policy) that our Article 32 UK GDPR “appropriate technical and organisational measures” are concrete, not slogans. The same register, with internal-risk scoring, is maintained as part of our DPIA (see §18).

A. Account & authentication threats

B. Subscriptions, billing & Stripe-integration threats

C. Data isolation & API protection threats

D. GDPR & regulatory threats

This register is reviewed and refreshed during the DPIA review cycle (annually, or sooner on a new vendor / new processing purpose / material change in UK data law). The internal DPIA carries the same risks with likelihood × severity scoring; this Policy lists only the public-facing mitigation. If you spot a risk we’ve missed, please email support@thesbkdance.com - we want to know.

5. Public Profiles & Marketplace Disclosures(Module: Directory Engine)

What this section discloses. When you create an Event listing, a Teacher profile, or leave a public review, the content becomes part of a public marketplace anyone can read without an account. This is the price of using a discovery platform; we want you to understand it explicitly.

5.1 What becomes public

5.2 Marketplace search indexing

The Service exposes a public search index covering Events and Teacher profiles so users can discover dance content. Pages with the listing are accessible without signing in and may be indexed by search engines (Google, Bing, etc.). You can edit or unpublish your own listings at any time from /dashboard; once unpublished the page is removed from our index, but third-party search-engine caches may retain it for several days. To request faster removal from a specific search engine, use that engine’s URL-removal tool - we cannot do this on your behalf.

5.3 Cross-tenant isolation (Organiser A cannot see Organiser B’s data)

The Service is multi-tenant: many Teachers and Organizers run their own events on the same platform simultaneously. We make the following architectural promise about isolation between organisers’ data:

• Organiser-scoped data is row-level isolated. An organiser’s events, attendee lists, booking details, payout records and revenue figures are visible only to that organiser, our admins, and the attendee themselves where applicable.
• One organiser cannot see another organiser’s data. We do not aggregate “all events” or “all attendees” views across organisers outside the public marketplace described in §5.1.
• Enforcement is at the database layer. Supabase Row-Level Security policies on every personal- data table check that the requesting user’s ID matches the row’s owner before returning data. Even if a future API route forgot to filter by user, the database itself rejects mismatched-user queries.
• Admins can see across tenants for support purposes only. Admin role grants are tightly held; admin actions against user data are audit-logged and reviewable. Admin MFA is mandatory (see §4.6 R9).

Risk R31 in §4.6 (cross-tenant data exposure) carries the internal mitigation detail.

5.4 Lawful basis

Publishing your own Event or profile is processed on the basis of contract performance (Art. 6(1)(b) UK GDPR - you asked us to publish it as part of the discovery service we provide) and your consent (Art. 6(1)(a)) for the public- visibility decision itself, which you make actively when clicking “Publish”.

5.5 Module risk register & mitigations

The Directory Engine is the most public-facing part of the Service. The risk profile is dominated by content integrity, search-engine cache and inadvertent disclosure of personal data through free-text fields.

A. Public-exposure threats

B. Content-integrity threats

C. Search-engine & discovery threats

6. Financial Transactions & Secure Transfers(Module: Ticketing & Transfers)

What this section discloses. Card data is handled exclusively by Stripe Payments UK Limited inside their PCI-DSS Level 1 environment - we never see your full card number, CVC or expiry. Ticket transfers use tokenised, time-limited links so the recipient gets only what they need to claim the ticket.

6.1 What we receive when you pay

6.2 Stripe Connect for organiser payouts

When a Teacher/Organizer accepts payments for their Events they onboard through Stripe Connect. Stripe collects the organiser’s identity verification documents (passport / driving licence) and bank-account details directly - we receive only a Stripe Connect account ID and the high-level verification status (verified / pending / rejected). We never see the verification documents.

6.3 Ticket transfers

You may transfer a confirmed ticket to another person from the booking detail page (where the Event organiser permits transfers). The mechanism:

1. You enter the recipient’s email address.
2. We mint an HMAC-signed transfer link, valid for a limited window, and email it to the recipient.
3. The recipient clicks the link → we verify the signature → ownership transfers and a fresh digital ticket is issued in their name.
4. You may cancel the transfer before the recipient claims it; cancellation invalidates the link immediately.

Data shared with the recipient: the original organiser’s event detail (already public), your display name (so the recipient can identify the sender), and the ticket. The recipient’s email is held only for the duration of the transfer window plus 30 days for audit; if they decline or the link expires, the email is purged.

6.4 AutoPay billing schedule & refund timing

AutoPay billing window. Subscription charges fire on the anniversary of your initial signup - e.g. if you signed up at 14:32 UTC on the 15th of the month, your next renewal attempts on the 15th of the following month, typically between 14:00 and 18:00 UTC depending on Stripe’s queue load. The card statement date you see may differ from this by 0–2 days depending on your card network’s settlement.

Failed-payment retry window. If a renewal fails (expired card, insufficient funds, soft decline), Stripe Smart Retries attempts up to 4 times across 21 days, with notification emails from us at retry 1 and retry 4. After all retries fail, your subscription is paused; Pro features lock until you update the payment method.

Refund timing. When we issue a refund - whether for a cancelled event, a successful chargeback dispute, or a 14-day statutory withdrawal - the refund fires immediately on our side via Stripe’s reverse- payment API. The funds typically appear in your card statement within 5–10 working days; international cards or some prepaid cards can take up to 14 working days, which is your card network’s clearing pipeline (we have no control over it). Apple Pay / Google Pay refunds settle to the underlying card on the same schedule. If your card was closed before the refund arrived, Stripe returns the funds to our balance and we contact you within 5 working days to arrange an alternative payout method.

6.5 Stripe Radar (fraud prevention)

Stripe Radar performs automated risk scoring on every payment attempt. A high-risk score may cause Stripe to require step-up authentication (3-D Secure) or decline the transaction. This is processed on the Recognised Legitimate Interests basis introduced by Schedule 4 of the 2026 Act (“detecting, preventing or investigating fraud”). You may ask Stripe to review any decline by their privacy contact.

6.6 Lawful basis

Ticket purchases, refunds and Stripe Connect payouts are processed on the basis of contract performance (Art. 6(1)(b)). Fraud prevention is processed on the basis of Recognised Legitimate Interests (Schedule 4, 2026 Act). Financial records that we are legally required to keep for HMRC and Companies Act purposes are retained on the basis of legal obligation (Art. 6(1)(c)).

6.7 Module risk register & mitigations

Ticketing & Transfers is the highest-financial-impact module. Risks concentrate on payment fraud, ticket-lifecycle integrity, and Stripe Connect organiser onboarding.

A. Payment-fraud threats

B. Ticket-lifecycle threats (transfers, refunds)

C. Stripe Connect / organiser-onboarding threats

7. Location Services & Geolocation(Module: Maps & Geolocation)

What this section discloses. We use location data to centre maps on events near you. We never read your GPS in the background, and we never load Google’s Maps SDK without your consent.

7.1 Two types of location data

7.2 No background tracking

We do not request “background” geolocation permission. We do not use the Geolocation API while the page is hidden. We do not poll your location. Your GPS is read only in the moment after you click the “Locate me” button on a map; the result is consumed locally to pan the map and is discarded when you navigate away.

7.3 Google Maps SDK is consent-gated

The Google Maps JavaScript SDK is gated behind your Functional cookie consent (see Cookie Policy §6). Until you accept Functional cookies, every map area on the Service is replaced with a static placeholder. The fallback ensures we cannot leak Google’s personalisation cookies (NID, 1P_JAR, etc.) before you have made a choice.

7.4 Lawful basis

IP-derived approximate region is processed on the basis of consent (Art. 6(1)(a)) - it only fires after you accept Functional cookies. Precise GPS is processed on the basis of your active consent (the moment-by-moment browser permission prompt).

7.5 Module risk register & mitigations

Location data is the highest-sensitivity category we handle. Risks concentrate on covert tracking, third-party leakage and inference attacks.

A. Location-privacy threats

B. Permission & UX threats

8. Referral Programs & Peer-to-Peer Invites(Module: Referrals)

What this section discloses. The Service includes a peer-to-peer referral programme. The most sensitive aspect of any referral system is anti-spam compliance under the Privacy and Electronic Communications Regulations 2003 (PECR) - sending unsolicited marketing to someone’s email is unlawful. We therefore design the referral flow so that you are the sender, and a referral can only happen with the recipient’s permission.

8.1 How referrals work

1. Every account is automatically issued a unique short Referral Code (e.g. USERMARIA12).
2. You can share that code or the corresponding signup link with people you have permission to invite - through your own messaging app, email, social media, or in person.
3. A new user signing up may optionally enter a Referral Code; if valid, we record a one-way link from the new account to your account so any rewards can be attributed.

We do not send referral emails on your behalf. We do not import your address book. We do not auto-suggest contacts. The Service exposes no “Invite friends” feature that mass-mails on your behalf. Any email sent to a third party as part of a referral is sent by you, from your email account, with your full visibility - keeping PECR compliance squarely in your hands.

8.2 Your obligations

By using the Service you confirm that you will only share a Referral Code or signup link with people who have consented to receive that communication from you, or with whom you have a pre-existing relationship that makes the message expected. Sending unsolicited marketing emails using our links is a breach of these Terms and of PECR (and the equivalent CAN-SPAM, CASL etc. in other jurisdictions). We reserve the right to suspend accounts that we have reasonable grounds to believe are misusing the programme.

8.3 Anti-fraud

Self-referrals, fake-account farming, automated signups and coordinated rings are detected through Stripe Radar signals (see §6.5) and our own heuristics. Detected abuse results in forfeiture of any rewards earned and may result in account suspension.

8.4 Lawful basis

The link between a new account and the referring account is processed on the basis of the new user’s consent (entering a referral code is an affirmative act, Art. 6(1)(a)) and our legitimate interest (Art. 6(1)(f)) in measuring word-of-mouth growth and detecting fraud.

8.5 Module risk register & mitigations

Referrals carry a distinctive risk profile dominated by PECR / anti-spam compliance and reward-system fraud.

A. PECR & anti-spam threats

B. Reward-fraud threats

9. Transactional Emails & Your Rights (GDPR)(Module: Communications)

What this section discloses. Two categories of communication leave our system: (a) transactional notifications you cannot opt out of without ending the underlying contract, and (b) marketing messages that require explicit opt-in and that you can withdraw at any time. Plus your full bundle of UK GDPR rights and how to exercise them.

9.1 Transactional vs marketing

9.2 How to opt out of marketing

• Click Unsubscribe in the footer of any marketing email.
• Toggle off Marketing communications in your profile settings.
• Email support@thesbkdance.com and we will action within 5 working days.

Withdrawal does not affect the lawfulness of any messages we sent before you withdrew consent.

9.3 Your rights under UK GDPR

• Access (Art. 15): request a copy of all data we hold about you.
• Rectification (Art. 16): request correction of inaccurate data.
• Erasure (Art. 17): request deletion (the “right to be forgotten”).
• Restriction (Art. 18): ask us to limit how we use your data while a dispute is investigated.
• Portability (Art. 20): receive your data in a portable JSON format - self-service via your profile settings.
• Object (Art. 21): object to processing based on legitimate interests, including any direct marketing.
• Withdraw consent (Art. 7(3)): instantly, for any consent-based processing.
• Not be subject to automated decision-making (Art. 22): see §21 - we do not currently make decisions affecting you by automated means alone.

9.4 Account deletion + financial-record retention

You can delete your account at any time from your profile. On deletion we anonymise your profile, cancel any active Subscription and outstanding ticket transfers, and place the account in a 30-day grace period during which support staff can recover it on your request. After 30 days the account row is hard-deleted by an automated retention job.

Financial records are retained for 7 years. Even after account deletion, we are required by HMRC and the Companies Act 2006 to keep records of completed transactions (booking references, amounts, organiser payouts) for 7 years. Those records are kept in an anonymised form (your personally-identifying fields are stripped at deletion; only the financial-event data remains). You cannot request earlier deletion of those records - but they are not used for any other purpose.

9.5 Customer support interactions

When you contact us via the contact form (/contact) or by emailing support@thesbkdance.com, the messages are stored as a support ticket linked to your account (or to the email address you wrote from, if you don’t have an account):

• What we keep: the message body, the timestamps, your email address, and any reply we send.
• Who can read it: only the Privacy & Compliance Officer and a small designated support rota. Engineers reading production logs cannot see ticket bodies - the logger scrubs them before they reach our log store (src/lib/log-scrub.ts).
• What we don’t do: support conversations are not reviewed by automated systems. They are not used to train AI (see §3a.1). They are not shared with third parties beyond the email-delivery sub-processor (Resend) which transmits them.
• Retention: 2 years after the ticket is closed (see §13), then permanently deleted.
• Your rights: support transcripts are included in your data export (§17). You can ask us to delete a specific ticket at any time.

9.6 Lawful basis

Transactional emails: contract performance (Art. 6(1)(b)). Marketing emails: consent (Art. 6(1)(a)) + PECR reg. 22. Financial-record retention: legal obligation (Art. 6(1)(c)) - HMRC + Companies Act 2006. Customer support interactions: contract performance + our legitimate interest (Art. 6(1)(f)) in operating an effective support function.

9.7 Module risk register & mitigations

Communications & GDPR-rights handling concentrates on delivery integrity, consent record-keeping, and the mechanics of subject-rights fulfilment.

A. Email / SMS delivery threats

B. Marketing-consent integrity threats

C. Subject-rights / SAR threats

D. Erasure & cross-jurisdictional threats

Risk registers across all six modules above (§4.6, §5.5, §6.7, §7.5, §8.5, §9.7) are reviewed during the DPIA review cycle (§18) and exposed in the internal DPIA at docs/dpia/2026-q2.md with likelihood × severity scoring. The public versions list the user-facing mitigation only. If you spot a risk we’ve missed, please email support@thesbkdance.com.

10. Lawful basis matrix

The complete set of lawful bases applied across the modules in Part 2:

11. Information sharing & sub-processors

We share your personal data with the following third-party service providers acting under written processing agreements aligned with Article 28 UK GDPR. Where providers are located outside the UK, transfers are protected by an instrument permitted under UK GDPR Article 46 - see §12.

A live machine-readable summary is exposed at /api/transparency with a human-readable counterpart at /transparency.

12. International transfers

Several of our sub-processors are located outside the UK. When your personal data is transferred internationally, we rely on:

• UK adequacy regulations and “data bridge” instruments designated under section 17A of the 2026 Act (including the UK-US Data Bridge for transfers to certified US importers);
• the UK International Data Transfer Addendum to the EU Standard Contractual Clauses (IDTA), where the data bridge does not apply;
• EEA adequacy decisions (e.g. Denmark);
• supplementary technical and organisational measures (TLS in transit, encryption at rest, contractual access controls).

You may request a copy of the safeguards we rely on for any specific transfer by contacting our Privacy & Compliance Officer.

13. Data retention

We retain your personal data only as long as necessary for the purpose it was collected, in accordance with UK GDPR Article 5(1)(e). Specific retention periods:

Third-party retention. Stripe independently retains payment and payout history per financial-regulation requirements; this data cannot be deleted through our platform. Contact privacy@stripe.com or visit the Stripe privacy centre to request deletion of records held directly by Stripe.

14. Data security

We implement appropriate technical and organisational security measures aligned with the ISO/IEC 27001:2022 framework. External certification has not yet been engaged.

• Encryption of data in transit (TLS 1.2+) and at rest (Supabase managed encryption + bcrypt for passwords).
• HttpOnly & Secure cookies for session tokens.
• Role-based access controls and per-row authorisation (Supabase RLS policies).
• CSRF protection (double-submit token pattern) on all state-changing requests.
• Cloudflare bot mitigation in front of our backend.
• Audit logs of administrative actions; rate-limiting of authentication endpoints.
• Regular dependency & vulnerability scans.

15. Data breach notification

In the event of a personal-data breach that is likely to result in a risk to your rights and freedoms, we will:

• Notify the UK ICO within 72 hours of becoming aware of the breach (Article 33 UK GDPR);
• Notify affected data subjects without undue delay where the breach is likely to result in a high risk (Article 34 UK GDPR), via the email on your account;
• Maintain an internal breach register (Article 33(5));
• Engage forensic investigation support where necessary.

Breach response is owned by our Privacy & Compliance Officer (support@thesbkdance.com).

16. Cookies and tracking

The full inventory, retention periods and lawful bases are documented in our Cookie Policy. Highlights:

• Strictly Necessary cookies for auth, CSRF, paywall state, bot mitigation, consent record. Cannot be disabled.
• Functional + Marketing cookies set by Google Maps when you grant Functional consent. Decline → maps become a placeholder.
• Payment & fraud cookies set by Stripe on checkout / subscription pages.
• No analytics cookies are currently set.
• Global Privacy Control (GPC) signal honoured as a refusal of non-essential cookies.

17. Subject Access Request (SAR) process

To make a Subject Access Request:

1. Email support@thesbkdance.com with the subject line “Subject Access Request”.
2. We may ask you to confirm your identity from the email registered on your account.
3. We will respond within one month of receipt (Art. 12(3) UK GDPR), extendable by two months for complex requests.
4. Where possible we provide your data in a portable JSON format (Art. 20 UK GDPR). Non-portable items (logs, support transcripts) come as PDF.
   Your export specifically includes: account profile fields; bookings & ticket records; RSVPs and saved events; reviews you have left and any received on your events; messages you have sent through our support channel; consent-record history (cookies, marketing); and the last 12 months of authentication event logs (sign-in time, IP, user agent, sign-in method). Auth logs older than 12 months are not retained and so are not exportable.
5. No charge for the first request in any 12-month period; manifestly unfounded or excessive requests may attract a reasonable administrative fee or be refused.

Self-service: you can export your data via the “Export my data” option in your profile settings, and you can delete your account from the same screen.

18. DPIA & ROPA

We maintain an internal Data Protection Impact Assessment (Article 35 UK GDPR + section 65 of the 2026 Act) covering every data flow described in Part 2. The DPIA is owned by our Privacy & Compliance Officer and was last reviewed on 7 May 2026; next due 7 May 2027. The processing was assessed as low residual risk after mitigations.

We also maintain Records of Processing Activities (Article 30 UK GDPR + Schedule 6 of the 2026 Act). A redacted summary of either document is available on written request to support@thesbkdance.com.

19. Children

The Service is not directed at children under 13. Account creation requires age 16+; users aged 13–17 require guardian agreement to be bound by the Terms of Service. Paid features (Subscription, AutoPay, ticket purchases) are restricted to users aged 18+ by our payment processor.

We do not show advertising and do not run analytics, so the heightened risks the ICO’s Age-Appropriate Design Code targets do not arise on the Service.

20. Accessibility

We aim to meet WCAG 2.2 AA. We have not yet commissioned an external accessibility audit - this is a self- attestation. If you encounter a barrier when exercising any privacy right, contact support@thesbkdance.com and we will resolve it without requiring further consent.

21. Automated decisions & profiling

We do not currently make decisions producing legal effects on you, or similarly significantly affecting you, based solely on automated processing (Article 22 UK GDPR). The Service uses algorithmic ranking for event recommendations and trending rails, but this affects the order of public listings only - it does not deny access, alter pricing, or change any of your rights.

Stripe Radar performs automated fraud risk scoring on payment attempts (see §6.4). You can ask Stripe to review any decline via their privacy contact.

22. Third-party links

Our Service may contain links to third-party websites or services that are not operated by us, including event organiser websites and social-media profiles. We have no control over their content, privacy policies or practices. Review the privacy policy of every site you visit.

23. Changes to this Policy

When we make material changes (a new sub-processor, a new lawful basis, a new category of data, a new module) we will publish a new version, add a row to §26 below, display an in-Service notice on your next visit, and where the change requires fresh consent re-prompt you via the consent banner.

24. Governing law

This Privacy Policy is governed by the laws of England and Wales, including the UK Data (Use and Access) Act 2026, the UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018.

25. Contact & complaints

For questions about this Privacy Policy or to exercise any right:

Inteleforge Limited (trading as The SBK Dance)
Registered office: 34 moray close, Darlington, DL1 3TH, United Kingdom
Company number: 16661156 (England & Wales)
Privacy & Compliance Officer: support@thesbkdance.com
Website: www.inteleforge.co.uk

You have the right to lodge a complaint with the UK Information Commissioner’s Office at any time - you do not have to wait for our response.

Information Commissioner’s Office (ICO)
Wycliffe House, Water Lane, Wilmslow, Cheshire, SK9 5AF
Website: ico.org.uk
Helpline: 0303 123 1113

Under the Complaints Handling Duty introduced by the 2026 Act, we will acknowledge complaints within 5 working days and provide a substantive reply within 30 days.

26. Sanctions, appeals & complaints SLA

The Service moderates user-generated content (Event listings, Teacher profiles, reviews, profile photos) and may suspend accounts that breach our acceptable-use rules. The procedure below applies to every moderation action and every user complaint, in line with the UK Online Safety Act 2023 and the Complaints Handling Duty introduced by the UK Data (Use and Access) Act 2026 (active from June 2026).

26.1 Reporting flagged content or behaviour

Any visitor or signed-in user can flag a piece of content (event listing, review, profile, image) or report a user for breach of the acceptable-use rules:

• Click the Report link on the relevant page;
• Or email support@thesbkdance.com with the URL and a short description of the concern;
• Or, for content covered by the Defamation Act 2013 §5 notice procedure, email the same address with the specific notice information that section requires.

26.2 Service-level commitments

26.3 What happens when content is removed or an account is suspended

1. Notification. The affected user receives an email at the address registered on their account, citing the specific content removed or the specific account action taken, the rule breached, and the appeal route described below.
2. Preservation. Removed content is quarantined for 30 days before final deletion so it can be restored on a successful appeal.
3. Pending refunds. If a Teacher / Organizer is suspended with active paid Events, attendees of those Events are refunded automatically; refunds settle to the original payment method via Stripe within 5–10 working days. Where a refund cannot complete (closed card etc.), the user is contacted by email to arrange an alternative.

26.4 Appeal process

You have the right to appeal any moderation decision. To appeal:

1. Reply to the moderation-decision email within 30 calendar days of receipt, OR email support@thesbkdance.com with the subject line “Appeal”.
2. State the moderation reference number, the action you are appealing, and the grounds for your appeal (factual error, misclassification, change of circumstances, etc.).
3. The appeal is reviewed within 14 calendar days. Where staffing permits, a different reviewer to the one who made the original decision will conduct the review; otherwise the original decider re-examines the evidence with any new submission you provide, and a senior member of staff signs off the outcome. If the appeal is upheld, the action is reversed and the content / account is restored from the 30-day quarantine.
4. If the appeal is rejected, the response will explain why and provide details of how to escalate to the UK Information Commissioner’s Office (for data- protection grounds) or the Online Safety Act ombudsman (for content-removal grounds).

26.5 Specific safeguards for automated decisions

Where any element of a moderation or anti-fraud decision is taken by an automated system (e.g. Stripe Radar declines a transaction; an automated heuristic flags a referral cohort), Article 22 UK GDPR applies. You have the right to:

• Request human review of any automated decision affecting your account or transaction;
• Contest the decision;
• Receive an explanation of the logic involved (to the extent we can disclose it without compromising the anti-fraud system);
• Have a meaningful opportunity to express your view to a person empowered to overrule the automated outcome.

Use the same appeal route described in §26.4 to invoke these rights.

26.6 ICO / regulator escalation at any time

You do not have to exhaust our internal procedure before contacting a regulator. You may contact the UK ICO (ico.org.uk) at any time on data-protection grounds, or Ofcom (ofcom.org.uk) on Online-Safety-Act grounds. We encourage you to raise the issue with us first so we can put it right, but you retain that right unconditionally.

27. Version history