Deelo Security: How We Protect Your Business Data

Davaughn White

If you run a small business on Deelo, you are trusting us with the keys to it. Your customer list. Your invoices and unpaid balances. Your contracts. Your support tickets. Your patient records, in some cases. A breach for a 200-person enterprise is a bad quarter. A breach for a 10-person business is existential.

We take that seriously, and we think the right way to take it seriously is to tell you exactly what we do, exactly what is in progress, and exactly what is not done yet. This page is the public version of the security walkthrough we do with customers on enterprise calls. It is not marketing copy. It names the controls, the technologies underneath them, and the gaps we are still closing in 2026.

If you would rather skip to specifics: authentication uses bcrypt-hashed passwords and TOTP-based 2FA, authorization is enforced at the database query level on every request with team-scoped multi-tenancy, data is encrypted in transit with TLS 1.2+ and at rest with AES-256, and healthcare apps that handle PHI use per-field encryption on top of that. Our SOC 2 audit is in progress and not yet complete. There is no bug bounty yet. Data residency is US-only at the time of writing.

Why security matters more for small businesses, not less

The conventional framing is that big enterprises need serious security and small businesses can lean on "we are too small to be a target." That framing is wrong, and has been for at least five years. Small businesses are the preferred target precisely because they are assumed not to be hardened. Phishing, credential stuffing, OAuth token theft, and supply-chain compromise through SaaS vendors are now industrialized — there is no manual targeting decision, you are scanned and probed automatically.

The second reason: a small business's SaaS vendor holds a larger share of the business's total operational state. A 5,000-person enterprise has its data spread across hundreds of systems. A 10-person business often has its CRM, helpdesk, billing, contracts, and team comms all running on three or four tools. If one of those tools gets breached, the blast radius is most of the company.

We write security with that in mind. The defenses we build are not aspirational "someday at IPO" controls — they are the floor for someone trusting Deelo with the operational core of their business today.

Layer 1: Authentication — proving you are you

Authentication is the first line of defense and the most common point of failure across the SaaS industry. Most breaches start here, not with sophisticated zero-day exploits. We harden the basics first.

Passwords are hashed with bcrypt. We never store plaintext passwords. Bcrypt is intentionally slow and salted per user, which makes offline cracking expensive even if a hash dump were ever stolen. We rotate the bcrypt work factor as compute gets cheaper.
Two-factor authentication via TOTP. Customers can enable 2FA in Settings → Security. We support standard authenticator apps (Google Authenticator, Authy, 1Password, Bitwarden). Backup codes are issued at setup and can be regenerated. We recommend every account enable 2FA, and we recommend admins require it for their teams.
Google OAuth as an SSO option. Customers who sign in with Google never have a Deelo password at all — the credential lives at Google, gated by whatever 2FA Google enforces. This is the most popular sign-in path for small teams already standardized on Google Workspace.
Rate-limited login attempts. Repeated failed sign-in attempts are throttled and locked. Automated credential-stuffing attacks against a Deelo account hit a wall quickly.
Suspicious-activity suspension. Accounts that exhibit anomalous sign-in patterns (impossible travel, rapid-fire failed attempts followed by a success, sudden bulk data access) are flagged and can be auto-suspended pending verification.
HttpOnly, Secure session cookies. Session tokens are sent over HTTPS only and are not readable by JavaScript, which prevents the most common XSS-based token theft.

One thing we want to be honest about: 2FA adoption across the customer base is not 100%. We strongly encourage it, we surface reminders, and team owners can require it via custom roles, but enforcement is a customer-side choice today. If you are reading this and have not turned on 2FA, that is the single highest-leverage thing you can do in the next ten minutes.

Layer 2: Authorization — what each person can actually see

Authentication proves who you are. Authorization decides what you can do once you are in. This is where multi-tenant SaaS gets dangerous if it is not architected carefully — the worst breaches we have seen in this industry are not break-ins, they are accidental cross-tenant data exposure where the wrong customer sees another customer's records.

We defend against this at the database query layer, not just at the application layer. Every authenticated request carries a team identifier, and our base repository pattern enforces that every query against a tenant-scoped collection includes that team filter. There is no way to write a controller that accidentally fetches another team's data — the query layer refuses.

