Security

DailyBuilt, Inc., a Delaware corporation ("DailyBuilt", "we", "us") operates the dailybuilt platform at app.dailybuilt.co and the hosted pages our customers publish for their own customers. This page describes how we protect the data our customers entrust to us.

We have written it to be accurate rather than impressive. Where a control is in place, we say so and describe it. Where a control is planned but not yet in place, we say that too, in Section 15. We do not hold a SOC 2 report, an ISO 27001 certificate, a HITRUST certification, or an independent penetration test report, and nothing on this page should be read as claiming otherwise.

This page is informational. It is not a warranty, not a service commitment, and not an amendment to any agreement. If anything here conflicts with your Order Form, Business Associate Agreement, Data Processing Addendum, or the Terms of Service, those documents govern. We may update this page as the Service changes. Prior versions of this document are archived by date and are available on request to hello@dailybuilt.co.

---

1. Definitions and scope

Capitalized terms used and not defined here have the meanings given in the Terms of Service.

This page covers the production environment of the Service: the application at app.dailybuilt.co, the DailyBuilt API, the hosted End User surfaces (booking pages at {slug}.dailybuilt.co/book, document signing pages, and invoice payment pages), our transactional and marketing email and SMS delivery paths, and our internal operator console.

It does not cover: systems operated by our Customers or their vendors; websites, devices, or accounts our Customers connect to the Service; third-party platforms a Customer authorizes us to interact with on its behalf (for example advertising or business-profile accounts); or the security of a Customer's own users, devices, and credentials.

This page is a description of our practices only. It is not incorporated by reference into the Terms of Service, the Data Processing Addendum, any Business Associate Agreement, or any Order Form, and it creates no warranty, covenant, or specification. The contractual statement of our security obligations is Section 6.8 of the Terms of Service and Annex 2 to the Data Processing Addendum; for protected health information, it is the Business Associate Agreement.

2. Hosting and infrastructure

The Service runs on managed cloud infrastructure in the United States. We do not operate our own data centers, and we do not own or manage physical servers, racks, or network hardware. Physical and environmental security, hardware lifecycle, and data center operations are the responsibility of our infrastructure providers, who are contractually bound as our subprocessors.

Our primary application infrastructure is Google Cloud (Cloud Run for application compute, Cloud SQL for PostgreSQL for the primary database, Secret Manager for credentials, Artifact Registry for container images, and Cloud Logging for operational logs). Outbound email is sent through Amazon Web Services (Amazon SES). Our marketing website and certain edge services run on Cloudflare. The complete, current list of subprocessors — what each one does and what categories of data it can see — is published at /subprocessors.

Application containers are built from source in our continuous integration pipeline and deployed to managed serverless compute. Deployment credentials use short-lived, keyless federated identity rather than long-lived service account keys.

3. Encryption

In transit. All connections to the Service are served over HTTPS using TLS. Our application responses carry HTTP Strict Transport Security (Strict-Transport-Security: max-age=63072000; includeSubDomains; preload), so conforming browsers will refuse to connect over plaintext HTTP. Connections between our application and the primary database are encrypted in transit: the database instance is configured to accept encrypted connections only, and our data-access layer additionally requires TLS at the client. Connections to our subprocessors' APIs (payments, email, SMS, storage, advertising and analytics platforms) are made over TLS.

At rest. The primary database is Google Cloud SQL for PostgreSQL, which encrypts data at rest with AES-256 using provider-managed keys. Object storage for uploaded files and generated documents is encrypted at rest by the storage provider, which is covered by a business associate agreement for the data types that may include protected health information. Secrets and credentials are held in a managed secret store rather than in application configuration files, source code, or container images.

We do not currently use customer-managed encryption keys (CMEK) or bring-your-own-key. We do not currently offer field-level or application-layer encryption of database columns as a general feature; specific high-sensitivity fields, such as stored third-party OAuth credentials, are encrypted at the application layer in addition to the storage-layer encryption.

4. Tenant isolation

The Service is multi-tenant. Every Customer's data lives in a workspace, and every row of Customer Data carries the identifier of the workspace that owns it.

