Security Policy

Information Security and Responsible Disclosure

Effective Date: 15 February 2026 | Last Updated: 16 February 2026

1. Introduction

At HELLO BART LTD ("we", "us", "our"), the security of our users' data is a top priority. Bart processes sensitive personal and financial information, including National Insurance numbers, bank transactions, and HMRC tax data. This policy describes the security controls we have in place to protect that data, how we manage risk, and how security researchers can report vulnerabilities responsibly.

2. Data We Protect

We classify the personal data we process into the following categories:

• Identity data: Name, email address, National Insurance number (NINO).
• Financial data: Bank account details, transaction history obtained via Open Banking.
• Tax data: HMRC business records, quarterly obligation details, and submission history.
• Authentication data: OAuth tokens for HMRC Government Gateway and Open Banking connections.
• Device data: Device identifiers, screen dimensions, timezone, and local IP addresses collected for HMRC fraud prevention headers.

3. How We Protect It

3.1 Encryption in Transit

All data transmitted between the Bart app, our backend services, and third-party APIs is encrypted using TLS (Transport Layer Security). No data is ever sent over unencrypted channels. Our backend enforces HTTPS for every connection.

3.2 Encryption at Rest

• On your device: Sensitive data such as authentication tokens is stored using the platform's secure storage (iOS Keychain and Android Keystore) via expo-secure-store. No sensitive data is stored in plain-text local storage.
• On our servers: Our database provider encrypts all data at rest using AES-256. For highly sensitive fields (National Insurance numbers, HMRC access tokens), we apply an additional layer of application-level encryption using AES-256-GCM before writing to the database. Encryption keys are stored in environment variables, never in source code.

3.3 Access Control

• User data isolation: Row Level Security (RLS) policies are enforced at the database level, ensuring that each user can only access their own records. Every database query is scoped to the authenticated user's identity.
• Internal access: Access to production systems and data is restricted by role. Only authorised personnel can access the production database, and all access is logged. We follow the principle of least privilege.
• Authentication: User authentication is handled via industry-standard OAuth 2.0 providers (Google, Apple). We never store user passwords. HMRC authorisation uses the Government Gateway OAuth flow — we never see or handle HMRC sign-in credentials.

3.4 Secure Development

• Our codebase uses TypeScript with strict mode enabled for type safety.
• We conduct regular penetration testing using OWASP ZAP (for API endpoints) and MobSF (for mobile application binaries), in line with the NCSC Penetration Testing guidance.
• Dependencies are monitored for known vulnerabilities.
• Android builds enforce a minimum SDK version of 29 (Android 10) to ensure devices receive current security updates, and application data backup via ADB is disabled.

4. Third-Party Processors

We use a limited number of third-party service providers to operate Bart. Each processor is bound by data processing agreements and is required to maintain appropriate security measures:

• Supabase — Database hosting, authentication, and serverless backend. Data is hosted in the EU and encrypted at rest and in transit. Supabase maintains SOC 2 Type II compliance.
• Finexer — Open Banking provider for retrieving bank transaction data. Authorised and regulated by the FCA. Connections are made via secure API with OAuth consent flows.
• HMRC — HM Revenue & Customs APIs for Income Tax Making Tax Digital. All communication uses OAuth 2.0 over HTTPS with fraud prevention headers as required by HMRC.
• Google / Apple — Authentication providers for user sign-in. Standard OAuth 2.0 flows; we only receive profile information the user has consented to share.

We do not sell, share, or provide personal data to any third parties beyond what is necessary to operate the service.

5. Monitoring and Incident Response

5.1 Monitoring

We maintain logging and monitoring across our backend services to detect unauthorised access, unusual activity, and system failures. Logs are retained for operational and compliance purposes.

5.2 Incident Response

In the event of a security incident involving personal data:

• We will contain the incident immediately by isolating affected systems and revoking compromised credentials.
• We will assess the scope and impact of the breach.
• We will notify the Information Commissioner's Office (ICO) within 72 hours if the breach poses a risk to individuals, as required by UK GDPR.
• We will notify HMRC at SDSTeam@hmrc.gov.uk within 72 hours, as required by the HMRC Developer terms of use.
• We will notify affected users directly if the breach poses a high risk to their rights and freedoms.

