Trust
The parts of Plio that exist specifically so that the wrong person cannot read the wrong record.
Describes the controls in place as at . VYZN Info Tech LLP, Ahmedabad, Gujarat, India.
Role and team scoping is applied where records are fetched, not where they are drawn. A Manager's request returns their team's rows; a Sales user's returns their own. Editing the interface, or calling the API directly, does not widen what comes back.
Every record carries the organisation it belongs to, and every query is scoped to the caller's organisation. Users who belong to more than one org switch between them explicitly; nothing crosses.
Plio never asks for a mail password. Each user grants access through Google or Microsoft, the token is bound to that user, and they can revoke it from their provider account at any time. No shared mailbox credential exists to leak.
Every create, update and delete is recorded with who did it, when, and a field-by-field before and after diff. Retention follows your plan; Enterprise keeps everything.
An admin decides which roles can see which tabs at all. A role without access to the Audit log tab cannot reach it, in the UI or otherwise.
Being able to leave is a security property. CSV export on all 7 record modules and PDF export from Reports are available to you at any time, without asking us. Profile → Privacy & your data → Download your data also gives a single JSON export of everything Plio holds about your own account.
Plio runs on dedicated Linux servers hosted with Linode in India. The application, the PostgreSQL database and the Redis instance all sit on managed infrastructure inside that estate; the database and Redis are not exposed to the public internet and accept connections only from the application itself.
Every connection to Plio is HTTPS. Certificates are issued by Let's Encrypt and renewed automatically, and plain HTTP is redirected rather than served, so there is no unencrypted path to the API or the web app. Traffic between Plio and Google, Microsoft and Meta is TLS-verified against those providers' own certificates.
Stored OAuth refresh tokens and mailbox credentials are encrypted at rest with Fernet (AES-128-CBC with an HMAC-SHA256 signature) using a key derived from a server secret held outside the database, so a copy of the database alone does not yield a working mailbox token. Passwords are never stored, only bcrypt hashes. We do not claim whole-disk or whole-database encryption at rest — the encryption above is applied to the credential tables specifically.
The database is backed up daily, and backups are periodically restored into a separate environment to verify that they are usable. Restore testing is part of the cadence rather than an assumption about it.
We do not currently hold a security certification such as ISO/IEC 27001 or SOC 2, and we make no claim to one. If your procurement process requires a security questionnaire, we will complete it and identify any control that is not yet in place.
Production data is reachable only by the small number of named engineers who operate the service, over SSH. There is no support tool that lets us browse a customer's records from inside the product, so there is no quiet path into your data from the application side.
We access an organisation's data only when you ask us to, to investigate something you have reported. Actions taken inside the application are written to the same audit log you can read yourself, so support activity on your records is visible to you rather than only to us.
Access is presently governed by a maintained list of authorised personnel rather than by a formal approval workflow with scheduled access reviews. We expect to formalise this control as the team grows, and disclose its current form here so that it can be assessed on its merits.
Send it to support@pliocrm.com with enough detail to reproduce it. We will confirm receipt within two working days and keep you updated until the issue is closed. Please do not test against another customer's organisation or against live customer data, and give us 90 days before publishing so a fix can reach the people running it.
We do not operate a paid bug bounty. We will credit you by name in the fix announcement if you would like us to.
If you believe data in your organisation has been accessed or disclosed without authorisation, write to support@pliocrm.com with “Security incident” in the subject line. Where we become aware of a personal data breach affecting your organisation, we will notify you without undue delay, with the information you need to meet your own notification obligations, and will co-operate with your response.
This page describes the technical and organisational measures in place as at the date shown above. It is provided for information, does not form part of any contract, and is not a warranty, guarantee or representation as to the security of the service or of any data processed through it.
Security measures evolve. We may add, change or withdraw any control described here without notice, provided we do not materially reduce the overall level of protection. Nothing on this page should be read as a commitment to maintain a specific technology, vendor, configuration or cadence.
No system is immune from compromise. We do not represent that the service is impenetrable or that unauthorised access, loss or alteration of data cannot occur. Your own obligations — managing user accounts and roles, revoking access when someone leaves, keeping your devices and mailboxes secure, and maintaining your own exports — are a necessary part of the outcome and remain yours.
Where you have signed an Enterprise agreement or data processing agreement with us, that document governs our security obligations to the extent of any inconsistency with this page. Our Terms and Privacy notice apply in full, including the disclaimers and limitation of liability set out there.