Every request is scoped server-side. The workspace context for a request is never taken on trust from the browser. For an authenticated session, the workspace identifier supplied by the client is validated against an active membership record for the authenticated user before any query runs; a request for a workspace the user does not belong to is rejected, not silently narrowed. For programmatic API access, the workspace is pinned to the API key itself and cannot be overridden by a request header. Identifiers of related records supplied by a client (a contact, a document, an invoice) are re-scoped to the resolved workspace before they are used, so a valid identifier from one workspace is not addressable from another.

We removed the shared-secret bypass. An earlier architecture included a shared internal credential that allowed a caller to assert a workspace and a role without a membership check, together with an operator "act as this user" impersonation path. Both were removed from the codebase in their entirety. There is no god-key and no cross-tenant impersonation path in the Service today.

Row-level security in the database. PostgreSQL row-level security is enabled and forced on the tables that hold Customer Data. In its current scope, these policies enforce the deletion model: a record marked deleted is invisible to every database role — including the table owner — unless a transaction explicitly opts in, which only a small set of audited surfaces (the operator trash and restore views, the archiver, and the purge path) ever does. Tenant separation itself is enforced in the application's data-access layer as described above, not by these row-level policies.

Verification. Tenant isolation has been the subject of repeated internal adversarial review, including white-box review of every tenant-facing read and write path. Those reviews have not found a tenant-reachable cross-tenant access path. That is a statement about what our reviews found, not a guarantee that none exists.

5. Authentication and access control

Customer users. Authentication for app.dailybuilt.co is provided by WorkOS AuthKit. Customers can sign in with email and password or with Google. Session tokens are validated on every request against the identity provider's published keys, with issuer and audience checks. Session cookies are HTTP-only, Secure, and time-bounded (currently a twelve-hour maximum age for the application session).

Roles. Access inside a workspace is governed by membership records with roles (owner, admin, member, viewer). Only an active member of a workspace can reach that workspace's data, and a suspended or removed member loses access immediately.

API keys. Programmatic keys are stored only as a salted, peppered hash, never in recoverable form. Comparison is timing-safe. A key is bound to exactly one workspace and can be revoked immediately, which takes effect on the next request.

DailyBuilt personnel. Access to production systems is limited to a small number of named DailyBuilt personnel. Our internal operator console requires sign-in through our identity provider and is additionally restricted to an explicit allowlist of operator email addresses, enforced before a session is issued — an authenticated Google account that is not on the allowlist cannot obtain a session. Every operator action in the console runs through a wrapper that records the acting operator's identity into the audit log; the codebase enforces this with a lint rule that rejects operator actions written without it. Cloud credentials are granted per-secret to the specific service that needs them rather than project-wide.

Multi-factor authentication. We do not currently enforce multi-factor authentication as a platform-level policy on DailyBuilt operator accounts, and we do not currently offer administrator-enforced MFA or SAML single sign-on as a Customer-configurable feature. Both are on our roadmap (Section 15). Customers who authenticate through Google can and should enforce MFA on that account through their own Google Workspace controls.

6. Application security

• Security headers. Application responses set a Content Security Policy, X-Content-Type-Options: nosniff, X-Frame-Options: DENY and frame-ancestors 'none', Referrer-Policy: strict-origin-when-cross-origin, a restrictive Permissions-Policy (camera, microphone, and geolocation disabled), and HSTS. The API sets equivalent hardening headers.
• Input handling. Requests are validated against a shared, typed API contract at the boundary. Database access uses parameterized queries throughout; we do not build SQL from string concatenation of user input.
• Abuse controls on public pages. Public booking and inquiry submissions are protected by Cloudflare Turnstile and by per-IP, per-email, and per-workspace rate limiting. Identifiers used as rate-limit keys are HMAC-hashed before they leave the application, so raw End User email addresses and phone numbers are not written to the rate-limit store.
• Webhooks. Inbound webhooks from our payment, messaging, and infrastructure providers are signature-verified and fail closed if verification fails.
• Tokens for unauthenticated flows. Links that let an End User cancel a booking, sign a document, or pay an invoice without an account carry high-entropy tokens that are stored hashed, are scoped to a single object, and are checked server-side on every use.
• Secrets. Application secrets are injected from a managed secret store at deploy time. The backend fails to start in production if a security-critical secret is missing, rather than starting in a degraded state.
• Logging hygiene. Our application logger redacts sensitive values, and the messaging and email paths are routed through it specifically so that recipient addresses, phone numbers, and provider payloads are not written to logs in the clear.

