Security and data protection

Polysync is a managed service running on Microsoft Azure. This page explains where your data lives, how access is controlled, and how it is protected. For legal detail see the Privacy Policy and Terms of Service.

Microsoft 365 Certification

Polysync has achieved Microsoft 365 Certification, an independent security and privacy audit of the application and the environment that runs it. As well as the application's security controls, the audit checked how Polysync is operated day to day, including:

• Security patches applied within set deadlines.
• Vulnerability scans every quarter.
• Multi-factor sign-in for all administrative access.
• Security logs kept and reviewed.
• Every code change documented and tested before release.
• An independent penetration test.

The certification is renewed every year. You can view Polysync's listing on Microsoft Learn, which gives your own security review a finished audit to start from.

Your data stays in Australia

Everything Polysync stores — your platform connections, schedules, task configuration and the history of every run — is held in Microsoft Azure's Australian data centres.

Polysync does not move your pipeline data. Your pipelines, notebooks and models keep running in your own cloud accounts; Polysync stores only the configuration and run records needed to orchestrate them.

Sign-in with Microsoft

Your team signs in with the Microsoft Entra ID work accounts they already have. That means:

• No new passwords. Polysync does not see or store a password for sign-in.
• Your policies apply. Multi-factor authentication and conditional access rules set by your organisation apply unchanged.
• Leavers lose access straight away. Disabling someone's Microsoft account removes their access to Polysync too.

Inside Polysync, each user has a role in each instance that controls what they can see and change.

Your data is separated, not just filtered

Each customer's data sits in its own dedicated schema in the database, rather than being mixed into shared tables and filtered by a customer column. Data is encrypted in transit (TLS) and encrypted again at rest.

Credentials stay in a vault

Credentials for your platforms are kept in a secret vault, never typed into Task parameters:

• Your own vault — Azure Key Vault, AWS Secrets Manager, Google Cloud Secret Manager or HashiCorp Vault. Polysync reads the secret when a task is dispatched. See Secret Vault.
• Polysync's managed vault — if you would rather not link your own, Polysync can hold the credential in its managed Azure Key Vault.

Either way, secrets are encrypted at rest and referenced by name (vault://…) rather than stored in your configuration.

Polysync's own service credentials live in a dedicated Azure Key Vault that is not reachable from the public internet. Polysync's services authenticate to each other with Azure managed identities, so there are no shared keys to copy or leak.

Backups you can restore

• The database can be restored to any point in the last 35 days.
• Weekly, monthly and yearly backups are kept beyond that.
• A real restore has been carried out and timed, rather than assuming the backups would work.

The Copilot and your data

Polysync Copilot runs on Azure OpenAI, and your data is not used to train models. It cannot change your setup without your approval, and it is limited to your organisation's instance. See Polysync Copilot.

Who you are dealing with

Polysync is built and owned by Polysync Data Solutions Pty Ltd (ABN 87 683 785 686), an Australian registered company bound by the Privacy Act 1988 and the Australian Privacy Principles. See Why Polysync for more about the company.