Security at FuseCall

FuseCall processes important business call data, including recordings, transcripts, summaries and workflow outcomes. We design our systems, processes and customer options around practical protection of that data.

Our security approach is based on:

• limiting access to data;
• protecting data in transit and at rest where applicable;
• giving customers retention and access-control options;
• using reputable infrastructure and service providers;
• reviewing subprocessors for privacy and security suitability;
• supporting Australian data residency and sovereign deployment pathways by scope;
• monitoring for operational and security issues; and
• being honest about what we do and do not claim.

FuseCall does not currently claim to hold SOC 2, ISO 27001, IRAP, PCI DSS, HIPAA or any other security or privacy certification.

Do not infer any certification from this page. If a future certification is obtained, we will update this page only after it is verified and approved for publication.

As between FuseCall and our business customers, customers own their Customer Data.

Customer Data may include:

• call recordings;
• call audio;
• transcripts;
• summaries;
• call metadata;
• prompts, scripts and phone-agent instructions;
• customer knowledge-base content;
• workflow outcomes;
• integration data; and
• support and configuration materials.

FuseCall does not claim ownership of customer call recordings, transcripts, summaries or workflow outcomes. We process Customer Data to provide, support, secure and improve FuseCall, and as otherwise described in our Privacy Policy, Terms and customer agreements.

We do not sell Customer Data. Unless a customer specifically agrees otherwise in writing, FuseCall must not use that customer's call recordings or transcripts to train public or third-party foundation models.

Depending on the customer's configuration, FuseCall may process:

• business contact information;
• authorised user account information;
• End Caller phone numbers and contact details;
• call recordings and audio;
• transcripts and summaries;
• workflow outcomes such as booking requests, lead details, tasks or CRM updates;
• technical logs and service metadata;
• support requests; and
• configuration data.

Customers control what calls, scripts, knowledge-base content, integrations and workflows they connect to FuseCall.

Our intended baseline is to protect service data using encryption in transit and encryption at rest where supported by the relevant system, provider and deployment.

In transit

Website, dashboard and API traffic should use HTTPS/TLS where supported. Some telephony pathways may depend on carrier, phone-system and integration constraints, so we do not describe all phone calls as end-to-end encrypted.

At rest

Stored service data, such as recordings, transcripts, summaries and related files, should be protected using storage-layer encryption at rest where supported and enabled by the relevant infrastructure or deployment.

Customer-specific encryption commitments, key-management requirements or sovereign deployment requirements must be documented in the relevant Order, security schedule or data-processing terms.

We restrict access to production systems and Customer Data based on role and need.

Depending on the deployment and system, access controls may include:

• account-based authentication;
• role-based permissions;
• restricted administrative access;
• access removal when no longer required;
• separation between customer accounts or environments;
• audit or activity logs;
• internal confidentiality obligations; and
• multi-factor authentication for administrative systems where available and appropriate.

Customer administrators are responsible for managing their own users, permissions, connected systems and credentials.

FuseCall personnel or approved contractors may access Customer Data only where reasonably needed for:

• implementation;
• customer support;
• troubleshooting;
• security and abuse prevention;
• service reliability;
• billing or account administration;
• legal compliance; or
• another purpose authorised by the customer or agreement.

We expect personnel and contractors with access to confidential or personal information to be bound by confidentiality obligations.

FuseCall uses subprocessors to provide the service. These may include providers for:

• cloud hosting and storage;
• telephony and call routing;
• speech recognition;
• voice generation;
• transcription;
• LLM processing;
• summarisation and classification;
• email, CRM or support operations;
• analytics and monitoring;
• security tooling; and
• customer-selected integrations.

AI voice and LLM providers may process prompts, audio, transcripts, summaries, metadata and outputs so FuseCall can handle calls and create workflow outcomes.

The subprocessors and processing locations used may vary by plan, feature, region, customer requirements and deployment scope. Customer-specific subprocessor commitments should be recorded in the relevant Order, data-processing addendum, security schedule or subprocessor list.

Australian data residency and sovereign deployment options are available by scope.

