01Standards and status
What we claim, and what we do not
Information Security Management Systems
Our security controls are implemented against, and mapped to, Annex A of ISO/IEC 27001:2022. We are not yet certified by an accredited body.
Privacy Information Management Systems
Our privacy controls extend the above using the ISO/IEC 27701 PIMS control set for organisations acting as both controller and processor.
United Kingdom data protection law
Plenix is established in the United Kingdom and processes personal data in accordance with the UK GDPR and the Data Protection Act 2018.
European Union General Data Protection Regulation
Where we process the personal data of individuals in the EEA, we do so in accordance with the EU GDPR, including the use of Standard Contractual Clauses for restricted transfers.
Customer Data is hosted in the United Kingdom. Our processing terms are in the Data Processing Agreement, and every third party with access is listed on the Sub-processors page.
02Tenant isolation
The most common failure in multi-tenant software is one customer seeing another’s data because a query forgot its filter. We designed that class of bug out rather than relying on discipline.
- A separate database per tenant. Not a shared table with a tenant column — a distinct database, so a missing filter returns nothing rather than someone else’s records.
- Binding at the edge. Every request resolves its tenant from the authenticated token and subdomain before any handler runs, and is given a connection scoped to that tenant only.
- Platform administration is separate. Our own staff platform is a different application surface from any customer tenant, guarded independently.
- Uploaded files are namespaced by tenant, and file operations are bound to the caller’s tenant so a reference cannot be pointed at another organisation’s storage.
03Encryption
- In transit — TLS 1.2 or higher everywhere, with HSTS. Agents and integrations connect over TLS.
- At rest — databases, uploaded files and backups are encrypted on disk.
- Field level — sensitive personal data is encrypted in the application before it reaches the database, so it is not present in plaintext there or in a database backup.
- Credential vault — customer-stored credentials are encrypted with per-tenant separation, and access is logged.
- Passwords — hashed with a modern adaptive algorithm, never stored or logged in a recoverable form.
- Key management — encryption and signing keys are held outside source control, are rotatable, and the application refuses to start on a weak or default signing key.
04Access control
For your users
- Role-based access control enforced server-side on every request, not merely by hiding buttons in the interface.
- Multi-factor authentication (TOTP) available on every plan, with backup codes.
- Single sign-on and SAML for customers who want identity managed centrally.
- Granular module and permission gating, so a role only reaches the areas it needs.
- Enforced password change on first login, and brute-force rate limiting on authentication endpoints.
For our staff
- Least privilege and need-to-know. Access to a customer tenant is not routine and is not granted by default.
- Individually attributable accounts — no shared administrative logins.
- Support access is logged, and is normally exercised only at the customer’s request.
- Access is reviewed periodically and revoked promptly when someone changes role or leaves.
05Audit and logging
- Every mutation in the platform writes an audit record — who, what, when, and from where — captured centrally rather than left to each feature to remember.
- Customers can query their own audit trail; it is evidence for their own compliance obligations, not just ours.
- Authentication events, MFA changes, permission changes and API key use are logged and retained.
- Logs are protected against tampering and are excluded from ordinary application access.
06Backups and resilience
- Automated encrypted backups on a defined schedule, stored separately from production.
- Documented restoration procedure with defined recovery point and recovery time objectives, tested periodically — an untested backup is a hope, not a control.
- Health monitoring with alerting; deployments are verified against a health check and rolled back on failure.
- Live service status is published at status.plenix.cloud.
07Secure development
- Security review of changes before release, with automated tests in the deployment pipeline.
- Input validation applied globally, with output encoding to prevent injection and cross-site scripting.
- Uploaded files are typed and constrained on the server, and stored so they cannot be served back as executable content.
- Dependency scanning and prioritised patching by severity.
- Secrets never committed to source control; production configuration is held only on production systems.
- Regression tests written specifically for authorisation defects, so a fixed access-control bug cannot quietly return.
08Incident response
- A documented response procedure covering detection, triage, containment, eradication, recovery and review.
- Affected customers are notified of a personal data breach within 24 hours of us becoming aware, per clause 8 of the DPA — ahead of the 72-hour regulatory deadline that then applies to the customer as controller.
- Evidence is preserved, and a post-incident review produces corrective actions that are tracked to completion.
- We do not wait for complete information before the first notification; we report in phases.
09ISO/IEC 27001:2022 control mapping
How our measures map to the four Annex A themes. This is the summary; a full statement of applicability is available under NDA — see section 13.
| Annex A theme | How we address it |
|---|---|
| A.5 — Organisational | Documented information security and acceptable use policies reviewed at least annually; defined security responsibilities; supplier due diligence and written data protection terms before engagement; asset and information classification; incident management procedure; continuity planning; documented legal, regulatory and contractual requirements. |
| A.6 — People | Screening proportionate to access; confidentiality obligations in every contract; security and data protection training at induction and periodically; joiner, mover and leaver process with prompt access revocation; a defined disciplinary route for security breaches. |
| A.7 — Physical | Production infrastructure is hosted in professionally operated data centres with their own physical access control, environmental protection and monitoring. We hold no customer data on office equipment; endpoints are encrypted and access to production is not granted from unmanaged devices. |
| A.8 — Technological | Per-tenant database isolation; role-based access enforced server-side; MFA and SSO; encryption in transit, at rest and at field level; secrets management; logging and monitoring with protected audit trails; segregation of environments; secure development and change control; vulnerability management and patching; backup and tested restoration; malware and abuse protections; rate limiting and input validation. |
10ISO/IEC 27701 privacy extension
ISO/IEC 27701 extends the above with privacy-specific controls, split by role. Plenix is both — a controller for its own account data, and a processor for Customer Data.
| Area | How we address it |
|---|---|
| As controller (Annex A) | Documented lawful basis for each purpose, published in the Privacy Policy; transparency notices at the point of collection; a defined route for data subject rights with a one-month response target; retention schedule with defined periods and deletion; privacy by design in the development process; records of processing activities. |
| As processor (Annex B) | Processing only on documented customer instruction; no use of Customer Data for our own purposes and none for model training; general sub-processor authorisation with 30 days’ notice and a right to object; assistance with data subject requests; breach notification within 24 hours; deletion or return at the end of the service with written certification on request. |
| Transfers | UK IDTA and EU Standard Contractual Clauses for restricted transfers, transfer risk assessments, and supplementary technical measures. Transfer mechanisms are named per provider on the Sub-processors page. |
| Data minimisation | Only the data needed for a feature is collected or transmitted; AI features send only the content required for the specific request, and only when invoked. |
12Reporting a vulnerability
If you have found a security issue, we want to hear about it and we will not take legal action against anyone who reports one in good faith under this policy.
- Report to security@plenix.cloud with enough detail to reproduce the issue.
- We acknowledge within 2 business days and give an assessment within 10 business days.
- Please give us a reasonable opportunity to fix the issue before disclosing it publicly. We will keep you updated and credit you if you would like.
Please do not
- Access, modify or delete data belonging to anyone else — use your own test account.
- Run denial-of-service or volumetric testing against production.
- Use social engineering, phishing or physical intrusion against our staff or providers.
- Test third-party services we depend on; report those to the provider concerned.
Testing beyond the above needs written permission first — write to security@plenix.cloud. We do not currently run a paid bounty programme.
13Due diligence and questionnaires
We answer security questionnaires and support vendor assessments. On request we can provide, under NDA where appropriate:
- A completed security questionnaire, or our answers mapped onto your template.
- Our statement of applicability and control mapping in detail.
- A countersigned Data Processing Agreement, or review of your own template.
- Penetration test summary, architecture overview, and business continuity documentation.
Start with security@plenix.cloud for technical assessments, or legal@plenix.cloud for contractual documents.