Security policy

1. Scope and current website

This policy sets out security requirements for Epione Trading Ltd, operating B-MO. It covers people, systems and suppliers handling information for the service. It is a policy baseline; evidence of implementation must be confirmed against each live deployment and its agreed security schedule.

The marketing website is a static site hosted by Vercel. Its card demonstrations run in the browser and do not create live customer records, install wallet passes, take payments or send notifications. Enquiry forms open the visitor’s email app. Shared demo links contain the entered sample details, so they should not contain confidential or sensitive information.

Live staff portals, booking connections and payment services have different access and data flows. Their controls must be reviewed separately. This page does not claim an independent audit, ISO 27001 certification, SOC 2 report, or a guarantee that a service is free from vulnerabilities.

2. Access and confidentiality

Access to customer information must be limited to authorised people and the minimum needed for their duties. Privileged accounts should use multi-factor authentication where supported. Joiner, role-change and leaver processes must grant, review and promptly remove access as appropriate.

Staff must follow confidentiality requirements and receive guidance appropriate to their role. Separate businesses’ records must be protected against cross-business access. Authentication, permissions and customer-data separation must be checked before a deployment handles live information.

3. Data and application protection

Live services must use encrypted transport for personal data. Stored-data protection, key management and supplier encryption settings must be documented for the actual configuration. Passwords, API secrets and payment credentials must not be placed in public website code, URLs, support messages or logs.

Changes must be reviewed and checked before release. Dependencies and reported vulnerabilities must be assessed and addressed according to risk. Inputs and permissions must be validated, with appropriate safeguards against abuse. Development and demonstrations should use sample information rather than copies of live customer records.

Stripe-hosted checkout, when enabled, must keep payment-card entry with Stripe. Signed payment events and the correct plan, amount and payment status must be verified before account activation. Customer payment-card security codes must not be collected by the B-MO marketing site.

4. Monitoring, backups and suppliers

Services handling live records need proportionate access and operational logging, with protection against unnecessary personal information in logs. Monitoring and escalation arrangements must be defined for the deployment.

Backup frequency, retention, locations, access and restoration procedures must be documented and restore checks performed for the relevant systems. Any recovery targets or availability commitments belong in the accepted service agreement; none are guaranteed by this policy.

Supplier due diligence must cover security, data-processing terms, onward suppliers and incident responsibilities. The data processing agreement explains the required processing and security schedules.

5. Report a security concern

Contact sales@bmopass.com with the subject “B-MO security concern”. Include the affected page or service, when you noticed the issue, and a brief description or steps to reproduce it using sample data.

Do not include passwords, secret keys, full payment details or another person’s records. If sensitive evidence is needed, ask us to agree a suitable transfer method. Do not access other customers’ information, interrupt services or continue testing beyond what is necessary to describe the issue. This notice does not authorise intrusive testing or offer a bug-bounty payment.

Reports must be assessed and escalated according to risk. Where a personal-data breach affects data processed for a client, that controller must be notified without undue delay after awareness. The responsible controller must assess any regulatory notification requirement, including the applicable 72-hour deadline, and whether affected people need to be informed. Investigation should not delay a notification that is already required.

6. Review and assurance

Security measures must remain proportionate to the data, service and risks. New integrations, sensitive-data uses and significant changes require review before activation. Prospective clients can request the relevant security schedule and available evidence when agreeing their service.

Read the privacy policy, GDPR policy and cookie policy for related information. This policy follows a risk-based approach consistent with the ICO’s guidance on data security.