Duffel Lockup

Security and Compliance

Last updated on Tue, 25 Mar 2025 17:07:09 GMT

Overview

Learn more about security at Duffel. This page describes the technical and organizational measures implemented by Duffel to ensure an appropriate level of security, taking into account the nature, scope, context and purpose of the processing, and the risks for the rights and freedoms of natural persons.

At Duffel, security is one of our top priorities. We really care about protecting our systems and data, as well as our users and their data from nefarious activities. We know how important security is, and we put a lot of effort into ensuring that all of the appropriate safeguards are in place to support our business.

If there's something that you'd like to know but cannot find it on this page, or if you have any questions, please don't hesitate to contact us at security@duffel.com. We'd love to hear from you.

Compliance

You can find our reports on compliance and additional information regarding security monitoring, and overall posture by visiting our Trust Report. Duffel is PCI-DSS v4 Level 1 compliant.

Protecting our customers' data

The framework for Duffel’s security programme includes administrative, organizational, technical, and physical safeguards reasonably designed to protect the Services and confidentiality, integrity, and availability of data.

  • Duffel has deployed secure methods and protocols for transmission of confidential or sensitive information. Agreements with employees, contractors, customers and suppliers contain confidentiality provisions.
  • Duffel adheres to a change management process to administer changes to the production environment for the Services, including changes to its underlying software, applications, and systems.
  • Physical security: Duffel software operates entirely on Google Cloud Platform (GCP), which is certified under numerous global standards for physical security. You can read more about their security here.
  • Logical security: All devices capable of processing data are equipped with full-disk encryption, set up via mobile device management (MDM) software, and include antivirus and threat detection systems. Devices can also be remotely managed and wiped if necessary. Duffel has implemented a leading intrusion detection and prevention system (IDS/IPS). Duffel enters into data processing agreements with its Sub-Processors with data protection obligations substantially similar to those contained in the Duffel DPA.

Encryption of sensitive data 'in transit' and 'at rest'

