Privacy Policy

Version 1.7 · Effective 27 August 2026

This policy describes how PACE (a product of Becloudsmart) collects, uses and protects your information when you use our website, apps, and API (together, the “Service”).

1. Who we are

PACE is operated by Becloudsmart Pty Ltd. Where this policy refers to “we”, “us”, or “our”, it means Becloudsmart Pty Ltd. You can reach our privacy team at hello@pacemos.ai or via the contact form at becloudsmart.com.

2. Information we collect

We collect information in three categories:

• Account identity. When you or your administrator sign in via Microsoft Entra ID, we receive your display name, email address, Entra object identifier (oid) and Entra tenant identifier (tid). We do not receive your password.
• Workspace content. Actions, decisions, risks, meetings, reports, scorecards, nominations, readiness gates, uploaded knowledge-base documents, and any other data you or your users enter. This is stored in your dedicated database and blob container.
• Operational telemetry. Technical logs such as request paths, response codes, latencies, error traces, and AI call metadata (token counts, model name, duration). We do not log request bodies or response contents.

3. How we use it

We use your information only to operate the Service and to comply with law. Specifically:

• To authenticate you and route requests to the correct workspace
• To render your workspace content back to you and other authorised members
• To ground AI-generated outputs (plans, reports, meeting packs) in your uploaded documents
• To bill you via Stripe for paid plans
• To send transactional email (invitations, billing failures, report notifications) via Resend
• To investigate incidents, debug failures, and prevent abuse

We do not use your workspace content to train any machine-learning model, ours or a third party’s.

4. Third-party processors

We rely on the following sub-processors. Except where noted, each is bound by an enterprise agreement with appropriate data protection terms:

• Microsoft Azure — hosting, database, blob storage, managed identity, Key Vault, Application Insights telemetry. Hosted in Australia (Azure Australia East).
• Microsoft Entra ID — sign-in. We never see your password.
• Anthropic — Claude AI API for grounded generation. This is the default AI engine for every workspace. Per Anthropic’s terms, API data is not used to train their models.
• Voyage AI — embedding API used to index knowledge-base documents for retrieval and to embed your search queries. This is the default embedding engine for every workspace. Per Voyage’s terms, API content is not used to train their models.
• Azure OpenAI Service — chat and embedding inference over workspace content, used in place of Anthropic and Voyage AI when a workspace administrator selects the Azure option under Admin → AI config. We run this on a Becloudsmart-owned Azure OpenAI account in Azure Australia East, using regional (not global) model deployments, so content processed this way stays in Australia. Per Microsoft’s Azure OpenAI terms, customer content is not used to train Microsoft or OpenAI models.
• Stripe — payment processing. We never see your full card number.
• Resend — transactional email delivery.
• Google — web fonts delivered from Google’s content delivery network (fonts.googleapis.com, fonts.gstatic.com) on every page of the Service. Your browser fetches these directly, so Google receives your IP address and browser user-agent. No workspace content or account identity is sent, and no cookies are set. Used under Google’s standard terms rather than a negotiated enterprise agreement.

A workspace administrator can also point the workspace at your own Azure resources — Azure OpenAI, Azure AI Foundry, or Azure AI Search — using credentials you supply. Where that is configured, AI processing, and for Azure AI Search the resulting document index, happen inside your own Azure subscription in whichever region you chose for those resources. They are your resources, not sub-processors we engage, and we do not control where they run or how they are configured.

5. Data residency and workspace isolation

All customer data we hold is stored at rest in Australia, in Microsoft’s Azure Australia East region. There is no per-customer region selection — every workspace resides in the same Australian region. When you use AI features, the relevant workspace content is processed transiently to generate the response; it is not retained by the AI provider and not used for training. Where that processing happens depends on which AI configuration your workspace uses:

• Default (Anthropic and Voyage AI). Content is processed outside Australia, under those providers’ API terms.
• Platform Azure OpenAI. Content is processed in Azure Australia East, on our Azure OpenAI account.
• Your own Azure resources. Content is processed in the region you chose for those resources, which may be outside Australia. If you use Azure AI Search, the indexed document text is also stored there, in your own search index.

Your current AI configuration is shown to workspace administrators under Admin → AI config.

Each paying customer’s workspace data — including the knowledge-base documents, actions, decisions and reports — resides in a dedicated PostgreSQL database and a dedicated Azure Blob Storage container, logically and physically isolated from other customers. Control plane data (your account identity, billing state, audit log) lives in a separate database shared across workspaces but never mixed with workspace data.

6. How long we keep it

