Public pages
6
The customer-facing documents that should be easy to find in-app.
Trust Centre
Privacy, security, and data handling information for customers
This is the customer-facing policy library for Cadence. It brings together the documents that should be easy to find in a business application like this: privacy, security, data processing, subprocessors, hosting regions, and AI-use commitments.
Internal operational records such as incident runbooks, breach record templates, DSAR workflows, and pre-production checklists are maintained separately and are not part of the public customer surface.
Contact
Use this address for privacy, security, or contract questions.
Approved processing scope
What Cadence is designed to handle
Cadence is designed to handle personal data and approved higher-sensitivity workflow data, including financial, legal or matter, and family information where that information is relevant to the module the customer has chosen to use.
This is a bounded approval, not a blanket permission to submit any sensitive data. Health data, biometric data, genetic data, racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, sex life or sexual orientation, and criminal-offence data remain outside scope unless they are separately reviewed and agreed in writing.
Approved workflows
Modules may handle debts, assets, income, transaction details, account references, case references, household composition, dependant details, and family circumstances where those details are part of the approved workflow.
What stays excluded
The current approval does not broaden Cadence into a general health, biometric, genetic, Article 9, or criminal-offence processing platform.
AI stays separately gated
This approved workflow scope does not permit customer data from these workflows to be sent to AI systems without a separate vendor review and privacy approval path.
Security overview
Security commitments customers should be able to review easily
The customer-facing security surface should explain how Cadence protects accounts and customer data without forcing users to read internal implementation notes. The items below are the commitments that matter most in day-to-day use.
Authentication
Passwords are hashed with bcrypt, MFA is supported with authenticator app or email code, and repeated failed logins trigger account lockout.
Data handling
Approved financial, legal, and family workflow data is handled through access-controlled module routes and processed in memory only. It is not written to local disk or kept as persistent file storage.
Logs and monitoring
Security events are logged, token-bearing auth paths are redacted before access logs are written, and audit history is append-only.
Backups and response
Database backups are managed through Supabase, restore testing is required, and incident runbooks cover containment, assessment, and customer communication.
Core controls
- HTTPS, HSTS, CSRF protection, and security headers are applied as standard controls.
- Sensitive values such as TOTP secrets, module settings, and connection strings are encrypted at rest.
- Password reset and account setup links are stored as hashes, not raw values.
- Structured security events cover auth failures, admin access, privacy exports, MFA reset actions, and maintenance outcomes.
Customer assurance points
- Nightly cleanup removes expired tokens, stale login-attempt records, and old audit entries according to the retention schedule.
- Customer data exports exclude secrets, hashes, and encrypted values.
- Legal holds can pause delete and anonymise actions where a lawful retention need exists.
- Incident handling covers both Australian Privacy Act breach assessment and GDPR notification thresholds.
Data processing terms
The contractual terms customers typically look for first
Customers generally do not need the full internal drafting history of a DPA inside the app, but they should be able to find the key commitments quickly. These points summarise the live customer-facing position reflected in Cadence's data processing documentation.
| Topic | Customer-facing position |
|---|---|
| Roles | Cadence acts as controller for its own platform operations and as processor when handling customer data on behalf of a client. |
| Instructions | Customer personal data is processed only on documented customer instructions and only for the platform services being provided. |
| Approved higher-sensitivity scope | Cadence can handle approved financial, legal, and family data where that information is relevant to an approved module workflow and falls within the customer contract scope. |
| Excluded categories | Health, biometric, genetic, racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, sex life or sexual orientation, and criminal-offence data are not part of the ordinary approved scope unless separately reviewed and agreed in writing. |
| Subprocessors | Customers are notified before a material subprocessor change and existing subprocessors are listed in the trust surface below. |
| Data subject support | Cadence assists customers with export, deletion, and privacy-response tooling where it acts as processor. |
| Customer responsibilities | Customers remain responsible for their own lawful basis, collection notices, and any extra review needed before asking Cadence to process excluded categories. |
| Breach support | For customer-controlled data, Cadence’s processor commitment is notification without undue delay and in any event within 24 hours of awareness. |
| Return and deletion | At contract end, customers can elect export or deletion within the contractual window, with automated cleanup supporting the platform retention schedule. |
| International transfers | Where EU or UK transfers require a safeguard, Cadence records the applicable transfer wording and region decision in the customer contract pack and supporting vendor records for that environment. |
What should be visible in-app
A customer should be able to see the high-level DPA terms here in the app, while the full executable DPA remains part of onboarding and contract exchange. If you need the current template or a client-specific copy, contact support@cadence-platform.com.
Subprocessors
The vendor list customers should not have to hunt for
Customers should be able to review the main third parties involved in service delivery from within the app. The list below is the customer-facing subprocessor summary and avoids internal-only notes that are better kept in operational registers.
| Vendor | Purpose | Region approach | Customer note |
|---|---|---|---|
| Fly.io (Superfly Inc.) | Application hosting and scheduled operational jobs. | Production hosted in Dublin, Ireland (EU). Staging in US East. Superfly Inc. is a US legal entity with a self-serve DPA at fly.io/legal/dpa/. | If the hosting role or region changes materially, customers receive notice under the DPA change process. |
| Supabase | PostgreSQL data storage and managed backups. | EU customer data defaults to an EU-region database; AU-only customers currently use the approved non-EU path documented in the regional hosting policy. | The exact region decision is recorded per environment and per client where required. |
| Google LLC (Google Workspace) | Transactional email delivery — password reset, account setup invites, and email MFA codes. | United States. Transfers covered by Google's Standard Contractual Clauses and Google Workspace Data Processing Amendment. | Customers are notified before any material provider change that affects data handling or transfer position. |
How changes are handled
New or replacement subprocessors are reviewed before production use and customer notice is handled through the DPA notice process for material changes.
What this page is for
This page is the clean customer-facing summary. The full internal subprocessor register remains the operational source of truth for review dates, contract evidence, and open actions.
Regional hosting and transfers
Where customer data is hosted and how region decisions are made
Regional hosting is something customers usually expect to find in a trust or legal centre, not buried in a contract appendix. This section presents the rules in plain English.
EU / EEA customers
The default position is an EU-region Supabase database, with the exact region recorded for the client environment.
Australian-only customers
The current approved production path allows the documented non-EU route while region decisions remain recorded and reviewed.
Staging
Staging is separate from production and must contain synthetic or masked data only.
| Customer profile | Default approach | Customer-facing explanation |
|---|---|---|
| EU / EEA or mixed EU + AU users | Use an EU-region database by default. | EU rules take precedence when a customer serves both EU and Australian users. |
| Australia-only customers | Use the currently approved regional path and keep the decision recorded. | The exact region and transfer basis are documented rather than assumed. |
| Cross-border access | Administrative access from outside the data region is assessed as part of the transfer position. | This is especially important for EU data accessed from Australia for support or administration. |
AI use policy
What customers should be told about AI use with their data
If AI is relevant to customer data, the position should be visible in-app. The current public-facing commitment is intentionally strict: no real customer data is sent to an AI system until the governance, vendor review, and privacy review steps are complete.
Current status
No approved AI vendors for live customer data
As of 17 April 2026, no AI vendor is approved for live personal information or customer confidential information.
Customer-facing commitments
- Public consumer AI tools are prohibited for customer personal information and customer confidential information.
- No AI vendor is approved for real customer data until vendor review, PIA or DPIA sign-off, redaction checks, and written approval are complete.
- Training or fine-tuning on customer data is prohibited by default.
- Any approved AI-assisted output that affects customer outcomes must go through human review.
- If an AI-related incident occurs, it is escalated through the same privacy and incident response process as any other data incident.
Questions and requests
Need the full policy pack or a customer-specific answer?
Customers usually need a short, clear in-app trust surface first and the detailed contract or assurance material second. If you need the full privacy, contract, or security pack, contact the privacy and security address below.
Contact
support@cadence-platform.comUse this for privacy questions, subprocessor requests, regional hosting clarifications, DPA requests, or customer security due diligence.