Security
Paylists Security Document
Technical and Organisational Security Measures
Effective Date: May 9, 2026
Paylists LTD, company number 14081565
1. Purpose and scope
This Security Document describes the high-level technical and organisational measures used by Paylists LTD (“Paylists”, “we”, “us” or “our”) to protect the Paylists software, customer data, business data and personal data processed through the Paylists services.
This document is intended to support Paylists’ User Agreement, Privacy Policy, Data Processing Addendum, Subprocessor List, Data Retention Schedule and public compliance information. It is a public-facing security summary and does not include sensitive internal security details such as system diagrams, credentials, vulnerability details, incident playbooks or internal architecture diagrams.
2. Current hosting and technology stack
Paylists currently uses a managed cloud architecture with separate application, database and infrastructure providers. The current stack is summarised below.
Component | Current implementation | Primary location / configuration |
Application framework | Next.js and TypeScript | Application codebase and runtime managed through Vercel deployment configuration. |
Application hosting | Vercel | London, United Kingdom, where available and configured by Paylists. |
Database | PostgreSQL managed by Supabase | London, United Kingdom. Supabase uses AWS infrastructure for the Paylists database environment. |
Underlying cloud infrastructure | AWS infrastructure used by Supabase and other configured services | London, United Kingdom, where configured by Paylists or the relevant provider. |
Peppol e-invoicing provider | Flowin, an e-invoicing product of Codabox | Flowin/Codabox processing and availability are described in Paylists’ Subprocessor List and Peppol Country Availability List. |
Optional AI feature | OpenAI API platform | Used only for optional AI-assisted cash-flow insights where enabled or consented to by an authorised user. |
Paylists aims to keep application components, libraries and managed-service configurations on current supported versions. Paylists does not represent that all third-party providers use the same infrastructure, regions or certifications for all aspects of their services, and Paylists maintains supplier records to track material processing locations and transfer safeguards where required.
3. Security governance
Paylists maintains security responsibilities internally and grants access to production systems only where needed for operational, support, engineering, security or compliance purposes.
Security measures are reviewed when Paylists introduces material new infrastructure, subprocessors, processing activities, Peppol/Flowin changes, AI features or security-sensitive product changes.
Paylists does not publish sensitive operational security details that could increase risk to the service or its users.
Paylists is not currently ISO 27001 certified, SOC 2 certified or certified under another formal information security certification scheme unless expressly stated in writing in a future version of this document.
4. Access control
Access to production systems should be restricted to authorised personnel and granted on a need-to-know and least-privilege basis.
Administrative access should use strong authentication, and multi-factor authentication should be enabled for administrator accounts wherever supported by the relevant service.
Access rights should be reviewed when personnel change roles, leave Paylists or no longer require access.
Shared administrator accounts should be avoided where practical. Individual accounts should be used for accountability.
Access to Supabase, Vercel, AWS, source code repositories, Flowin/Codabox administration tools and other operational tools should be limited to authorised engineering, support or administrative personnel.
5. Application hosting and deployment on Vercel
Paylists’ web application is built using Next.js and TypeScript and is hosted on Vercel.
Paylists configures Vercel to use the United Kingdom / London region where available. Vercel is used to host and deliver the application layer, while Paylists’ PostgreSQL database is managed through Supabase and hosted on AWS infrastructure.
Paylists is responsible for configuring and using Vercel appropriately, including access control, project permissions, deployment settings, environment variables, domain configuration and any available security controls.
Secrets, API keys and production credentials should be stored in secured environment variables or secret-management functionality and should not be committed to source code.
Deployments should be controlled through authorised repositories and deployment workflows. Security-sensitive changes should be reviewed before deployment where practical.
6. Database and data security
Paylists uses PostgreSQL managed by Supabase for database services.
Database access should be protected through authentication, role-based access, network/security configuration and access controls provided by Supabase and the underlying AWS infrastructure.
Production data should not be copied into development or test environments unless necessary and appropriately protected, minimised or pseudonymised where reasonably possible.
Paylists should maintain audit trails for key events, including account access, administrative actions, business profile changes, Peppol onboarding submissions and status changes, AI consent changes and security-relevant events.
7. Encryption and transmission security
Paylists should use HTTPS/TLS for connections to the Paylists software and APIs.
Data transfers between Paylists, Supabase, Vercel, AWS, Flowin/Codabox, OpenAI and other subprocessors should use secure transport protocols where supported.
Encryption at rest should be enabled where provided by managed service providers such as Supabase, AWS and Vercel, subject to their service configuration.
Secrets, credentials and tokens should be protected against unauthorised access and rotated where needed following suspected compromise or operational change.
8. Application security
Paylists aims to follow secure development practices, including input validation, output encoding, authentication checks, authorisation checks and protection against common web application risks.
Dependency updates and security patches should be applied within a reasonable timeframe based on severity, exploitability and operational risk.
Public endpoints, APIs, webhooks and integrations should include appropriate authentication, authorisation, validation and rate-limiting or abuse-control measures where appropriate.
Paylists should maintain separation between development, staging and production environments where practical.
9. Peppol, Flowin/Codabox and KYC security
Paylists may collect, store and submit Peppol onboarding information to Flowin/Codabox for Peppol onboarding, KYC, proof-of-ownership, authority verification and Peppol registration.
Flowin/Codabox, not Paylists, performs the Peppol KYC, proof-of-ownership or authority verification where applicable.
Paylists should store Flowin/Codabox verification status and related operational references in a controlled manner.
Paylists should not mark a business as Peppol-enabled until the required Flowin/Codabox onboarding or verification process has been completed or approved where applicable.
Peppol onboarding data and status changes should be logged to support security, dispute resolution, fraud prevention and compliance.
10. AI feature security
Optional AI-assisted cash-flow insights should only be enabled where an authorised user enables or consents to the feature.
Where reasonably possible, Paylists should minimise, aggregate, anonymise or pseudonymise data before sending it to AI service providers.
AI prompts and outputs should be treated as potentially sensitive business information and protected accordingly.
Paylists should store the AI enablement/consent state, timestamp, user ID, business ID and version of the consent wording shown to the user.
11. Logging, monitoring and audit trails
Paylists should maintain security and operational logs reasonably necessary to operate the service, investigate issues, detect misuse, prevent fraud and support compliance.
Logs should be protected from unauthorised access and should not be used as a general-purpose source of user-visible data.
Key change logs should include business legal name, business address, company number, Peppol identifier, Peppol onboarding status, authorised users, AI consent, invoice/payment-request status and administrator actions.
Log retention should follow the Paylists Data Retention Schedule and should not be indefinite unless required for legal, compliance, security, fraud or dispute reasons.
12. Backups, availability and recovery
Paylists relies on managed service providers such as Supabase, AWS and Vercel for underlying hosting, database and infrastructure availability.
Database backups and recovery capabilities should be configured using Supabase and/or underlying infrastructure capabilities appropriate to Paylists’ operational requirements.
Paylists should maintain a recovery approach for critical systems, including access to provider dashboards, operational contacts, key credentials and deployment procedures.
Paylists does not guarantee uninterrupted service and may be affected by maintenance, incidents or outages at Paylists or its managed service providers.
13. Subprocessor and supplier security
Paylists uses subprocessors and suppliers listed in the Paylists Subprocessor List, including AWS, Supabase, Vercel, Flowin/Codabox, OpenAI and DataRep where applicable.
Before using material subprocessors, Paylists should assess their role, purpose, location, data categories and security posture at a level appropriate to the risk.
Paylists should maintain contractual arrangements with material subprocessors where required, including data processing terms and transfer safeguards where applicable.
Supplier access to Paylists data should be limited to what is necessary for the relevant service.
If a subprocessor changes its processing location or begins processing personal data outside the UK or EEA, Paylists should assess whether updates are needed to the Subprocessor List, Privacy Policy, DPA, ROPA and any applicable international transfer safeguards.
14. Personnel and operational security
Personnel with access to Paylists systems should be subject to confidentiality obligations.
Access should be removed or changed when personnel leave or no longer need access.
Personnel should receive security and data-protection guidance appropriate to their role.
Security-sensitive administrative actions should be limited to authorised personnel.
15. Vulnerability and patch management
Paylists aims to keep Next.js, TypeScript, dependencies, runtime components and managed service configurations on current supported versions.
Security updates should be prioritised according to severity, exploitability, exposure and business impact.
Vulnerability reports should be triaged and remediated within a reasonable period depending on severity.
Users and researchers may report suspected security issues to security@paylists.co.uk, unless Paylists publishes a different security contact.
16. Incident response
Paylists should maintain an incident response process for suspected security incidents, personal data breaches, unauthorised access, loss of data, service misuse and supplier security incidents.
Incidents should be assessed for impact, containment, remediation, user notification, regulator notification, DataRep involvement and subprocessor involvement where applicable.
Where Paylists acts as processor for a business user, Paylists should notify the business user without undue delay after becoming aware of a personal data breach affecting that user’s data, as required by the DPA.
Incident records should be retained as internal compliance records.
17. Data retention and secure deletion
Paylists follows the Paylists Data Retention Schedule for retention and deletion of data categories.
Data should be deleted, anonymised or archived when it is no longer reasonably required for the purposes for which it was collected, subject to legal, tax, accounting, fraud, dispute, security, Peppol, Flowin/Codabox and backup requirements.
Backups and managed service provider retention may follow separate deletion cycles, and data may remain in backups for a limited period before being overwritten or deleted according to provider processes.
18. Certifications and limitations
Paylists is not currently ISO 27001 certified, SOC 2 certified or certified under another formal information security certification scheme. Paylists may use managed service providers that maintain their own security programmes or certifications, but such provider certifications do not mean Paylists itself is certified.
This document describes security measures at a high level. It does not create an absolute guarantee of security, availability, confidentiality, integrity or error-free operation. No system can be completely secure, and Paylists’ security obligations are subject to the User Agreement, Privacy Policy, Data Processing Addendum and applicable law.
19. User responsibilities
Users are responsible for keeping account credentials confidential and using strong passwords.
Users should ensure that only authorised personnel are invited to their Paylists account or business workspace.
Users are responsible for verifying payment requests, invoices, vendors and Peppol information before acting on them.
Users should promptly notify Paylists of suspected account compromise, unauthorised access, suspicious payment requests or security incidents involving their account.
20. Contact
Security issues may be reported to security@paylists.co.uk. Privacy questions may be sent to privacy@paylists.co.uk. Product support requests should be sent through the support channels identified by Paylists.