Security & privacy
Security and privacy by design.
Your CRM holds the most sensitive list your business owns. bizzMate uses layered technical and operational safeguards to protect that information and keep the service available to you.
No credit card required · Set up in minutes · AUD pricing
How to read this page
Our controls cover identity and access management, workspace isolation, encryption, monitoring, backups, secure development and operational recovery. We describe them accurately and avoid security or compliance claims that have not been independently established. The commitments we have already published are in our Privacy Policy.
Data protection
In transit, at rest, and on the way out.
What happens to your data while you are a customer, and what happens to it when you are not.
Encrypted in transit
All traffic to bizzMate is served over TLS, and the service instructs browsers to refuse an unencrypted connection to it. This is also stated in section 9 of our Privacy Policy.
Backups are encrypted before they leave our environment
Database, file and configuration backups are encrypted using authenticated encryption at the point they are created — so a backup copy is never written, transferred or stored in readable form.
Credentials and secrets are handled as secrets
Passwords are stored hashed, never in a recoverable form. Operational secrets are supplied to the service as configuration rather than held in the codebase, and our error reporting strips passwords, tokens, keys, cookies and customer content before anything is recorded.
Payment details never touch our systems
Card details are collected directly by Stripe. bizzMate does not see or store full payment card numbers.
Retention and deletion
Account and customer data is retained while your account is active and removed from production systems within 30 days of account deletion. Audit records are retained for one year, or up to seven years for billing-related records as required by Australian tax law.
Export and deletion are self-service
You can export your workspace data whenever you want, and a workspace owner can delete the workspace, which begins removal of the associated data.
Workspace isolation
Your workspace is separated from every other workspace.
Multi-tenant separation is the single most important control in a CRM, so it is not left to application code to remember.
Isolation is a mechanism, not a policy
Every workspace's records are separated by workspace-level isolation enforced in the data layer rather than by application code remembering to filter. The application holds only restricted, least-privilege access, and the active workspace is established for the duration of each operation — so a request cannot return another customer's records even if application code asks it to.
Isolation is tested, not assumed
Cross-workspace isolation is covered by automated tests that run against real dependencies on every change. A feature that touches workspace data ships with an isolation test alongside it, and those tests must pass before a release is built.
AI runs inside the same boundary
AI features read your workspace data through the same isolated, permission-checked path as the rest of the product. There is no privileged shortcut for AI, and it cannot read across workspaces.
Administrative access is a separate boundary
The platform operator console is a completely separate authentication boundary with its own login, its own session and its own signing secret. A workspace user's session cannot reach operator functions, and multi-factor authentication is required for administrative access.
Identity and access
Who can do what, decided by the server.
Roles, ownership and visibility are checked on every request, and administrative access is a separate boundary entirely.
Three roles, enforced on the server
Owner, admin and member. The interface hides what you cannot use, but that is cosmetic — every permission is checked by the API. Hiding a button is never the security control.
Record ownership and visibility
Contacts, organisations, deals and activities each have an owner. Owners and admins can set each record type to public across the workspace, or private so only the owner and admins can see it.
Sign-in options
People can sign in with Google, with Microsoft, or with an email address and password. At signup a new password is checked against known-breached password lists, so you are warned before choosing one that has already leaked.
Session handling
Sessions use signed tokens in http-only cookies, verified on every request. Signing out ends the session, and deactivating a user removes their access to the workspace immediately.
Multi-factor authentication where it matters most
Multi-factor authentication is required for privileged administrative access to the platform. On individual workspace sign-in, accounts are protected by password hashing, breached-password screening and signed session cookies; workspace-level MFA is not part of the product today.
Application security
Secure development, not just secure intentions.
How a change gets from an idea to your workspace, and what has to be true before it does.
Every change is reviewed before it merges
Changes are proposed, reviewed and approved before they reach the main line of development. Nothing reaches customers on the strength of one person's confidence alone.
Automated checks gate every release
Type checking, linting and an automated test suite — including integration tests that run against real dependencies rather than mocks — must pass before a release is built. A release is built from a specific, recorded revision of the reviewed code.
Input is validated against shared schemas
Requests and AI-generated output are both validated against a single shared set of schemas before they are trusted, so the rules the interface applies and the rules the server enforces cannot drift apart.
Least privilege by default
The application runs with the narrowest access it needs to do its job. Elevated access is reserved for a small number of explicit, justified operations rather than being the default path.
Protection against common web risks
Security response headers are applied across the service, sensitive endpoints are rate limited to blunt automated abuse, authentication uses signed http-only cookies, and error reports are stripped of sensitive values before they are recorded.
Secure cloud delivery
bizzMate is delivered through a controlled cloud environment with restricted production access, encrypted communications, monitored service health and managed release procedures. We describe the safeguards around that environment rather than its internal composition — the controls below are the part that should matter to your assessment.
Monitoring and operational security
Knowing when something is wrong.
Monitoring, alerting, restricted production access and controlled change — the operational half of security.
Service health is monitored
The service continuously checks its own health and that of each dependency it relies on, and reports readiness separately from liveness so a degraded dependency is visible rather than silent.
Automated jobs report success and failure
Scheduled operational jobs, including backups, report their outcome to external monitoring and raise an alert on failure — and equally if an expected run does not happen at all, which is the failure mode that otherwise goes unnoticed.
Production access is restricted and serialised
Access to the production environment is limited to authorised operators. Changes that alter production are serialised so two of them cannot be applied at the same time, and privileged administrative actions are recorded.
Environments are separated
Development, automated testing and production are separate environments with separate data. Testing and verification work runs against purpose-built data, never against production customer records.
Releases follow a controlled procedure
Production changes follow a documented release procedure: the exact reviewed revision is verified before it is deployed, data changes are applied ahead of the release under a controlled step, and the service is checked for health afterwards before the release is accepted.
Availability and resilience
Keeping the service available, and honest about the limits.
What is in place today to detect problems and recover from them, described without overstating the current stage.
Health is watched continuously
Service and dependency health, and capacity signals such as available storage, are monitored on an ongoing basis so degradation is detected rather than reported to us by a customer.
A tested path back to the last good release
Before a release is deployed, the currently running version is recorded as a rollback target. If a release misbehaves, returning to that known-good version is a single controlled operation, and the tooling that performs it is itself covered by automated tests.
Recovery procedures are documented
Restoring the service, restoring data, and rolling back a change are written down as procedures with defined steps rather than improvised during an incident.
Availability commitments are made in writing
Availability targets apply where they are agreed with you in writing, so you are never relying on a figure published on a marketing page. Resilience and failover capabilities are continuously reviewed and strengthened as the platform grows.
Backup and recovery
Backups you can actually restore from.
A backup nobody has ever restored is a hope, not a control. Restoration capability is tested rather than simply assumed.
Backups run daily and are encrypted
Customer data is protected through an automated daily backup process. Every backup is encrypted with authenticated encryption as it is created, so it is never stored or transferred in readable form.
Multiple protected copies
Backups are retained in more than one protected location, so the loss of any single copy does not mean the loss of your data. Files, uploaded documents and service configuration are covered as well as the database.
Integrity is verified, restoration is tested
Each backup is checked for integrity when it is written, and a recent backup is regularly restored into an isolated scratch environment and compared against production on a recurring cycle. Restoration capability is tested rather than simply assumed — and the failure cases, such as a corrupted or undecryptable backup, are confirmed to fail safely rather than silently.
Retention and secure deletion
Backups are retained for 30 days in the primary copy and up to 90 days in the secondary copy, and are then securely deleted. Retention and deletion controls apply to backup copies just as they do to live data.
Business continuity
What happens if the worst happens.
Recovery planning, verification, and a clear statement of what we do and do not commit to.
Recovery is planned, not improvised
Service continuity is covered by documented recovery planning: what is restored, in what order, and how the result is confirmed correct before the service is handed back to customers.
Verified periodically rather than filed away
Recovery procedures are exercised and the outcome recorded, so the plan reflects what actually works today rather than what worked when it was written.
Continuity commitments in writing
If your organisation needs agreed continuity or recovery commitments — for a procurement, tender or risk assessment — ask us and we will address them in writing for your circumstances, rather than have you rely on a figure published on a marketing page.
Auditing and accountability
A record of who did what.
Accountability matters most after the fact, which is why the record has to exist before you need it.
An audit log inside your workspace
Owners and admins can review a log of significant workspace activity, which matters the first time somebody needs to answer "who changed this?". Account, permission and configuration changes are traceable.
Administrative actions are recorded
Important administrative and security-sensitive actions are recorded to support accountability, investigation and operational review — including who acted, on what, and when.
Audit records resist tampering
The administrative audit trail is append-only by design: once written, entries cannot be altered or removed through ordinary application access, and the application's day-to-day access has no permission over it at all.
Support access is accountable
Where our support or operations team needs privileged access to help you, that access runs through the separate administrative boundary that requires multi-factor authentication and records what was done.
Security testing and incident response
How controls are checked, and what happens when something goes wrong.
How security-relevant behaviour is verified before it ships, and the processes that run when something goes wrong.
How controls are checked
We use a combination of automated testing, code review and configuration review as the platform evolves. That includes an automated suite covering security-relevant behaviour — workspace isolation, role enforcement and the separation of the administrative boundary — run against real dependencies on every change. Findings are assessed, prioritised and remediated through our engineering process.
Reporting a vulnerability
We publish a vulnerability disclosure policy with a security contact, a defined scope and a safe-harbour commitment for good-faith research, along with what you can expect after you report something. Please do not test against other customers' workspaces.
Responding to incidents
We maintain operational processes for detecting and investigating security and availability events, containing impact, restoring service and reviewing corrective actions afterwards. Where an incident affects your personal information, our Privacy Policy commits us to notifying you and the applicable regulators under the Notifiable Data Breaches scheme.
AI data boundaries
What AI can and cannot do with your data.
AI is the newest reason to distrust a CRM, so these boundaries are stated explicitly rather than buried.
Your data is not used to train models
Our Privacy Policy states plainly that we do not use customer data to train AI models, and names the AI sub-processor used to deliver the feature.
Nothing runs in the background
AI is triggered by a person clicking something. bizzMate does not run scheduled or batch AI jobs across your customer data.
AI never acts on its own
bizzMate AI produces drafts. It never sends a message, changes a deal, completes an activity or contacts anyone without a person reviewing and acting.
Extracted information is a suggestion
Where AI reads a document or a message, what it finds is presented for you to confirm rather than written silently into your records.
Transparency
Who else touches your data.
bizzMate uses a small number of sub-processors to deliver the service — for AI features, transactional email, network delivery, off-site backup storage and payments. Each one is named in our Privacy Policy, along with what it is used for and where it operates. Material changes to that list are communicated in advance.
Smart City Pty Ltd is an Australian company subject to the Privacy Act 1988 (Cth) and the Australian Privacy Principles. Where users are in the EU or UK, our Privacy Policy is intended to comply with the GDPR and UK GDPR as well. Where your organisation needs a statement of where a specific category of data is held, we provide it in writing — the sub-processor list in our Privacy Policy is the starting point.
Read the full Privacy Policy, including the sub-processor list
Reporting a security issue
There is no formal bug bounty programme today. If you believe you have found a vulnerability, email us with the details and we will respond. Good-faith research within our disclosure policy will not be met with legal action. Please do not test against other customers’ workspaces or attempt to access data that is not yours.
Privacy requests
Access, correction and complaint procedures are set out in the Privacy Policy, including how to escalate to the Office of the Australian Information Commissioner.
Security questions
The questions buyers ask us during a security review.
- Is bizzMate ISO 27001, SOC 2 or IRAP certified?
- No. bizzMate holds none of those certifications, and we will not imply otherwise. This page describes the controls that are actually in place so you can assess them on their merits. If a formal certification becomes part of our roadmap, it will be stated here once it is achieved — not before.
- Where is my data stored?
- bizzMate's application and database run on infrastructure we operate ourselves rather than on shared public-cloud hosting. Workspace records are isolated at the database layer, traffic is encrypted in transit, and backups are encrypted as they are created and replicated to protected off-site storage. Transactional email for Australian customers is sent from the Asia Pacific (Sydney) region. Our Privacy Policy names every sub-processor, what it is used for and where it operates. If you need a written statement of where a specific category of data is held — for a procurement, tender or compliance process — email us and we will provide one.
- Can another bizzMate customer see my data?
- No. Workspaces are isolated from one another in the data layer, so the separation is enforced by the platform rather than by application code remembering to filter. That isolation is covered by automated tests that run against real dependencies on every change.
- Who at bizzMate can see my customer data?
- Access is limited to what is needed to operate and support the service, through a separate administrative boundary that requires multi-factor authentication and records significant actions. Our Privacy Policy describes how we use information and who we share it with.
- Are my backups safe if something happens to your systems?
- Backups run daily, are encrypted as they are created, and are retained in more than one protected location. A recent backup is regularly restored into an isolated scratch environment and checked against production, so restoration capability is tested rather than assumed. If your organisation needs agreed recovery commitments, ask us and we will address them in writing.
- Is my data sent to an AI provider?
- Only when you use an AI feature, and only the relevant context for that request. Our Privacy Policy names the AI sub-processor, states that the data is not retained to train its models when accessed via the API, and confirms that we do not use customer data to train AI models.
- Do you have a bug bounty or a way to report a vulnerability?
- There is no formal bug bounty programme today. If you believe you have found a security issue, email support@bizzmatecrm.com with the details and we will respond. Please do not test against other customers' workspaces.
- What happens if there is a data breach?
- Our Privacy Policy commits us to notifying you and the applicable regulators of any breach affecting your personal information, in accordance with the Notifiable Data Breaches scheme under the Privacy Act and other applicable laws.
- Does bizzMate track me across the web?
- No. Our Privacy Policy states that we do not currently use advertising cookies, third-party tracking pixels or behavioural analytics tools. The cookies bizzMate sets are for authentication, security and remembering small interface preferences.
Judge it for yourself.
Start a free trial, put a handful of real records in, and see how the product behaves before you commit anything.
No credit card required.