Security Policy
How we protect your data, and how to report a vulnerability.
This Policy describes our approach at a level appropriate for public disclosure. It deliberately omits implementation detail: publishing the specifics of a defence tells an attacker where to aim.
1. What we do
1.1 Encryption
- In transit: all connections — dashboard, APIs and published sites — are encrypted using current TLS. Certificates are provisioned automatically, including for custom domains.
- At rest: data stored in our databases and object storage is encrypted at rest by the underlying platform.
- Credentials: account passwords are stored only as salted hashes using an industry-standard adaptive algorithm. We cannot recover your password, and neither can anyone who obtains our database. Third-party credentials you supply for integrations are stored encrypted.
- Payment data: full card numbers, CVV and PIN never reach our systems. Card entry happens in the payment provider’s own PCI-DSS-compliant environment; we hold only a provider-issued token and non-sensitive descriptors.
1.2 Access control
- Authentication is required for all non-public functionality.
- Session tokens are held in cookies marked HttpOnly and Secure, so they cannot be read by page scripts and are only sent over encrypted connections.
- Role-based permissions govern what each team member can do.
- Sessions can be invalidated, and are invalidated automatically on password change.
- Internal access to production systems is limited to personnel who need it, and is logged.
1.3 Tenant isolation
Every customer’s data is logically separated. Requests are scoped to the authenticated customer’s own data, and isolation is enforced at the data-access layer rather than relying on interface behaviour alone.
1.4 Application security
- Input submitted to the Service is validated against defined schemas.
- Content published through the editor is sanitised before rendering, to prevent script injection.
- Database access uses parameterised queries.
- Standard browser security headers are applied.
- Outbound requests made on a customer's behalf are constrained to prevent them being used to reach internal systems.
- Rate limiting protects authentication and abuse-prone endpoints from brute-force and flooding.
- Payment and webhook callbacks from third parties are cryptographically verified before they are acted on.
- Dependencies are tracked and updated.
1.5 Monitoring and resilience
- The Service is monitored for availability, errors and anomalous activity, with alerting to the operations team.
- Security-relevant events are logged and retained per our Data Retention Policy.
- Encrypted backups are taken regularly and are access-controlled.
1.6 Organisational measures
- Personnel with access to customer data are bound by confidentiality obligations.
- Access is granted on a need-to-know basis and revoked when no longer required.
- Vendors handling personal data are assessed and bound by data-protection terms — see Sub-processors.
2. What we ask of you
Security is shared. You are responsible for:
- Using a strong, unique password and not reusing it elsewhere.
- Keeping credentials confidential and not sharing accounts — add team members as Users instead.
- Granting each team member the minimum role they need, and removing access when they leave.
- Keeping the contact email on your account current, so we can reach you about security matters.
- Keeping your own devices and email account secure — most account compromises begin there.
- Telling us immediately at security@postlyo.com if you suspect unauthorised access.
- Exporting your content regularly. Our backups are for our disaster recovery, not your archive.
3. Reporting a vulnerability
We welcome reports from security researchers and will not pursue legal action against anyone who reports in good faith under this Policy.
3.1 How to report
Email security@postlyo.com with a description of the issue and its potential impact, clear steps to reproduce it, the affected URL or component, and any proof-of-concept material.
3.2 What we commit to
| Commitment | Timeframe |
|---|---|
| Acknowledge your report | Within 2 business days |
| Initial assessment | Within 5 business days |
| Progress updates | At least every 10 business days until resolved |
| Coordinated disclosure | We will agree a timeline with you and will not ask for indefinite silence |
| Credit | We will acknowledge your contribution publicly if you wish |
3.3 Rules for researchers
Test only against your own account and data. You must not:
- access, modify or delete data belonging to anyone else;
- degrade the Service — no denial-of-service, load testing, or automated scanning at volume;
- use social engineering, phishing, or physical intrusion against our staff or vendors;
- test third-party services we depend on (report those to the third party directly);
- publicly disclose the issue before we have had a reasonable opportunity to fix it; or
- demand payment as a condition of disclosure.
Testing that stays within these rules is authorised and is not a breach of our Acceptable Use Policy. Testing outside them is not authorised.
3.4 Out of scope
Reports of the following will usually be closed without action: missing security headers with no demonstrated impact; issues requiring physical access or a compromised device; theoretical attacks without a working proof of concept; unvalidated automated scanner output; email configuration issues with no demonstrated exploitability; social engineering; and vulnerabilities in third-party services.
3.5 Rewards
We do not currently operate a paid bug bounty programme, but we recognise contributors publicly.
4. Incident response and breach notification
If a security incident affects customer data, we will:
- Contain and investigate. Isolate the issue, assess scope and impact, preserve evidence.
- Notify regulators. Where a personal data breach is likely to result in a risk to individuals, we notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it.
- Notify affected customers without undue delay, so they can meet their own notification obligations to their users.
- Notify individuals directly where a breach is likely to result in a high risk to their rights and freedoms, or where the law otherwise requires it.
- Tell you what we know — the nature of the incident, the categories and approximate volume of data involved, likely consequences, measures taken, and a contact point — without waiting for the investigation to be complete.
- Remediate and review. Fix the root cause and conduct a post-incident review.
We will not conceal a breach, and will not delay notification to manage reputational impact.
5. Certifications and audits
We hold no third-party security certification at this time. We follow the practices described in this Policy, but we do not claim SOC 2, ISO 27001, or PCI-DSS certification.
Regarding payments: card data is handled by a PCI-DSS-compliant payment provider and does not reach our systems. That is a statement about our provider, not a claim that we are certified.
To be updated by the website owner if a certification is later obtained — never claim one you cannot evidence with a current attestation.
6. Contact
| Purpose | Contact |
|---|---|
| Vulnerability reports | security@postlyo.com |
| Suspected account compromise | security@postlyo.com |
| Abuse | abuse@postlyo.com |
| Privacy and data protection | privacy@postlyo.com |
| Legal | legal@postlyo.com |
This document is provided in English. If we publish a translation and there is a conflict, the English version governs unless local law requires otherwise.