Duffel’s systems are fully encrypted. For data in transit, e.g. an API request, Duffel uses HTTPS for all of its public-facing services using Transport Layer Security (TLS) 1.2 or greater; this includes traffic to our public website (https://duffel.com), our API (https://api.duffel.com) and our Dashboard (https://app.duffel.com). We enforce the usage of HTTPS, by using HTTP Strict Transport Security (HSTS). At rest, e.g. stored in our databases, data is encrypted using AES-256.

  • Duffel does not, under any circumstance, store card numbers. All card numbers received via our API are forwarded to the relevant service providers.
  • Duffel is responsible for the security of the card data received through our API.

Penetration testing and vulnerability scanning

Duffel regularly tests its security systems and processes, assessing and evaluating the effectiveness of technical and organizational measures in order to ensure the security of the processing. Every year we carry out many internal and external audits of our systems, which are performed by both third parties and the internal team. They help to ensure that our systems and its configurations are being frequently reviewed for potential flaws.

We believe firmly in learning from failure, and this is built right into our culture. Some of these practices include:

  • Yearly penetration tests.
  • Quarterly Approved Scanning Vendor security scans.
  • Quarterly internal security scans.
  • Regularly patching of security vulnerabilities
  • Post-mortems after significant incidents.

Access control

Duffel uses secure access protocols and processes and follows industry best-practices for access and authentication. Duffel employs role-based access control (RBAC) and single sign-on (SSO) to enforce access restrictions and streamline authentication.

Any access to database or production consoles is logged and requires approval from a restricted set of authorised users. To detect unauthorised access or anomalies, Duffel utilises comprehensive monitoring and auditing systems.

Business Continuity and Disaster Recovery (BCDR)

By default all back-ups are made to a storage repository with robust security controls. All compute resources powering our Services are defined in code, enabling Duffel to recreate infrastructure quickly in the event of a failure. For data, Duffel maintains a replica with logical replication in place and performs daily backups.

Duffel has an incident management programme that includes incident response and data breach plans to ensure Duffel handles an incident in a timely and secure manner.

Data retention

Duffel retains data only for the purpose of and for as long as necessary, and will destroy data when there is no longer any lawful basis for processing. Duffel shows ultimate care and attention for the erasure of data.

Responsible vulnerability disclosure

Keeping our customers' data safe is one of our highest priorities. If you discover an issue or a vulnerability that may compromise the security of our systems, please report it in a secure and responsible manner. It's worth calling out that sharing open vulnerabilities widely incurs a risk to our business and our users. Please refrain from disclosing the vulnerability until you've had confirmation from us that it has been addressed.

You can read more about how to responsibly disclose vulnerabilities in the Vulnerability Disclosure Cheat Sheet provided by OWASP.

Rules of engagement

As per the Vulnerability Disclosure Cheat Sheet provided by OWASP, we expect that all security researchers should:

  • Ensure that any testing is legal and authorised.
  • Respect the privacy of others.
  • Make reasonable efforts to contact the security team of the organisation.
  • Provide sufficient details to allow the vulnerabilities to be verified and reproduced.
  • Not demand payment or rewards for reporting vulnerabilities outside of an established bug bounty program.

As a researcher, you can expect that Duffel as an organisation will:

  • Provide a clear method for researchers to securely report vulnerabilities. See 'Reporting a vulnerability' below.
  • Clearly establish the scope and terms of any bug bounty programs.
  • Respond to reports in a reasonable timeline.
  • Communicate openly with researchers.
  • Not threaten legal action against researchers.
  • Request CVEs where appropriate.
  • Publish clear security advisories and changelogs.
  • Offer rewards and credit where applicable. See 'Reward eligibility' below.

Reporting a vulnerability

This is our version of a 'Bug Bounty Program'. Upon discovering a vulnerability please contact us at security@duffel.com as soon as possible. We recommend that you encrypt your message to us. Our GPG key id is 0xB13FDB69 with its fingerprint being: F4B7 8241 A61A ED4A 69AC 16ED 5122 33E2 B13F DB69.

Do:

  • Include as much detail as possible, preferably with steps to reproduce the issue.

Do not:

  • Exploit the vulnerability, except to provide a demonstration or you have been explicitly instructed to do so.
  • Disclose the issue publicly, until you have confirmation from Duffel staff that you can do so.

Reward eligibility

We understand and appreciate the effort that goes into investigating and responsibly disclosing security vulnerabilities. This work helps immensely in keeping our services and our customers safe, as well as the wider community. Because of that, we want and aim to remunerate security researchers appropriately, but it is assessed on a case-by-case basis and at our discretion.

However, we will not accept any type of malicious behaviour, or actions that cause disruption to our services. We also want to make clear that we will not pursue legal action against security researchers provided that your activities were legal.

Each submission is assessed individually by our engineering team, however we will not provide rewards for:

  • Any denial of service (DoS, DDoS) attacks.
  • The usage of automated tools, such as scanners and fuzzers.
    • These tools can negatively impact our quality of service and generate large amounts of noise and cost.
  • Social engineering attacks.
  • Physical attacks or threats against Duffel staff, merchants or customers.
  • Self-XSS.
  • Disclosure of server or software version numbers.
  • User/organisation enumeration.
  • Best practice reports without a valid exploit (e.g. use of “weak” TLS ciphers).
  • Reports of spam.
  • Hypothetical subdomain takeovers without supporting evidence (e.g. actually taking over the sub-domain).
  • Perceived security weaknesses without concrete evidence of the ability to compromise a user (e.g., missing rate limits, missing headers, etc.).
  • Submissions that relate to third-party services that Duffel has little or no control over (e.g. https://changelog.duffel.com)
  • Submissions that we are already aware of.

Please note that submissions that are closely related should be submitted together rather than as separate bounties.