This page summarises the technical and organisational measures Supplio uses to protect customer data. It supports our Privacy Policy and forms the technical and organisational measures schedule referenced in our Data Processing Addendum. We aim to describe what is true today, not what we hope to be true; where a control is a roadmap item we say so.

1. Encryption

In transit: all connections to app.supplio.co.uk and supplio.co.uk are served over TLS 1.2 or higher, with HTTP Strict Transport Security (HSTS) enabled. Our application servers accept no inbound web traffic from the internet; requests reach them only through an encrypted tunnel from our CDN.
At rest: databases, database backups and uploaded files are encrypted at rest with AES-256 by the underlying storage providers. Off-site database backups are additionally encrypted with AES-256 before they leave our servers.
Passwords: stored only as salted PBKDF2 (HMAC-SHA512) hashes; we never store or transmit clear-text passwords.
Sensitive values: two-factor secrets, recovery codes, per-customer database passwords and storage credentials are encrypted again at the application layer, with keys that are themselves protected by a certificate. Session refresh tokens and invitation tokens are stored only as hashes.
Secrets: API keys, signing keys and other secrets are kept out of source control and supplied to the runtime through environment configuration. A start-up guard rejects deployments that ship with weak or known-leaked JWT signing keys.

2. Authentication and session management

Two-factor authentication (MFA): every user can protect their account with a standard authenticator app (time-based one-time codes, such as Microsoft Authenticator or Google Authenticator), with 10 single-use recovery codes for a lost device.
MFA enforcement: organisation administrators decide who must use two-factor authentication: no one, all staff, or all staff and supplier portal users. New organisations start with it required for all staff. Anyone who is required to use it and has not set it up is taken through set-up at their next sign-in before they can reach any data.
Two-factor codes cannot be reused, and each sign-in challenge allows a limited number of attempts. Users receive an email whenever two-factor authentication is turned on or off for their account, when a recovery code is used and when an administrator resets it; an administrator reset requires the administrator to re-enter their own password.
Passwords: a minimum length of 12 characters, with no arbitrary character-class rules (consistent with NIST SP 800-63B guidance). Every new password is checked against passwords exposed in known data breaches using the Have I Been Pwned k-anonymity service, so only the first five characters of a hash ever leave our servers.
Sign-in limits: no more than 5 wrong passwords per account and network address in any 15-minute window, enforced across all servers, in addition to per-IP rate limits in the application and at the edge.
Sessions: access tokens last 30 minutes. A session ends after 30 minutes of inactivity and after 12 hours at most, however active it is. Every request is checked against the live server-side session, so signing out or revoking a session takes effect immediately on every server.
Cookies: session tokens are held only in __Host- prefixed cookies that are HttpOnly and Secure, never in browser storage or in API responses. Refresh tokens rotate on every use, and replaying an old one revokes the session.
Single sign-on: sign-in through Microsoft Entra ID (OpenID Connect) is available on Scale and Enterprise as a paid add-on with assisted set-up. Organisations can require it for staff, keeping an administrator password fallback for emergencies, and sign-ins through Entra rely on your own Entra multi-factor policy.

3. Application security

Rate limiting on every API endpoint, per IP address and per signed-in user, with stricter limits on sign-in, sign-up and external-form endpoints, and an additional edge rule on credential endpoints.
Default-deny authorisation: every API endpoint requires a signed-in user unless it is deliberately marked public, and permissions are checked on every request.
Origin and referrer checks on every state-changing request that carries a session cookie; cross-origin requests are allowed only from Supplio's own domains.
Security headers on the app and API, including HSTS with preload, a strict Content Security Policy, frame blocking, MIME-type sniffing protection and cross-origin isolation headers.
Uploaded files are identified by their content rather than the name or type the browser claims, size-capped, and scanned for malware (ClamAV) while held in quarantine. If the scanner is unavailable, uploads are refused rather than stored unscanned. SVG images are sanitised and displayed through <img> tags so embedded scripts cannot run.
File uploads go through a quota-aware storage layer with a per-organisation storage event ledger.
Per-customer isolation: each customer's supplier records, forms and settings live in a dedicated database rather than co-mingled tables. The application reaches each database with its own login, which cannot read any other customer's database or change the schema. Uploaded files sit in a per-customer area of object storage, accessed with storage credentials limited to that area.

4. Access controls