7. Payments and card data

Payments to our Customers run on Stripe Connect using direct charges on the Customer's own connected Stripe account. The Customer is the merchant of record for those payments.

DailyBuilt never receives, stores, or processes full payment card numbers. Card details are entered directly into Stripe-hosted payment components rendered in the End User's browser and are transmitted to Stripe, not to us. We store Stripe object identifiers and payment status, not card data. Our own subscription billing likewise runs through Stripe Checkout and the Stripe billing portal.

Because we do not touch cardholder data, DailyBuilt is not a card-data environment and does not undergo PCI DSS Level 1 assessment. Stripe's PCI compliance covers the card path.

8. Logging, audit, and monitoring

Application audit log. Changes to Customer Data are recorded automatically at the data-access layer rather than by individual feature code, so a new feature cannot ship without auditing. Every insert, update, and delete against an audited table — including inside transactions — writes an audit record capturing the actor (a Customer user, an API key, a DailyBuilt operator, or a system process), the action, the entity type and identifier, and the request context (request identifier, IP address, and user agent). Audit writes participate in the same transaction as the change, so a data change cannot commit without its audit record.

Append-only. The audit log is exempt from the soft-delete model and cannot be deleted through the application. Workspace closure and cascade operations do not remove audit history.

Access logging. In addition to change auditing, we record read and download events for the record types most likely to constitute a clinical or sensitive record: clinical notes, treatment plans, diagnoses, e-signature documents, and file and document downloads (including downloads performed by DailyBuilt operators).

Cloud audit logs. The production Google Cloud project is configured to capture administrative and data-access audit logs across services, exported to a dedicated archive-class storage bucket with a six-year retention policy.

Monitoring. We use error monitoring and log-based alerting on the production environment, including alerts on sensitive infrastructure changes. Our in-browser error monitoring is configured not to capture user information, cookies, or response bodies, and to drop events entirely while a Healthcare Edition workspace is active.

9. Data retention, deletion, and archival

Deletion in the Service is a lifecycle, not a single command:

1. Active. The record is live in the database.
2. Deleted. Deletion marks the record with a deletion timestamp. It disappears from every product surface immediately, and — as described in Section 4 — from every database query that has not explicitly opted in. It remains restorable during a recovery window.
3. Archived. Eligible records are exported to a cold archive bundle with a manifest, and the corresponding database rows and file objects are removed from the live systems.
4. Destroyed. Permanent destruction happens only through a single controlled path, only after the applicable retention period has run or on a Covered Entity's written election under the BAA, and always records a destruction certificate.

Retention is resolved from the record's class rather than from the record alone. Clinical records follow a floor of the later of seven years from the last entry in the chart or the patient's twentieth birthday. Financial records follow a seven-year floor. Audit records are retained six years. Suppression and opt-out records are retained for as long as the workspace exists, because a purged opt-out becomes a future violation. A Customer may configure a longer retention period; a Customer setting can never shorten a record below its legal floor.

We honor deletion requests to the extent the law allows. Where a legal retention obligation applies to a record, we retain it for the required period, restrict it, and delete it when the obligation ends, rather than deleting on request and creating a compliance failure for our Customer.

What is not built yet. The cold-archive exporter and the controlled destruction path described in steps 3 and 4 are specified and in progress; today, deletion means the record is marked deleted and hidden. We do not currently offer a self-serve, one-click export of an entire workspace. Return of Customer Data on termination is handled as described in the Agreement and, for protected health information, in the BAA.

10. Backups and resilience

The primary database runs on managed Cloud SQL with automated daily backups and point-in-time recovery enabled. Our current configuration retains seven automated backups and seven days of transaction logs, which allows recovery to any point within that window. Deletion protection is enabled on the database instance at both the infrastructure-as-code layer and the cloud provider layer.

Backups inherit the same encryption at rest as the primary database and are stored by the same provider in the United States.

We do not currently publish a formal recovery time objective or recovery point objective, and we do not currently publish a status page or uptime SLA. Availability commitments, if any, are made in the Order Form.

11. Subprocessors and supply chain

