Security Overview

1. Overview

DashAPI holds customer and revenue data from across an organisation, so security is a product requirement rather than an add-on. This page describes the measures we have in place today. It is written to be accurate rather than impressive; where a control is not yet in place, we say so in clause 12.

This page is referenced by our Data Processing Addendum as the description of our technical and organisational measures. We may improve those measures over time, provided the level of protection is not reduced.

2. Tenant isolation and access control

• Every record in the platform is scoped to an organisation. Queries are constrained to the tenant of the authenticated user, and access is enforced by server-side authorisation policies on each action, not by the interface.
• Within an organisation, access is further scoped by teams, workspaces and roles that administrators configure.
• Authentication uses passwords hashed with bcrypt; passwords are never stored or logged in plain text.
• API access uses scoped tokens that can be revoked individually. Tokens are shown once at creation and stored hashed.
• Connections to third-party services use OAuth with the narrowest scopes the feature needs, and can be disconnected at any time.
• Security-relevant events are recorded in an audit log for investigation.

3. Encryption

• All traffic between your browser or client and the platform is encrypted with TLS.
• Data at rest — databases, object storage and backups — is encrypted using industry-standard algorithms.
• Secrets and third-party credentials are held in encrypted configuration, not in source code, and are rotated when staff or vendor access changes.

4. Infrastructure and availability

• The platform runs on hardened, containerised infrastructure with a controlled deployment pipeline; production changes are made through that pipeline rather than by hand.
• Administrative access to production is restricted to a small number of engineers who need it.
• We monitor availability, error rates and performance, and alert on anomalies.
• Background processing is idempotent and retried, so a transient failure does not silently drop or duplicate work.

5. Backups and recovery

• Databases are backed up on a regular schedule, with backups encrypted at rest.
• Backups are retained on a rolling window and age out automatically; deleted customer data is removed from live systems first and disappears from backups as that window passes.
• Restore procedures are documented and exercised.
• Backups are our disaster recovery mechanism, not a per-customer undo. Keep your own export of data that matters to you.

6. Secure development

• Changes are peer reviewed before they reach production.
• Automated test suites run on every change, including authorisation tests.
• Static security analysis (Brakeman) and dependency vulnerability scanning (bundler-audit) run in continuous integration; builds that surface a known vulnerability are addressed before release.
• Dependencies are updated regularly, and security patches are prioritised over feature work.
• Test data is synthetic. We do not use real customer data in development or test environments.

7. People and internal access

• Access to production data is granted on a least-privilege, need-to-know basis and removed when no longer needed.
• Staff and contractors are bound by written confidentiality obligations.
• We access customer content only to operate the service, to investigate a fault or security issue, to comply with law, or when you ask us to — for example while handling a support request.
• Access to a customer workspace for support is logged.

8. AI and data handling

• AI processing is performed by the model providers listed on our Sub-processors page, under contracts that prohibit training on customer content.
• We send a model only the context required to answer a request.
• Agents operate within the tools and permissions you grant them, and inherit the same tenant scoping and authorisation checks as a user.
• We do not use customer content to train our own general-purpose models.

9. Incident response

We maintain an incident response process covering detection, triage, containment, eradication, recovery and post-incident review. If we determine that a security incident has affected your data, we will notify you without undue delay with what we know, what we are doing, and what we recommend you do, and will follow up with the outcome of our review.

Our regulatory notification commitments — including the GDPR 72-hour authority notification — are set out in clause 16 of the Privacy Policy and in theData Processing Addendum.

10. Vulnerability disclosure

We welcome reports from security researchers. Send findings tosupport@dashapi.ai with steps to reproduce, the impact you believe it has, and any supporting material.

What we ask of you:

• test only against accounts and data you own or have permission to use;
• do not access, modify, exfiltrate or retain another party's data — stop as soon as you have proof of access;
• no denial-of-service testing, spam, social engineering or physical attacks;
• give us reasonable time to fix an issue before disclosing it publicly.

What you can expect from us:

• acknowledgement within 5 business days;
• an assessment and a remediation plan, with updates as we work through it;
• credit for the finding if you would like it; and
• no legal action against researchers who follow this policy in good faith.

We do not currently operate a paid bug bounty programme.

11. Your side of the shared responsibility

• Use strong, unique passwords and do not share accounts.
• Grant the least privilege each member of your organisation needs, and remove access promptly when someone leaves.
• Scope, rotate and revoke API tokens; never commit them to a repository or paste them into a shared document.
• Review which third-party services and AI clients you have connected, and disconnect the ones you no longer use.
• Only put data into the platform that you have the right to hold — see the Acceptable Use Policy.
• Keep your own exports of data that is critical to you.
• Report anything suspicious to support@dashapi.ai immediately.

12. What we do not claim yet

We would rather be precise than aspirational. As at the date of this page:

• We do not hold a SOC 2, ISO 27001 or comparable third-party attestation. Formal certification is on our roadmap, and we will publish it here when it is complete rather than before.
• We have not published an independent penetration test report. Enterprise prospects may request our current security documentation under NDA.
• We do not offer a contractual uptime service level outside an enterprise agreement.
• Data residency options outside the United States are not generally available today; ask us if you have a specific requirement.

13. Contact

Security questions, documentation requests and vulnerability reports:support@dashapi.ai.