Role-based access controls with preset roles (Admin, Manager, Employee and Supplier) and, on Growth and above, custom roles built from granular permissions. Role and permission changes take effect within a minute, without anyone signing out.
Production access for Supplio personnel is restricted on the principle of least privilege; access is auditable and revoked on offboarding.
Production servers expose no inbound ports to the internet. Administrative access is by SSH key over a private network only, and our internal operations console is reachable only on that network and requires per-operator sign-in with two-factor authentication.
When Supplio support views a customer workspace at the customer's request, that access is read-only by default and limited to 15-minute sessions.
Cloud-console access requires MFA.

5. Logging and auditing

An in-application audit log records changes to supplier records, documents, configuration, scores and security settings (including two-factor changes), with the actor, timestamp, originating IP address and user-agent. Entries cannot be edited or deleted through the application; they are kept for 13 months and can be filtered and exported to CSV.
Sign-ins are tracked through server-side session records, and failed sign-in attempts are written to security logs.
Operational request and error logs are kept for a limited period and reviewed for anomalies. We avoid logging request and response bodies to minimise the personal data that lands in logs.

6. Infrastructure and network

UK hosting: application servers, PostgreSQL databases and file storage are all hosted in London, United Kingdom. See the sub-processor list for the providers.
Traffic is fronted by Cloudflare, which provides TLS termination, DDoS protection, a web application firewall and rate limiting at the edge. Forwarded client addresses are accepted only from trusted upstream networks, to prevent IP spoofing in logs.
Servers run a regularly patched Linux with a host firewall and automatic security updates.
Slow-loris and similar low-bandwidth attacks are mitigated by configured request-header and keep-alive timeouts.

7. Backups and disaster recovery

The production database can be restored to any point in the last 7 days, and the database provider also keeps daily snapshots for 30 days.
Every night each database is also exported, encrypted with AES-256 and copied to separate, versioned object storage in the UK. Our servers can add new backups but cannot delete them. Daily copies are kept for 30 days, weekly copies for 12 weeks and monthly copies for 13 months, then deleted automatically.
Backup failures raise an alert, and restores are tested with restore drills into an isolated environment.
Recovery-time and recovery-point objectives appropriate to the Enterprise plan are documented in the relevant order form.

8. Sub-processors and supply-chain security

See /legal/sub-processors for the current sub-processor list, the data each one handles and the transfer safeguards in place. We monitor dependency vulnerabilities and review significant infrastructure changes.

9. Personal-data breach response

We monitor for security events and have an internal incident-response procedure for containment, eradication, recovery and lessons-learned.
If we become aware of a personal-data breach affecting Customer Personal Data, we notify affected customers without undue delay and in any event within 72 hours, in line with section 9 of the DPA.
We will provide reasonable cooperation, including any information needed for the customer to meet its own notification obligations to data subjects and supervisory authorities.

10. Secure software development

Every production release goes through a pull request from a staging branch that is deployed to a separate test environment first.
Automated tests and a full build run on every pull request and every change to the staging branch.
Dependencies are kept up to date and monitored for known vulnerabilities.
Production source maps are not published.

11. Compliance posture

UK GDPR & Data Protection Act 2018: see the Privacy Policy and DPA.
PCI-DSS: we do not store or transmit cardholder data; payments are handled by Stripe, a PCI-DSS Level 1 service provider.
SOC 2 / ISO 27001: Supplio does not currently hold these certifications. We rely on the certifications of our underlying infrastructure providers and on the controls described here. Achieving an independent attestation is on our roadmap as we grow.

12. Vulnerability disclosure

Security researchers are welcome to report suspected vulnerabilities to security@supplio.co.uk (also listed in our security.txt). Please include enough information to reproduce the issue. We aim to acknowledge reports within two UK business days. We do not currently operate a paid bug-bounty programme; we will not pursue good-faith researchers who:

do not access, modify or delete data beyond what is needed to demonstrate the issue;
do not degrade the Service or affect other customers;
do not exfiltrate data or use it for any purpose;
give us a reasonable window to fix the issue before public disclosure.

13. Customer responsibilities

Strong security is a shared responsibility. Customers should:

protect their administrator credentials and remove users promptly when they leave;
require two-factor authentication in their organisation settings (for staff, and for supplier portal users where appropriate);
follow good account-hygiene practices (no shared logins);
review the audit log periodically; and
configure supplier-scoring weights and automation rules consistent with their own risk appetite.

14. Contact

Security questions, vulnerability reports or requests for a security questionnaire? Email security@supplio.co.uk.

Security Statement