• While your account is active: we retain your workspace data so you can use it.
• After cancellation: workspace data stays available in a read-only state for 30 days. After that, the database and blob container are permanently deleted.
• Billing records: retained for 7 years to satisfy tax law.
• Operational logs: retained for up to 90 days.
• Do-not-contact list: if an email we send permanently bounces, or the person receiving it marks it as spam, we record that address so we stop sending to it. We keep that record indefinitely — there is no window after which it is removed, and we do not intend to add one. A suppression only works if we remember it: deleting the entry would start the mail again, which for a spam complaint is the opposite of what was asked for. What we hold is the address itself, whether it was a bounce or a complaint, the reason our email provider gave, and the date. This list is not limited to customers — it covers everyone we email, which includes people invited to a workspace who never joined and people referred to us by a partner who never signed up. A deletion request does not clear it, deliberately; see section 7.
• Audit trail: administrative and security-relevant actions — sign-ins, permission changes, workspace configuration changes, billing events — are recorded in an audit log held in the control plane database. This is a separate record from the operational telemetry above and is kept for much longer: retention is set by your plan, currently 3 months on a partner-sponsored trial, 12 months on Pacemos, and 36 months on Pacemos Enterprise. A workspace whose plan sets no period falls back to 12 months. A nightly job deletes entries once their period has passed.
• Audit archive: before those entries are deleted, a record of each one is appended to a write-once archive in Australian Azure storage. It exists for one purpose — proving the audit log has not been silently shortened — and is not a second copy of the audit trail. Entries archived after 27 August 2026 record no actor: the entry’s identifier and integrity hash, the action name, the timestamp, and the workspace or partner identifier, and nothing that names or points to the person who acted. The workspace identifier still says which organisation an action belonged to, which in a single-user workspace narrows it to one person. Entries archived up to and including that date also carry the acting person’s email address, their Entra object identifier (oid), and the event’s recorded details. The archive sits under an Azure immutability policy that blocks any edit or deletion, ours included, and nothing removes entries from it — so treat its retention as indefinite.
• Backups: the database server keeps 35 days of point-in-time restore history. Separately, each workspace database is dumped nightly to a write-once storage account and kept for the window your plan sets — 30 days unless your plan specifies otherwise — and the control plane database is dumped nightly and kept for 30 days. Data you delete or change stays inside those backups until they expire.

7. Your rights

Under the Australian Privacy Act 1988 (Cth) and the Australian Privacy Principles, you may request access to, or correction of, the personal information we hold about you, and may ask us to export or delete it. You can also lodge a complaint with the Office of the Australian Information Commissioner (OAIC).

To exercise these rights, email hello@pacemos.ai. We respond within 30 days.

Limits on deletion. Some copies of your information sit outside a deletion request, by design:

• Backups hold the pre-deletion state until they expire — up to 35 days of point-in-time restore history on the database server, and your plan’s backup window (30 days by default) for the nightly dumps. We keep a record of completed deletion requests so that if a workspace is ever restored from a backup taken before your request, the deletion is re-applied to the restored copy before it returns to service.
• The audit trail is not rewritten on request. Entries recording what was done, by whom, and when are kept for the plan period in section 6 and deleted when it expires.
• The audit archive cannot be edited or deleted at all — not by you, and not by us. Entries archived up to and including 27 August 2026 carry the acting person’s email address and Entra object identifier; entries archived after that date record no actor, as set out in section 6.
• The do-not-contact list is not cleared by a deletion request. Removing your address from it would start our email reaching you again, which is the opposite of what a bounce or a spam complaint asked for — so the entry stays, indefinitely. This is a deliberate exception, not an oversight; section 6 sets out exactly what it holds.

In short: a deletion request clears the copies we can query, the remaining copies age out with the backup windows in section 6, and the audit archive and the do-not-contact list stay.

8. Security

We use industry-standard safeguards including TLS 1.2+ for all data in transit, encryption at rest on all Azure storage, per-workspace database passwords stored in Azure Key Vault, managed-identity access control for every backend call, Entra multi-factor authentication, and short-lived SAS URLs for all blob downloads. No system is perfectly secure — report suspected issues to hello@pacemos.ai.

If a data breach occurs that is likely to result in serious harm, we will notify affected customers and the Office of the Australian Information Commissioner in accordance with the Notifiable Data Breaches scheme.

9. Cookies

We use a single Auth.js session cookie (authjs.session-token, prefixed __Secure- on HTTPS) to keep you signed in. It is HTTP-only, same-site lax, and expires 4 hours after you sign in. That limit is absolute rather than an idle timeout — staying active does not extend it, and you are asked to sign in again once it passes. We do not use advertising or analytics cookies.

10. Children

The Service is not directed at children under 16. We do not knowingly collect information from children.

11. Changes

If we change this policy materially we’ll email account administrators and update the “last updated” date at the top. Continued use after the change means you accept the updated policy.

12. Contact

For privacy questions, security reports, or anything else, reach us at hello@pacemos.ai.