We use third-party subprocessors to deliver the Service. Our current subprocessor list — the vendor, what it does, the categories of data it can access, and whether it is covered by a business associate agreement for protected health information — is published at /subprocessors and is maintained from a single source of truth in our codebase, so the public page, the DPA, and the BAA exhibit cannot drift apart.

Where a subprocessor may create, receive, maintain, or transmit protected health information on our behalf, we obtain a business associate agreement with that subprocessor before that flow is enabled. Subprocessors that are not covered by such an agreement are not approved channels for protected health information, and the product is gated accordingly for Healthcare Edition workspaces.

Change notice for subprocessors is governed by the Data Processing Addendum.

12. HIPAA and the Healthcare Edition

DailyBuilt is a Business Associate, not a Covered Entity. Where a Customer is a Covered Entity (or a Business Associate of one) and enables the Healthcare Edition on its workspace, our Platform Business Associate Agreement self-executes at enablement, and a Healthcare Edition workspace cannot accept public patient intake through its booking page until the Customer's owner has accepted it in the Service. The accepted version and content hash are recorded.

Under the Healthcare Edition:

• Protected health information is confined to infrastructure covered by a business associate agreement. Services and vendors that are not so covered are not approved channels for it.
• Product analytics on public pages are disabled for Healthcare Edition workspaces by default. Where analytics are enabled for such a workspace at all, only a privacy-hardened profile is available — Do Not Track honored, query strings and URL fragments excluded, and page paths coarsened before anything leaves the browser. Session replay and heatmap capture are never loaded on those pages.
• No third-party advertising, conversion, or analytics tag is served on any hosted surface of a Healthcare Edition workspace — no advertising pixel, no conversion tag, and no third-party analytics script on its booking, signing, or payment pages. Tenant-supplied tag injection is not supported on those surfaces. The first-party analytics described above run without transmission to any third party. Advertising and business-profile connections are for the Customer's own marketing properties and ad accounts, never for the patient-facing pages we host.
• In-browser error monitoring drops events while a Healthcare Edition workspace is active, and never captures user information, cookies, or response bodies.
• Read and download access to clinical records is logged as described in Section 8, in addition to change auditing.
• Retention follows the clinical floors described in Section 9, and a Healthcare Edition workspace cannot be casually deleted.

There is no such thing as a government-issued "HIPAA certification." Any vendor that claims one is describing something else. What exists is a signed BAA plus a set of implemented safeguards, and we describe ours here and in the BAA rather than pointing at a certificate.

Our HIPAA compliance program artifacts — the written risk analysis and risk-management plan, the incident response plan, workforce training, and the sanction and access-authorization procedures — are in development (Section 15). We will not represent them as complete before they are.

13. Reporting a vulnerability

We welcome reports from security researchers and from our Customers' own security teams.

• Email: hello@dailybuilt.co, with "Security" in the subject line.
• Machine-readable policy: https://dailybuilt.co/.well-known/security.txt (RFC 9116).

Please include enough detail to reproduce the issue: the affected URL or endpoint, the steps, and what you observed. We will acknowledge a report within five business days and will keep you updated while we investigate. We do not currently operate a paid bug bounty program.

Safe harbor. If you make a good-faith effort to comply with this policy while researching a vulnerability, we will consider your research authorized, we will not pursue or support civil or criminal action against you for it, and we will say so if a third party brings action against you for research conducted under this policy. Specifically:

• We will not bring or support a civil claim against you, and will not report or refer you for prosecution, under the Computer Fraud and Abuse Act, 18 U.S.C. § 1030, or under any state computer-crime or unauthorized-access law, for research conducted within this policy.
• We authorize that research as security testing for the purposes of 17 U.S.C. § 1201(j), and we will not assert a claim under 17 U.S.C. § 1201 against it.
• We will not enforce against you the provisions of our Terms of Service and Acceptable Use Policy that prohibit probing, scanning, penetration testing, or reverse engineering of the Service, to the extent your research complies with this policy.

Good faith means: you stay within the systems listed in Section 1; you do not access, modify, delete, or exfiltrate data belonging to anyone other than yourself (if you encounter Customer Data or personal information, stop, do not save it, and tell us); you do not degrade the Service (no denial-of-service, no automated load testing, no spam or social engineering of our staff, Customers, or End Users); you do not use the finding for any purpose other than reporting it to us; and you give us a reasonable opportunity to remediate before disclosing publicly. This safe harbor does not authorize testing against our Customers' own systems or the systems of our subprocessors.