A data-residency pathway may involve agreeing that certain categories of Customer Data are stored in Australia.

A sovereign deployment pathway may involve additional requirements, such as Australian-hosted infrastructure, restricted provider selection, restricted administrative access, specific support arrangements, or feature limitations.

These options must be scoped before activation. Not every feature, integration, AI provider or support pathway will necessarily be available in every data-residency or sovereign deployment model.

Customers who require Australian-only storage, Australian-only processing, Australian-only support access or specific provider exclusions should raise those requirements before signing an Order.

FuseCall supports configurable retention by scope, plan or customer agreement.

Retention settings may apply to:

• call recordings;
• transcripts;
• summaries;
• workflow outcomes;
• logs;
• exports; and
• connected-system records.

Shorter retention periods can reduce privacy and security risk. Customers should choose retention settings that match their legal, operational and risk requirements.

Some backups, logs, audit records and security records may remain for a limited operational period after data is deleted from active systems. Legal, dispute, fraud-prevention, security or compliance needs may also require limited retention.

We may use logs and monitoring to help:

• keep the service available;
• detect errors;
• investigate support issues;
• identify misuse or suspicious activity;
• measure performance;
• understand usage; and
• respond to security incidents.

Logs may include technical metadata, account activity, system events, API events, error details and limited operational information. We aim to avoid unnecessary exposure of call content in operational logs where practical.

We may use backups, replication, snapshots or similar processes to support continuity and recovery.

Backup and recovery arrangements may vary by deployment, plan, provider and customer scope. Backup retention may not match active-data retention exactly.

Customer-specific backup, recovery-time, recovery-point or business-continuity commitments must be stated in the relevant Order or security schedule.

If we become aware of a suspected security incident affecting Customer Data, we will take steps designed to:

• investigate the issue;
• contain and mitigate harm;
• assess affected systems and data;
• notify affected customers where required by law, contract or reasonable security practice;
• support customers with information needed for their own assessment; and
• improve controls where appropriate.

Where a notifiable data breach or similar legal obligation may apply, we will work with affected customers to assess responsibilities and notification steps.

Security is shared. Customers are responsible for:

• choosing appropriate retention settings;
• configuring account permissions carefully;
• removing users who no longer need access;
• protecting passwords, API keys, integration tokens and phone-system credentials;
• securing their devices, networks and connected systems;
• ensuring scripts and workflows do not collect unnecessary sensitive information;
• providing required privacy, AI-agent and call-recording notices;
• obtaining required consents;
• reviewing call summaries and workflow outcomes before relying on them where appropriate;
• keeping their own systems and CRMs secure; and
• telling us promptly about suspected misuse or unauthorised access.

Online Stripe payments are planned but are not live at the date of this page.

Customers should not configure FuseCall to collect, record or store payment-card CVV/CVC codes, online banking passwords, one-time passcodes, security answers or other sensitive authentication data.

If payment capture is needed in the future, it must be handled through an agreed payment workflow designed for that purpose.

We welcome good-faith reports of potential security vulnerabilities.

Please email hello@fusecall.com.au with the subject line "Security disclosure" and include:

• a clear description of the issue;
• steps to reproduce it;
• affected URLs, accounts, systems or features;
• screenshots or proof-of-concept details if safe to provide;
• your contact details; and
• any suggested severity or impact.

When researching or reporting a vulnerability, you must not:

• access, copy, change or delete other people's data;
• disrupt FuseCall, customers, callers or providers;
• run denial-of-service testing;
• use social engineering, phishing or physical attacks;
• attempt to extort payment or threaten disclosure;
• publicly disclose the issue before we have had a reasonable opportunity to investigate and respond; or
• break the law.

We do not currently offer a paid bug-bounty program. Submitting a report does not guarantee payment, reward or public acknowledgement.

For customers with higher security or procurement requirements, we can discuss additional security documentation, data-residency pathways, subprocessor details and deployment options.

Any customer-specific security commitments must be documented in a signed Order, data-processing addendum or security schedule. This public page should not be treated as a substitute for those documents.

Security contact: hello@fusecall.com.au

Website: fusecall.ai