Security
Last Updated: August 21, 2026
This product holds pay plans, commissions, and named individuals' earnings. The people who evaluate it on behalf of a dealer group read a security page more carefully than they read a pricing page, so this one is written as a description of mechanisms rather than a list of adjectives. Where a control is partial, it says which part. Where we have nothing, it says so — Section 8 is the list of certifications we do not hold, and it is there because a page that only contains good news is not evidence of anything.
Self-attested — every seal links to its own proof
Certifications, attestations, standards, and regulations
Eight claims you can check in eight clicks
Nobody issued these. Each one is a statement about how this software is built, and each one is a link to the section of this site that describes the mechanism behind it — so a claim that stops being true has somewhere visible to fail.
Regulations we operate under
Standards and practices, self-attested
Certifications and attestations
The infrastructure is audited. The audits are theirs.
The five companies that hold the substance of your data — the database, the payments, the hosting, the model that reads your figures, and the error tracker — hold the certifications we do not. Those certificates belong to them, cover their platforms, and say nothing about our application. We name them because a vendor questionnaire asks and the answer should be findable, not to stand closer to them than the facts allow.
Stripe
PCI DSS Service Provider Level 1 · SOC 1 and SOC 2 Type II on request · a public SOC 3
Their audit, linked — verify it at the source.
Netlify
SOC 2 Type 2 · ISO 27001 · ISO 27018 · PCI DSS v4.0 · HIPAA
Their audit, linked — verify it at the source.
Anthropic
SOC 2 Type I and Type II · ISO 27001:2022 · ISO/IEC 42001:2023 for AI management · HIPAA-ready with a BAA
Their audit, linked — verify it at the source.
Sentry
SOC 2 Type I and Type II · ISO 27001 · HIPAA attestation
Their audit, linked — verify it at the source.
Read off each vendor’s own public compliance page on 21 August 2026; theirs is the authoritative version and it can change without us noticing. These five are not the whole list — every outside company that receives data is named in the sub-processor table on the compliance page, including the ones with no public certification list to quote.
1. Tenant isolation, described accurately
Isolation between dealerships is the control that matters most here, and it has two halves. Describing only the first is the mistake our own documentation used to make.
Row-level security. PostgreSQL row-level security is enabled on roughly 110 application tables, with policies that scope rows to the caller's dealership, group, or own record. This is the control on direct table reads and writes.
The function surface. Much of the product does not read tables directly — it calls database functions. About 185 of those functions are declared SECURITY DEFINER, which means they execute with the definer's rights and therefore bypass row-level security by construction. That is deliberate and necessary (a function that computes a group-wide roll-up cannot be constrained to one row), but it means that for this surface, row-level security is not the boundary. Each function's own internal authorisation check is, and the grant is: which of them an unauthenticated caller is permitted to execute at all.
The compensating control. An audit compares the live database's execute grants against a committed allowlist of 24 functions that anonymous callers are permitted to call. It fails if anything has been added to that set, and it fails if any SECURITY DEFINER function has an unpinned search path — a privilege-escalation vector we treat as zero-tolerance rather than as a finding with a baseline.
We built that audit because the drift it looks for had already happened 3 times. That is a less flattering sentence than "we maintain strict database permissions", and it is the reason the control exists and is worth trusting.
2. Transport and storage
- All traffic is TLS. HTTP Strict Transport Security is served with a max-age of 63,072,000 seconds — two years — with includeSubDomains and the preload directive.
- The production content security policy upgrades insecure requests and permits no non-HTTPS origin, so a plaintext connection cannot be made even by mistake.
- Data at rest is encrypted by our infrastructure providers, Supabase and Netlify. We do not add an application-layer encryption layer of our own, and we do not describe their disk encryption as though it were ours.
- Uploaded onboarding documents live in a private storage bucket restricted to the uploader’s own folder, and are served only through signed links that expire after five minutes.
One thing that is not encrypted by us
If your dealership enables the optional DMS sync, the credentials you provide are stored as structured data in our database, protected by row-level security and our provider's disk encryption — not by an application-level secret store. Moving them into a dedicated vault is planned and has not happened. We are naming it because a comment in our own codebase used to describe those credentials as encrypted at rest, and that comment was wrong; it has been corrected.
3. Application security
- A hash-based content security policy is generated at build time from the actual inline scripts, rather than falling back to unsafe-inline. Violations are reported back to an endpoint we monitor.
- The policy pins the database host to this build’s exact project rather than a wildcard, and permits no script source from it — so an attacker with their own project on the same provider cannot serve JavaScript into our pages.
- Rate limiting on sign-in, signup, and password reset runs on the server, in three independent buckets. The tight one is keyed on the account identifier AND the network address together — five sign-in attempts per fifteen minutes for that pair. Keying it on the identifier alone would have been a targeted-lockout weapon, because the identifier is caller-supplied and unauthenticated before sign-in: anyone could have posted five attempts naming your email and locked you out. A looser per-address bucket catches an attacker rotating identifiers, and a looser global per-identifier bucket still bounds a distributed attempt. The browser-side limiter that also exists is convenience, not a control, and we do not count it as one.
- Inbound webhooks are signature-verified before anything is processed — the payment webhook through the provider’s SDK, the SMS webhook through an HMAC comparison written to run in constant time. A request that fails verification is refused, and a missing signing secret refuses the request rather than skipping the check.
- The codebase is TypeScript in strict mode, and dependencies are audited for known vulnerabilities.
Error reports: two paths, scrubbed differently
Averaging these into one sentence would flatter the weaker of them, so they are described separately. Your browser sends error events straight to Sentry, not relayed through us, with your signed-in identity attached on purpose: your user id and email address, plus your role and dealership id as tags. An error nobody can attribute to an account is usually an error nobody can fix. Before sending, the browser drops known-harmless noise and redacts values whose keys mark them as credentials — tokens, passwords, secrets, authorization headers, cookies. It does not scan the text of an error message for an email address or telephone number that happens to be embedded in it.
A second copy goes to an endpoint of our own, and that path is scrubbed harder: bearer tokens, API keys, passwords, and any text matching an email address or a telephone number are stripped from the message, the stack, and the breadcrumbs, and only an opaque user id is forwarded — never your email or your name.
4. Staff access to your data, and what it records
Four ways a person who does not work for your dealership can see your dealership's data. Each is listed with what it records, including the two that record nothing.
| Mechanism | Who | Limit | What is recorded |
|---|---|---|---|
| Concierge setup | Our onboarding team, when you have purchased setup | The tenant you asked us to configure | Normal application activity, attributable to the staff account performing it |
| Impersonation | Named owner accounts only | 30 minutes, then it expires automatically | An audit row marked high severity: who started it, against whom, when, and when it ended. A banner is displayed throughout. |
| Presenter sessions | Our sales team, for live demonstrations | 4 hours, and only against accounts flagged as demo accounts in demo dealer groups — the database refuses any other target | An audit row, plus a record of every write made during the session so it can be undone |
| Staff view and platform reporting | Group administrators viewing a staff member; our master administrators viewing platform totals | Server-side authorisation checks the caller’s role and tenant on every request | No audit row is written today. We would rather tell you that than write “all privileged access is logged”. |
5. Testing
Roughly 1,350 unit tests across 69 files, and roughly 160 end-to-end cases across exactly 30 suites, run against the codebase. Two of those specifications exist specifically for the boundary this page is about:
- A tenant-isolation specification that signs in as a salesperson at one dealership and asserts that reads and writes against another dealership’s records return nothing and fail respectively. It talks to the database directly rather than through the interface, so a policy regression fails loudly instead of being hidden by the UI.
- A specification for the privileged database functions described in Section 1, asserting that they reject a request naming a dealership the caller does not belong to.
These two require credentials for a dedicated test project and are skipped when those are absent, so they are a gate we run rather than one that runs itself on every commit.
6. Data we deliberately do not hold
The most reliable protection for a piece of data is not to store it. The product holds a vehicle buyer's name, the vehicle, and the dealership's own profit on the deal — and it has no field for a Social Security number, a credit score, a date of birth, a driver's licence, an address, a complete telephone number, or the buyer's financing terms. Section 3 of the Privacy Policy is the full list, in both directions.
7. Reporting a vulnerability
Email security@thedasboard.com. Tell us what you found, how to reproduce it, and how you would like to be credited. We will acknowledge within three business days.
Safe harbour
If you make a good-faith effort to comply with this policy while researching, we will not pursue or support legal action against you, and we will work with you to understand and resolve the issue quickly. Good faith means: only touch accounts you own or have explicit permission to test; do not access, modify, or retain another dealership's or another person's data — if you encounter it, stop and tell us; no denial of service, no spam, no social engineering of our staff or customers; give us reasonable time to fix the issue before disclosing it publicly.
We do not operate a paid bug bounty. We do not want that to discourage you from telling us, and we will credit you publicly if you want us to.
Machine-readable version: /.well-known/security.txt
8. What we do not have
Every item below is something a buyer's checklist may ask for and something we cannot claim. We are an early-stage company and this is the honest position; it will change, and this page will change with it rather than in advance of it.
- SOC 2 Type I or Type II
- ISO/IEC 27001
- PCI DSS certification in our own right (card data is handled entirely by Stripe, which is PCI DSS Level 1)
- An independent third-party penetration test
- A funded bug bounty programme
- A statutory Data Protection Officer
- An EU representative under Article 27 GDPR
- A contractual uptime commitment or credit-backed service level agreement
On SOC 2 in particular: we will pursue it when our customer count warrants the cost, and not before. A vendor claiming to be "SOC 2 aligned" without a report is telling you they have read the criteria.
Our infrastructure providers do hold certifications, and those are theirs rather than ours to represent. Supabase, Netlify, and Stripe each publish their own compliance documentation; if your procurement process needs them, read them at the source rather than through our summary of them.