Swootle Book a demo

Security and governance at Swootle

Review Swootle's published AML workflow controls, operating boundaries, assurance register, privacy links and vulnerability disclosure process.

Swootle gives regulated teams observable workflow controls for customer submissions, evidence collection, review, approvals and decision records. This page describes product capabilities and does not make infrastructure, certification or compliance outcome claims.

Last updated: 3 September 2026

Product governance capabilities

  • Guided customer submissions: Customers move through the questions, declarations and requests your team configures for the flow.
  • Structured evidence collection: Collect documents, data and confirmations in a consistent record instead of scattered messages and files.
  • Conditional workflow logic: Branch questions and evidence requests according to customer type, service, jurisdiction or risk context.
  • Review and approval stages: Route cases for internal review, request more information and record the outcome before approval.
  • Submission and decision history: Keep submitted evidence and review context together so teams can understand what was decided and why.
  • Configurable templates: Start from a reusable workflow and adapt its questions, evidence requirements, branching and approvals.

Operating boundaries

  • Program ownership: Swootle supports your AML/CTF program; it does not replace your regulatory obligations or legal advice.
  • Configured controls: Your team remains responsible for choosing the questions, evidence, screening, risk, review and approval controls appropriate to its process.
  • Record context: The platform brings submissions, evidence, review steps and decision history into a workflow record for your team to assess.
  • Change management: Templates can be refreshed as your services, risk appetite, internal procedures or regulatory requirements change.

Public assurance register

Regulated buyers should be able to distinguish published evidence from information that still requires due diligence. Swootle does not use a certification badge or security claim here unless it can be substantiated.

  • Published now: Product governance boundaries, privacy purposes, retention principles, international-transfer notice, subprocessor categories, legal entity details and private security contact.
  • Available on request: The current subprocessor list and answers to product, data-flow, implementation and security questions relevant to a proposed workflow.
  • Not claimed on this site: A specific hosting region, data-residency guarantee, encryption specification, uptime commitment, certification, penetration-test result or independent assurance report unless it is documented in agreed commercial materials.

Read the Privacy Policy for data categories, retention, transfers and subprocessors, and the Terms for account responsibilities and service boundaries.

Vulnerability disclosure policy

Report a suspected vulnerability privately to [email protected]. This mailbox is assigned to the Swootle security owner and reviewed on UK business days. Please do not send passwords, access tokens, private keys, identity documents or customer data by email.

We aim to acknowledge a new report within five UK business days. If you do not receive an acknowledgement, resend the message with the original subject line and the word “FOLLOW-UP”.

What to include

  • The affected Swootle hostname, application, API endpoint or feature.
  • A concise description of the issue, its likely impact and the conditions required to reproduce it.
  • Reproduction steps and the smallest safe proof of concept; remove credentials, personal data and customer content.
  • Any suggested mitigation and whether you intend to publish the finding.

Research rules

  • Use only accounts and data you own or are expressly authorised to test.
  • Make the minimum requests needed to demonstrate the issue, and stop immediately if you encounter personal data, secrets or another customer’s information.
  • Do not retain, copy, alter, delete or publicly disclose data obtained during testing. Tell us what was accessed so we can investigate safely.
  • Do not use denial of service, destructive testing, high-volume automated scanning, social engineering, phishing, spam, physical intrusion or attacks against Swootle staff or suppliers.

Scope

This policy covers Swootle-operated web applications, APIs and supporting services on swootle.com and its managed subdomains. Customer-owned domains are in scope only where the reported issue is caused by Swootle’s application or managed configuration. Third-party products and services are outside our authority unless the issue arises from how Swootle integrates or configures them.

How we respond

We will validate and risk-rate the report, identify an owner and provide a status update after initial triage. Remediation and disclosure timing depend on severity, exploitability, affected customers and the availability of a safe fix. We ask reporters to keep findings confidential until remediation is complete or a coordinated disclosure date has been agreed in writing.

Good-faith research

When research follows this policy, Swootle will treat it as authorised for the purpose of investigating and resolving the reported issue and will not initiate legal action solely because of that research. This commitment cannot authorise activity against systems, accounts or data owned by somebody else, and it does not override applicable law.

Swootle does not currently operate a public bug-bounty programme. A report does not create an entitlement to payment, although we may acknowledge helpful reports with the reporter’s permission.

Continue your evaluation

Use the published material to prepare specific product, data-flow, provider and implementation questions, then test them against one representative workflow.