6. Risk Assessment

We identify, assess, and manage information security risks on an ongoing basis. This includes:

• Conducting Data Protection Impact Assessments (DPIAs) for processing activities that pose high risks to individuals.
• Regular penetration testing of our API endpoints and mobile application.
• Reviewing and updating security controls when our architecture, third-party processors, or data processing activities change.
• Monitoring for new threats and vulnerabilities affecting our technology stack.

7. Responsibilities

HELLO BART LTD has designated a responsible individual who oversees information security and ensures compliance with this policy, UK GDPR, and HMRC's terms of use. This individual is accountable for:

• Maintaining and reviewing this security policy.
• Ensuring penetration test findings are remediated.
• Approving the breach response plan and coordinating incident response.
• Reviewing third-party processor agreements.
• Ensuring all personnel with access to personal data understand their security obligations.

8. Policy Review

This policy is reviewed at least every six months, or sooner if there is a material change to our systems, data processing activities, or applicable regulations. The last review date is noted at the top of this page.

9. Vulnerability Disclosure

We welcome and encourage security researchers and members of the public to help us improve our security by reporting potential vulnerabilities responsibly.

9.1 How to Report a Security Issue

If you believe you have discovered a security vulnerability in Bart, please report it to us as soon as possible.

Please do not report security vulnerabilities through public channels such as social media, public forums, or GitHub issues. Responsible disclosure helps us protect our users while we work on a fix.

9.2 What to Include in Your Report

To help us investigate and resolve the issue as quickly as possible, please include:

• Description: A clear and detailed description of the vulnerability, including the type of issue (e.g., cross-site scripting, SQL injection, authentication bypass).
• Steps to reproduce: Step-by-step instructions that allow us to reliably reproduce the vulnerability. Include any specific URLs, parameters, or payloads used.
• Impact assessment: Your understanding of the potential impact and severity of the vulnerability.
• Environment details: The platform, browser, device, or app version where the issue was observed.
• Supporting evidence: Any relevant screenshots, logs, or proof-of-concept code that demonstrate the issue.

If you are unable to provide all of the above, please still submit your report with as much detail as you can. Incomplete reports are better than unreported vulnerabilities.

9.3 Our Response Commitment

We take every security report seriously. Here is what you can expect from us:

• Acknowledgement: We will acknowledge receipt of your report within 48 hours.
• Assessment: We will investigate and validate the reported vulnerability promptly. We aim to provide an initial assessment within 5 business days.
• Resolution: We will work to remediate confirmed vulnerabilities as quickly as possible, prioritising based on severity and impact.
• Communication: We will keep you informed of our progress and notify you when the issue has been resolved.

9.4 Safe Harbour

We will not pursue legal action against individuals who discover and report security vulnerabilities in good faith.

To qualify for safe harbour protection, we ask that you:

• Act in good faith and avoid actions that could harm our users, our services, or our data.
• Do not access, modify, or delete data belonging to other users.
• Do not degrade or disrupt our services (e.g., denial-of-service attacks).
• Do not exploit the vulnerability beyond what is necessary to demonstrate it.
• Allow us a reasonable amount of time to address the issue before disclosing it publicly.
• Report your findings exclusively through the channels described in this policy.

We consider security research conducted in accordance with this policy to be authorised and will not pursue civil or criminal action against researchers who comply with these guidelines.

9.5 Scope

This disclosure policy applies to vulnerabilities found in:

• The Bart mobile application (iOS and Android)
• The Bart website (hellobart.com)
• Bart's APIs and backend services

The following are generally out of scope:

• Vulnerabilities in third-party services or software that we do not control
• Social engineering or phishing attacks against our employees or users
• Physical attacks against our offices or infrastructure
• Denial-of-service (DoS/DDoS) attacks
• Spam or volume-based attacks
• Issues that require unlikely or complex user interaction

9.6 Recognition

We value the contributions of security researchers. With your permission, we are happy to publicly acknowledge your contribution once the vulnerability has been resolved.

10. Contact

For any questions about this policy, to report a security issue, or to raise a data protection concern, contact us at:

• Email: security@hellobart.com

Thank you for helping keep Bart and our users safe.