Our approach (section link)

We design for a small company that holds business data, including employee data inside products such as Staffora. The aim is to reduce the chance of unauthorised access, loss or alteration, and to notice and contain an incident if one happens. Measures are chosen to match the risk. They will change as the products and the hosts change. We will update this page when a material control changes.

Customers remain responsible for their own users, passwords, role design, and for the decision to upload a given category of data. A product is not a suitable store for every kind of data. See the Disclaimer and the Data Processing Addendum summary.

Encryption (section link)

In transit. The corporate Site is served over HTTPS. Traffic between your browser and the Site is encrypted with TLS. We redirect clear-text HTTP to HTTPS in production and we send a strict transport security header.
At rest. [ENCRYPTION AT REST]. We intend production databases and backups to be encrypted at rest on Plesk. Do not read this page as confirmation of a named algorithm, key length or key-management service until that placeholder is replaced.
Secrets. Passwords are not stored in clear text. Payment card numbers are handled by [PAYMENT PROCESSOR], not stored on the corporate Site.

Access control (section link)

Production access is limited to named people who need it for their job.
Administrative access uses multi-factor authentication where the platform supports it. The platforms in scope are [ACCESS CONTROL DETAILS].
Access is removed when a person leaves or changes role.
Customer tenants are separated by the product's access model. A customer admin decides which of their users can see which records.
Support staff do not browse Customer Data as a matter of routine. Access for a support request is limited to what the request needs.

Infrastructure (section link)

The Site and the products are hosted on Plesk. The data-centre region is [HOSTING REGION]. We rely on that host's physical security for the data centre. We are responsible for how the application is configured on Plesk.

The Site sends a content security policy, a frame restriction, a referrer policy and a nosniff header. Dependencies are updated as part of ordinary maintenance. We do not claim a particular patch timeline in public. Critical fixes are prioritised.

Backups (section link)

Production data is backed up on this schedule: [BACKUP SCHEDULE]. Backups are restricted to the same people who may access production, or to a smaller set. We test that backups can be restored: [BACKUP TEST]. A backup is a recovery tool. It is not an archive you can ask us to search for a single deleted record after the production deletion window has passed. See the export window in the Terms of Service.

How we build (section link)

Changes go through review before they reach production.
Production credentials are not committed to source control.
We separate environments so that tests are not run against live customer data unless a customer has agreed a specific test.
Third-party libraries are pinned and updated. We do not represent that every dependency is free of known issues on every day.

Incident response (section link)

If we suspect a security incident we follow four steps. The order can overlap.

Contain. Limit the affected account, key or system so the incident does not spread. We would rather interrupt a feature than leave a door open.
Assess. Find out what data and which customers are affected, and whether personal data is involved.
Notify. Where we are the controller and the PDPA, the GDPR or the UK GDPR requires it, we notify the authority and, where required, the people affected. Where we are a processor, we notify the customer within [PROCESSOR BREACH NOTICE], as the Data Processing Addendum summary describes. Under the GDPR, a controller's notice to its supervisory authority is made without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk.
Recover and learn. Restore service from a clean state or a backup, rotate secrets that may have been exposed, and record what we will change.

We will not describe an open incident in public if that would help an attacker or identify a customer. After it is contained we may post a summary where customers need it.

Reporting a vulnerability (section link)

If you believe you have found a security weakness in a Syncora site or product, email legal@syncora.solutions and, when it exists, [SECURITY_EMAIL]. Please include steps to reproduce, the URL, and the impact you think it has. Give us a reasonable time to investigate before any public disclosure. Do not access data that is not yours, do not run denial-of-service tests, and do not attack physical premises.

A machine-readable contact is published at https://syncora.solutions/.well-known/security.txt (opens in a new tab). We do not operate a paid bug-bounty programme unless this page later says we do. [BUG BOUNTY] We will not take legal action against research that follows this section and the law. This is not an invitation to test systems we do not own.

What we do not claim (section link)

We do not currently hold, and this page must not be read as claiming, any of the following: ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, SOC 2, PCI DSS, Cyber Essentials, or a government cloud certification. [CERTIFICATIONS] If we obtain one, we will name the body, the scope and the date here. Card payments are handled by [PAYMENT PROCESSOR]. Do not send card numbers to us.

We do not promise that the services will be free of vulnerabilities or that a particular uptime percentage applies. Uptime, if any, is only what a signed service-level agreement says.

Contact (section link)

Security contact: legal@syncora.solutions. Dedicated security inbox, when created: [SECURITY_EMAIL]. Syncora (Pvt) Ltd, Colombo, Sri Lanka. Company registration number: [REG NO]. Phone: +94 77 565 2040.