Who we are, in one paragraph
HalyardCo (legal entity: OBB Holdings LLC, a Wisconsin LLC) designs, builds, and operates web applications and data tooling for nonprofit organizations: dashboards, CRMs, intake pipelines, and reporting surfaces, hosted on Cloudflare's developer platform. We are a small senior team; the same people who design the architecture operate it. This page describes the controls that are actually in place, verified on the date shown. It is not an aspiration document.
Identity & access control
- Every application surface sits behind Cloudflare Access (Zero Trust): client-org email allowlist, one-time-passcode second factor, bounded sessions. Unauthenticated requests never reach application code; they are redirected at Cloudflare's edge. verified 2026-08-18
- The API layer enforces identity structurally. A root middleware requires a Cloudflare Access identity on every
/api/*route, so no individual endpoint can ever ship without the check; endpoints additionally re-verify identity per-file (defense in depth). Where a signed Access JWT is present it is cryptographically verified against the Access organization's published signing keys. verified 2026-08-18 - Identity cannot be supplied by the client. Cloudflare's edge strips inbound identity headers and injects its own on authenticated requests. Application writes record the authenticated user from that edge-injected identity; user-supplied identity fields in request bodies are ignored by design. verified 2026-08-18
- Immutable per-deploy preview URLs are covered by the same wall. A wildcard Access application gates deploy-hash hostnames, so old build URLs cannot bypass authentication. probe-verified 2026-08-18: all probes 302 to Access sign-in
Data isolation & classification
- One client, one project, one database. Each client's application runs as its own Cloudflare Pages project bound to its own D1 (SQLite) database. There is no shared multi-tenant database and no cross-client data path. verified 2026-08-18
- We hold the minimum class of data the tool needs: organizational records, staff rosters, program and giving aggregates. We do not accept or store SSNs, payment-card numbers, bank/routing numbers, or health data in the systems we operate.
- Personal-data discipline extends to our own operations: individual donor and student data stays out of chat systems, prompts, and operational logs. That is a standing internal rule, not an afterthought.
Transport, caching & logging
- All traffic is TLS end-to-end at Cloudflare's edge; there are no non-HTTPS surfaces.
- Financially or personally sensitive API responses are served
Cache-Control: private, no-store, so nothing sensitive parks in shared caches. verified 2026-08-18 - Application logs carry operational metadata and identifiers, not payload contents; platform-level request logging is governed by Cloudflare's Data Processing Addendum.
Secrets & credentials
- Runtime secrets live in the platform secret store (Cloudflare Pages secrets), never in source trees or configuration files; API tokens are scoped to the specific account and capability they serve. A sweep of the deployed source tree for embedded credential values returns none. swept 2026-08-18
- Credential exposure has a standing playbook: any credential that transits an insecure channel is rotated, not merely deleted.
Change control & verification culture
This is the control we would most want a reviewer to test us on. Every production deploy is wrapped in verification: routes are snapshotted before the deploy and diffed after (cache-busted and content-level; a status code is not accepted as proof), staged changes pass syntax gates and a line-by-line deletion review before adoption, and completion claims must cite the evidence they rest on; our own tooling hard-blocks an unevidenced "verified" claim. Data loads are reconciled to the cent against their source documents before an endpoint serves them.
- Schema changes ship as numbered, reviewed migrations; destructive operations require explicit, separate authorization.
- Server-side authorization decisions (admin scopes, role views) are enforced in the API, never only in the browser. verified 2026-08-18
Availability, backups & retention
- Scheduled uptime checks watch the production surfaces; scheduled backup jobs run nightly, with cold archives encrypted at rest. job inventory verified 2026-08-18
- On contract end or on request, client data is returned or destroyed with certification, consistent with the return-or-destroy terms in our confidentiality agreements.
Incident posture
Prompt notification of any unauthorized access or disclosure involving a client's information is a contractual commitment we accept in our agreements (including NPPI-specific security and breach-notice obligations), and our monitoring is built so that failures surface to us first. We will state plainly what we know, when we knew it, and what we did: the same honesty this page practices.
What we deliberately do not claim
We hold no SOC 2 attestation and no ISO 27001 certificate, and we will not imply otherwise. Our controls are architectural (the platform enforces them), procedural (the verification culture above), and contractual (confidentiality and breach-notice obligations we sign). For an organization our size we believe that is the honest configuration, and everything on this page is independently checkable: the Access wall, the headers, the isolation model are all observable from the outside or demonstrable in a walkthrough, and we are glad to do one live.
How the integration is provisioned
We run integrations the way that keeps the data owner in maximum control. The arrangement that gives you the most control is also the one that puts your existing security program in front of our access, which is where it belongs.
- The integration runs as a named service identity under your tenant, governed by your identity provider. Not a personal login and never a shared password. Your MFA and conditional-access policies apply to our access automatically, our activity appears in your audit logs as a first-class principal, and revocation is a single action on your side that requires nothing from us. Materially, this moves credential security from "HalyardCo promises" to "your controls enforce."
- Grants are least-privilege and scoped. Read-only wherever read-only suffices; scopes narrowed to the specific objects and reports the integration needs; separate credentials per system and per environment (sandbox versus production) so any single credential has a small blast radius.
- Builds are sandbox-first. We build and verify against a sandbox or staging tenant; production data is touched only by a verified build. Our own build process (the verification culture above) applies at each step.
- Data moves by event or delta feeds where the platform offers them. Webhooks and modified-since queries move less data, touch fewer records, and leave a cleaner audit trail; bulk extraction is an initialization step, not a habit.
- Our egress is deterministic. IP allowlisting and any additional guardrails you operate compose cleanly with it; pinning is available the day you want it.
Consumption discipline: rate limits and pull patterns
- Scheduled, incremental syncs at agreed windows rather than continuous polling; modified-since deltas rather than full-table sweeps once an initial load is complete.
- Client-side rate caps set below the platform's published limits, with exponential backoff and a circuit breaker on repeated errors, so a failure on either side degrades to silence rather than a retry storm.
- Every pull is logged (scope, window, record counts) on our side, and we assume yours logs it too; the two records should agree.
- Volume and scope changes are proposed before they happen, not observed after. If a new feature needs a new object or a bigger window, that is a conversation, not a surprise in your API metrics.
Insurance
| Line | Limit | Status |
|---|---|---|
| Professional Liability / E&O (claims-made) | $1,000,000 per claim / $1,000,000 aggregate | In force · 07/21/2026 – 07/21/2027 |
| Cyber / Security & Privacy Liability | $1,000,000 (sub-limit within the policy total) | In force · effective 08/01/2026 |
Carrier: biBERK / National Liability & Fire Insurance Co. (a Berkshire Hathaway company), policy N8PL697054; insured OBB Holdings LLC with Halyard Co. as additional named insured. Certificate of Insurance available on request. verified against policy documents 2026-08-03
Subprocessors
For hosted client applications the platform dependency is Cloudflare (Pages, Workers, D1, KV, Access). Where a specific engagement adds a service that handles client data (for example, transactional email or document storage in the client's own tenant), it is disclosed for that engagement; nothing is added silently. The application stack described on this page runs on Cloudflare alone. verified 2026-08-18