Per-app permissions. Deelo has 50+ apps (CRM, helpdesk, billing, projects, healthcare apps, and more). Each app exposes granular permissions like view, edit, delete, and category-specific actions. A support agent can have helpdesk access without seeing billing. A bookkeeper can see invoices without seeing patient notes.
Scoped permissions for own-vs-all access. Some permissions have a `.own` variant — a field technician can have `view.own` on work orders (sees only their assigned work) without `view` (which would show every technician's queue). The data layer enforces the scope.
Role-based defaults. Four base roles — owner, admin, member, viewer — set sensible defaults for every app. Most teams never need to touch individual permissions; the defaults are calibrated for typical small-business roles.
Custom roles and per-user overrides. When defaults are not enough, you can define custom roles (e.g., "Billing-only contractor") or override permissions for individual users. Resolution order is documented: user overrides win, then custom role, then base role default.
Multi-tenant isolation at the query level. Every tenant-scoped database query automatically includes the team filter. Compliance-sensitive queries also carry an audit context that records who asked, when, and why.
Cross-tenant blast radius is zero by construction. Because team scope is enforced before any application logic runs, a bug in a controller cannot leak data across tenants — the query simply returns nothing for the wrong team.

Layer 3: Data protection — encryption in transit and at rest

Encryption is table stakes for any SaaS in 2026, but "we use encryption" without specifics is one of the more meaningless claims in the security marketing genre. Here is what we actually do.

TLS 1.2+ in transit. Every connection to Deelo — browser, mobile app, API — is over HTTPS using TLS 1.2 or higher. TLS 1.0 and 1.1 are disabled. Modern cipher suites only.
HSTS enforced. Browsers are instructed to refuse plaintext connections to Deelo for a long horizon, which prevents downgrade attacks.
AES-256 encryption at rest. Our primary database (MongoDB Atlas) encrypts all storage volumes at rest using AES-256, the industry-standard symmetric encryption. Backups inherit the same encryption.
Per-field encryption for sensitive collections. On top of full-volume encryption, the healthcare apps (Practice, Dentistry, Cardiology, Radiology, Ophthalmology, Pathology, DermAI, Disease Analysis) use a per-field encryption layer for PHI and PII — patient names, diagnoses, notes, identifiers. Even with database-level access, those fields are unreadable without the application-layer key.
No plaintext credentials in logs. Our logging pipeline strips passwords, API keys, OAuth tokens, and known sensitive fields before any log line is shipped to long-term storage. We review the redaction filter regularly.
Encrypted backups, multi-region. Daily encrypted backups with point-in-time recovery, replicated across multiple AWS regions. Backup restoration is exercised regularly.
Session cookies are HttpOnly + Secure + SameSite. Cookies that carry session state cannot be accessed by JavaScript, cannot travel over plaintext, and cannot be sent in unexpected cross-site contexts.

Layer 4: Operational security — the parts you do not see

Most security failures are not failures of cryptography. They are operational — a former employee whose access never got revoked, a vendor with too-broad access, an alert that nobody saw. Operational discipline is the difference between a well-designed system and a secure one.

Audit logs for compliance-sensitive actions. Sign-ins, permission changes, role assignments, data exports, deletions, and access to healthcare records are logged with actor, target, timestamp, and IP context. Logs are retained according to the applicable compliance horizon (HIPAA-relevant logs are retained longer).
Principle of least privilege for internal staff. Production access is restricted to a small, named set of engineers. Customer-data access requires a documented reason and is itself audit-logged. Most engineers have no direct access to customer data in normal operation.
Vendor security review for every subprocessor. We do not add a vendor that holds customer data without reviewing their security posture, public certifications, and contractual terms. We do not use vendors who train AI models on customer data — see the subprocessor section below.
Documented incident response. We have a written runbook for security incidents — detection, triage, containment, customer notification, post-incident review. We will publish the post-mortem summary for any material incident.
24-hour notification commitment. On a confirmed material security incident affecting customer data, we will notify affected customers within 24 hours of confirmation. This is a commitment, not a regulatory minimum.
Secure SDLC. Code review is required for every change. Dependencies are scanned for known vulnerabilities. Secrets are managed through a vault, never committed to source control.

Healthcare apps: HIPAA-grade handling

A subset of Deelo's apps handle protected health information. Practice, Dentistry, Cardiology, Radiology, Ophthalmology, Pathology, DermAI, and Disease Analysis are designed for clinical workflows where the data is regulated under HIPAA in the US (and analogous regimes elsewhere). For those apps, the defense layers are stricter.

Per-field encryption for PHI. Patient names, identifiers, diagnoses, clinical notes, and other sensitive fields are encrypted at the application layer before they reach the database, on top of the volume-level encryption already in place.
HIPAA middleware on every request. Requests to healthcare app endpoints pass through a HIPAA-aware middleware that enforces audit logging, minimum-necessary access patterns, and compliance-context propagation through the query layer.
Audit logging with the longer HIPAA retention horizon. Access to PHI is logged with actor, patient identifier (encrypted), reason, and timestamp. These logs are retained for the period required by HIPAA.
Performed-by and reviewed-by metadata on clinical records. Healthcare app records carry standard workflow metadata (who performed an action, who reviewed it, what the review status is) so audit trails are complete by design, not bolted on after the fact.
Business Associate Agreement (BAA) ready terms. Customers using the healthcare apps in a HIPAA-covered capacity can sign a BAA with us. Reach out to security@deelo.ai for the current template.

An honest note on scope: HIPAA assessment at Deelo is by-app, not company-wide. The healthcare apps are designed and operated to HIPAA standards. The other apps (CRM, marketing, projects, etc.) are not in scope for HIPAA — if you put PHI into a non-healthcare app, you are operating outside the design intent and outside what our BAA covers. We do not recommend it.

SOC 2: where we are honestly

We get this question on most enterprise sales calls, and we believe the honest answer earns more trust than a generic "we are SOC 2 compliant" claim that turns out to mean "we are working on it." Here is exactly where we are.

SOC 2 Type I audit is in progress. We are working with a qualified third-party auditor against the Trust Services Criteria (security, availability, confidentiality). Type I attests to control design at a point in time. We do not have a Type I report in hand yet.
SOC 2 Type II is planned to follow Type I. Type II attests that the controls operate effectively over a period (typically 6-12 months). Our roadmap is Type I first, then a Type II window.
Controls are aligned to the Common Criteria. Independent of the audit timeline, we have built our security program against the SOC 2 Common Criteria (CC1-CC9). The audit is the external attestation; the controls themselves are already in place.
We will not claim a certification we do not have. When we have a SOC 2 report, this page will say so and link to the report (available under NDA to prospects and customers). Until then, this page says "in progress."

What you can do as a customer

Security is a shared model. We harden the platform. You harden your team's use of it. The single highest-leverage things a customer can do, in rough order of impact:

Turn on 2FA. Today. Settings → Security → Enable two-factor authentication. Generate backup codes and store them somewhere safe. If you administer a team, consider requiring 2FA for everyone — it is the single biggest reduction in account-takeover risk available.
Set up SSO (Enterprise plan). SAML-based SSO lets you centralize authentication in your identity provider (Okta, Azure AD, Google Workspace, JumpCloud). Deprovisioning a departing employee in your IdP automatically cuts their Deelo access, which is the cleanest off-boarding model in SaaS.
Audit user permissions quarterly. Open Settings → Team and review who has access to what. Look for stale accounts, over-broad roles, and people who changed jobs but still hold their old permissions. Ten minutes a quarter prevents most insider-risk incidents.
Review your active sessions. Settings → Security → Active sessions shows every device currently signed in. Revoke anything you do not recognize. Revoke anything from a device you no longer own.
Use custom roles instead of giving everyone admin. The default "give them admin so it works" pattern is the single most common cause of accidental access in small businesses. Build a custom role that grants exactly what the role needs and assign it.
Export your data on a schedule. Deelo supports data export at any time, no friction, no support ticket required. A periodic export to a location you control is a good backstop against any catastrophic failure on either side.
Watch the security@deelo.ai inbox. If you ever need to report a vulnerability, suspected breach, or security concern, security@deelo.ai is monitored and acknowledged within one business day.

Subprocessors: the vendors we use

Every SaaS platform sits on top of other vendors. Pretending otherwise is dishonest. Here are the categories of subprocessor we rely on, what they do, and how we vet them. The exact named list is maintained on our public subprocessor page and is updated whenever it changes.

Primary database: MongoDB Atlas. Our production database. Encryption at rest, network isolation, and operational security inherited from Atlas's certifications (SOC 2, ISO 27001, HIPAA-eligible).
Payments: Stripe. All billing flows through Stripe. We do not store full card numbers — Stripe holds the cardholder data inside their PCI DSS Level 1 environment. We hold only the customer and subscription identifiers.
Hosting: AWS and DigitalOcean. Application servers, background workers, and supporting infrastructure run on AWS and DigitalOcean, both of which carry SOC 2 Type II and ISO 27001 certifications.
AI providers: Anthropic, OpenAI, Google. Some Deelo features call third-party AI models. Every AI provider we use has contractual terms that prohibit training on customer data. When a request goes to an AI provider, only the data needed for that specific request is sent; nothing is retained for model improvement on either side.
Email delivery. Transactional and notification email is delivered through a reputable email infrastructure provider with strong deliverability and security posture. Email addresses are minimum-necessary for delivery.
30-day advance notice for subprocessor changes. When we add, remove, or materially change a subprocessor, we notify customers at least 30 days in advance via the in-app announcement system and email.

Incident response: what we commit to

Every SaaS vendor will face an incident at some point. The differentiator is how they handle it. We commit to the following, in writing.

24-hour notification on confirmed material incidents. If a security incident is confirmed to have affected customer data, we will notify affected customers within 24 hours of confirmation — not 24 hours from discovery, but from confirmation that customer data was actually involved. (Earlier notice is often premature and confusing; we will not send "we may have a problem" alerts that turn out to be nothing.)
Status page transparency. Operational incidents (downtime, degraded performance) are published in real time on our status page. Security-relevant incidents go through the same channel with appropriate detail.
Public post-mortem for material incidents. After a material security incident is resolved, we publish a post-mortem summary covering what happened, what data was affected, what we did to contain it, and what we are changing to prevent recurrence.
security@deelo.ai for reporting. Customers, security researchers, and the general public can report issues to security@deelo.ai. Acknowledgement within one business day; severity-triaged response timelines after that.

The honest gaps

Every security page should have this section. We owe customers a clear list of what we have not done yet, so they can decide whether the gap is a dealbreaker for their use case.

SOC 2 certification is in progress, not complete. We do not have a Type I or Type II report in hand. We will publish one when the audit completes.
HIPAA scope is by-app, not company-wide. Healthcare apps are designed and operated to HIPAA standards under a BAA. Non-healthcare apps are not in HIPAA scope. Do not put PHI into a non-healthcare app.
No bug bounty program yet. A formal bounty program is planned but not yet live. In the meantime, we welcome responsible disclosure to security@deelo.ai and will acknowledge researchers who report valid issues.
Data residency is US-only. Customer data is stored in US AWS regions. Customers with EU data residency requirements should reach out — we are tracking demand and will publish a roadmap update when EU residency is on the schedule.
No formal penetration test report published yet. We have run security testing internally and with partners. A formal third-party penetration test with a publishable report is on the roadmap alongside SOC 2.
Bring-your-own-key (BYOK) encryption is not yet supported. Per-field encryption uses Deelo-managed keys. Customers with regulatory requirements for customer-managed keys should contact us — this is a tracked roadmap item.

Harden your Deelo workspace in ten minutes

Turn on 2FA, review your active sessions, and audit who has access to what. These three steps reduce the most common account-takeover risk by an order of magnitude. Settings → Security is where every one of those lives. For questions about security, BAA terms, SOC 2 timeline, or subprocessor details, email security@deelo.ai — we answer.

Start Free — No Credit Card

Frequently asked questions

Does Deelo encrypt customer data?: Yes, at multiple layers. All traffic to Deelo uses TLS 1.2 or higher in transit. Data at rest is encrypted using AES-256 via MongoDB Atlas's native encryption. Sensitive fields in healthcare apps (Practice, Dentistry, Cardiology, Radiology, Ophthalmology, Pathology, DermAI, Disease Analysis) get an additional per-field encryption layer on top of volume-level encryption, so PHI remains unreadable even with database-level access.
Is Deelo SOC 2 compliant?: A SOC 2 Type I audit is in progress with a qualified third-party auditor. We do not have a completed report yet, and we will not claim a certification we do not have. The underlying controls are already aligned to the SOC 2 Common Criteria; the audit is the external attestation. Type II will follow Type I. We will publish the report (available under NDA) when the audit completes.
Is Deelo HIPAA compliant?: Deelo's healthcare apps — Practice, Dentistry, Cardiology, Radiology, Ophthalmology, Pathology, DermAI, and Disease Analysis — are designed and operated to HIPAA standards, including per-field encryption of PHI, HIPAA-specific middleware, audit logging with HIPAA retention, and Business Associate Agreement (BAA) terms available on request. HIPAA scope is by-app, not company-wide. Non-healthcare apps (CRM, marketing, etc.) are not in HIPAA scope and should not be used to store PHI.
How does Deelo handle two-factor authentication?: Two-factor authentication is available to every account via Settings → Security. Deelo supports TOTP-based 2FA, which works with standard authenticator apps including Google Authenticator, Authy, 1Password, and Bitwarden. Backup codes are issued at setup and can be regenerated. Team owners can require 2FA for all members via custom roles. We strongly recommend every account turn it on.
What does Deelo do to prevent cross-tenant data leakage?: Multi-tenant isolation is enforced at the database query layer, not just at the application layer. Every authenticated request carries a team identifier, and our base repository pattern automatically scopes every tenant-relevant query to that team. There is no application-layer code path that can accidentally return another team's data — the query simply refuses to return cross-tenant records by construction.
Does Deelo's AI training use customer data?: No. Deelo uses third-party AI providers (Anthropic, OpenAI, Google) for some features. Every AI provider we use has contractual terms that prohibit training on customer data. When a request goes to an AI provider, only the data needed for that specific request is sent, and nothing is retained for model improvement. Deelo itself does not train models on customer data either.
How do I report a security vulnerability to Deelo?: Email security@deelo.ai. The inbox is monitored, and we will acknowledge within one business day. We do not yet have a formal bug bounty program (it is planned), but we welcome responsible disclosure and credit researchers who report valid issues. Please give us a reasonable window to investigate and fix before public disclosure.
What happens if Deelo has a security incident?: On a confirmed material incident affecting customer data, we commit to notifying affected customers within 24 hours of confirmation. Operational incidents (downtime, degraded performance) are published in real time on our status page. After resolution, we publish a post-mortem covering what happened, what data was affected, what we did to contain it, and what we are changing. Every confirmed incident gets a public post-mortem; we do not handle them quietly.
Where is Deelo customer data stored?: In US AWS regions, with encrypted backups replicated across multiple regions for disaster recovery. Data residency is US-only at the time of writing. Customers with EU or other regional data residency requirements should contact security@deelo.ai — we are tracking demand and will publish a roadmap update when additional regions are scheduled.
Who has access to my data inside Deelo the company?: A small, named set of engineers has production access. Customer-data access by staff requires a documented reason and is itself audit-logged. Most engineers have no direct access to customer data in normal operation. Internal access follows principle-of-least-privilege, and access reviews are run regularly to revoke anything no longer needed.

The thing we keep coming back to internally: small-business security is not a marketing problem, it is a craft problem. The right defenses are not exotic — bcrypt for passwords, TOTP for 2FA, TLS 1.2+ in transit, AES-256 at rest, query-level tenant isolation, audit logs, least-privilege staff access, honest disclosure of gaps. The hard part is doing all of them, consistently, without shortcuts, and telling customers the truth about where you are. That is what this page is. If you find something missing, email security@deelo.ai and we will fix it.

Related pages

Explore More

All software categories Compare alternatives Best software by industry