Confidential · Customer Review
Technical and organizational security controls mapped to SOC 2 Trust Services Criteria for vendor-risk review.
| |
|---|
| Version | 1.0 |
| Reviewed | 2026-07-15 |
| Owner | Chris Keenan |
This document represents a self-assessment of the current control environment, not an independent audit. Dash uses Vanta for continuous monitoring and is formalizing controls under SOC 2. We are happy to complete security questionnaires, share evidence under NDA, and provide audit reports when available.
At a Glance
| Area | Summary |
|---|
| Identity provider | Clerk — managed IdP, OIDC/JWT |
| Access model | RBAC with per-scope data grants, least-privilege defaults |
| Hosting | Amazon Web Services (US region) |
| Data in transit | TLS enforced, HTTPS redirection, secure strict cookies |
| Data stores | PostgreSQL (primary + replica), Redis (TLS), Amazon S3 |
| PII handling | Server-side field masking for lower-privilege callers |
| Audit trail | Actor-attributed, append-only log of sensitive changes |
| Change control | Peer + automated review, CI-enforced authorization tests |
TSC · Security
Access Control & Authorization
| ID | Control | Status |
|---|
| AC-01 | Deny-by-default policy — global fallback requiring an authenticated principal with an appropriate organizational role | Implemented |
| AC-02 | Three-tier principal model — platform admin, organization member, client tier — derived server-side | Implemented |
| AC-03 | Role-based access control with granular permission sets | Implemented |
| AC-04 | Scoped data grants constrained to organizations, clients, locations, or cities | Implemented |
| AC-05 | Global filter denying state-changing requests for read-only principals | Implemented |
| AC-06 | Per-user grant caps and last-administrator protection | Implemented |
| AC-07 | Support/admin impersonation validated per request; can only narrow scope | Implemented |
| AC-08 | Authorization regression tests fail the build on endpoint surface changes | Implemented |
Authentication
| ID | Control | Status |
|---|
| AU-01 | Managed identity provider — validates issuer, token lifetime, and cryptographic signature | Implemented |
| AU-02 | Multi-factor authentication available, configurable per organization | Available |
| AU-03 | API keys generated securely, stored as a one-way hash, support expiry and revocation | Implemented |
| AU-04 | Key usage tracking records last-used timestamp and source IP | Implemented |
Change Management & Secure SDLC
| ID | Control | Status |
|---|
| CM-01 | Peer + automated code review before merge | Implemented |
| CM-02 | Controlled deployments through CI/CD pipelines, with a dedicated migration pipeline | Implemented |
| CM-03 | Pre-commit quality gates for formatting, linting, and build checks | Implemented |
| CM-04 | Environment isolation — secrets injected at runtime | Implemented |
Monitoring & Logging
| ID | Control | Status |
|---|
| MO-01 | Centralized structured logging to Datadog | Implemented |
| MO-02 | Severity-mapped request logging for errors and alerts | Implemented |
| MO-03 | Interactive API documentation disabled in production | Implemented |
| MO-04 | Origin controls restricting cross-origin requests to an allowlist | Implemented |
TSC · Availability
| ID | Control | Status |
|---|
| AV-01 | Managed cloud infrastructure on AWS | Implemented |
| AV-02 | Read-replica architecture isolating analytics traffic | Implemented |
| AV-03 | Resilient integrations with retry, backoff, and circuit breakers | Implemented |
| AV-04 | TLS-secured Redis cache for frequently read data | Implemented |
TSC · Confidentiality
| ID | Control | Status |
|---|
| CF-01 | TLS enforced end to end; HTTP redirected to HTTPS | Implemented |
| CF-02 | Encryption at rest via AWS managed services | Infrastructure |
| CF-03 | Field-level PII masking server-side before client-tier return | Implemented |
| CF-04 | Scope enforcement filtering at the database query layer | Implemented |
| CF-05 | Secrets supplied through environment configuration | Implemented |
TSC · Processing Integrity
| ID | Control | Status |
|---|
| PI-01 | Append-only audit log of sensitive mutations | Implemented |
| PI-02 | Full actor attribution capturing role, IP, and user agent | Implemented |
| PI-03 | Defined action vocabulary kept consistent and queryable | Implemented |
| PI-04 | Validated, atomic grant changes through a single service path | Implemented |
TSC · Privacy
| ID | Control | Status |
|---|
| PR-01 | Data minimization with masked personal data by default | Implemented |
| PR-02 | Opt-out and communication-preference flags honored | Implemented |
| PR-03 | Tenant isolation preventing cross-tenant exposure | Implemented |
| PR-04 | Abuse protection on public intake with rate limiting and CAPTCHA | Configurable |
Shared Responsibility
Dash is responsible for: platform security, infrastructure, access controls, encryption, monitoring, and the controls described above.
Customers are responsible for: managing users and roles, protecting credentials, enforcing MFA, and appropriate data use.
Security contact: support@dashmarketing.io
This document is confidential and intended for vendor evaluation purposes. It reflects the environment as of the review date.