Out of scope. Reports that consist only of automated scanner output without a demonstrated impact, missing security headers with no exploit path, best-practice recommendations without a vulnerability, social engineering, physical attacks, and issues in third-party products we do not control.

14. Incident response

We maintain internal procedures for detecting, escalating, investigating, containing, and remediating security incidents. In an incident affecting Customer Data:

• Notice to Customers. We will notify affected Customers without undue delay and in any event within five (5) business days after Discovery, as defined in the Data Processing Addendum §9, using the contact information associated with the workspace, and will provide the information we then have about what happened, what data was involved, and what we are doing about it. We will supplement as the investigation develops.
• Notice to Covered Entities. For a Breach of Unsecured Protected Health Information, we will report to the affected Covered Entity within five (5) business days after Discovery, as those terms are defined in the BAA. The initial report is preliminary and we have a continuing duty to supplement it. Where the relevant facts sit with a subprocessor and we are awaiting that subprocessor's disclosure, the reporting clock is tolled as provided in the BAA. This commitment sits well inside HIPAA's outer sixty-day bound at 45 CFR 164.410 and inside the Florida notification window at Fla. Stat. § 501.171(6).
• Roles. As a Business Associate, we report to the Covered Entity. Notification of individuals, the Secretary of Health and Human Services, the media, and state regulators is the Covered Entity's determination and duty, and we will provide the information reasonably needed to make and discharge it.
• Not an admission. A notice or report under this section is not, and will not be construed as, an acknowledgment of fault or liability by DailyBuilt.

A formal, written incident response plan with named roles and tested runbooks is in development (Section 15).

15. What we do not have yet

We would rather you learn this here than in a questionnaire.

• No SOC 2 report, no ISO 27001 certificate, no HITRUST certification. A SOC 2 Type II engagement is our intended first formal attestation. We have no audit period underway today and we will not name a date we cannot hold.
• No independent third-party penetration test report. We conduct structured internal adversarial security reviews — white-box review of tenant isolation, authorization, injection surfaces, the operator console, and data exposure — and we remediate what they find. An external test is on the roadmap ahead of certification.
• No enforced MFA or SAML single sign-on as a Customer-configurable policy, and no platform-level MFA enforcement on operator accounts (Section 5).
• No self-serve data export of an entire workspace, and no accounting-of-disclosures report in the product (Section 9).
• No customer-managed encryption keys (Section 3).
• No published status page, uptime SLA, or recovery objectives (Section 10).
• No automated dependency vulnerability scanning in CI today; dependencies are reviewed and updated manually, and automated scanning with a remediation SLA is on the roadmap.
• HIPAA program artifacts in development (Section 12).

If a formal control is a gating requirement for your organization, tell us before you buy rather than after. We will tell you honestly whether we can meet it and when.

16. Shared responsibility

Security of the Service is a joint effort. We are responsible for the platform. You are responsible for how you use it, including:

• Managing your workspace's users, roles, and offboarding, and revoking API keys you no longer use.
• Protecting your own account credentials and devices, and enabling MFA on the identity you use to sign in.
• Deciding what data you put into the Service, including whether you enable the Healthcare Edition before collecting protected health information.
• Configuring the features that touch third parties — calendar synchronization, advertising and business-profile connections, session replay on your public pages, marketing email and SMS — in line with your own legal obligations and the consents you have captured.
• Content you or your users publish on the pages we host for you, and the documents you send for signature.

Your obligations are set out in the Terms of Service and the Acceptable Use Policy.

17. Requests, questionnaires, and contact

We are happy to complete a reasonable security review. Email hello@dailybuilt.co and ask for our security overview; we can provide our architecture summary, subprocessor list, data flow description, and answers to a standard questionnaire under a mutual NDA.

For law enforcement and legal process, see /legal-process. For privacy questions, see /privacy. For consumer-facing surfaces, see /consumer-privacy-notice.

DailyBuilt, Inc. c/o Corporation Service Company, 251 Little Falls Drive, Wilmington, DE 19808 hello@dailybuilt.co