Security

1. Our Approach

This page describes the security practices actually implemented across the Burdenoff platform today. We keep it accurate rather than aspirational: where a control is on our roadmap but not yet shipped, we say so explicitly rather than imply it exists.

2. Encryption

• All traffic to and within the Service is encrypted in transit via TLS.
• Databases and object storage are encrypted at rest using our cloud providers' managed encryption.
• Sensitive credential fields — including MFA (TOTP) secrets, API/HMAC signing keys, OAuth access and refresh tokens, and tenant OIDC client secrets — are field-level encrypted at rest with AES-256, in addition to storage-level encryption.

3. Access Control & Tenant Isolation

• Every workspace, organization, and tenant is isolated at the data layer; API access is scoped to the authenticated actor's own tenant.
• Every GraphQL query and mutation across our services carries an explicit role-based-access-control (RBAC) authorization check, enforced centrally at the API gateway from a versioned permission catalog — services never re-implement authorization on their own.
• Administrative and internal service-to-service calls are authenticated and scoped; there is no direct, unauthenticated machine-to-machine path into the platform.
• Production infrastructure access is restricted to authenticated operators through a managed bastion and Zero Trust access broker — there is no open SSH or direct public database access.

4. Audit Logging

Administrative and security-relevant actions are recorded in an activity/audit log. Audit records are retained for a mandatory 7-year window and cannot be deleted early through any admin-facing control, including by Burdenoff staff, once written — purge only occurs automatically once a record is more than 7 years old.

5. Vulnerability Management

• Every service image is scanned for known CVEs, infrastructure-as-code misconfiguration, and software-bill-of-materials issues in CI before it can deploy.
• Secret scanning runs against every commit to prevent committed credentials.
• We run a documented internal security review before every production deployment.

6. Data Retention & Deletion

See our Privacy Policy for retention periods by data category, and burdenoff.com/subprocessors for the current list of parties who process data on our behalf.

7. Certifications and Attestations

Burdenoff has not yet completed a third-party accredited security certification or attestation (for example, SOC 2 Type II, ISO/IEC 27001, or ISO/IEC 42001). Achieving these is on our compliance roadmap, and engaging an accredited auditor requires a dedicated engagement over weeks to months once scheduled. This page will be updated with the specific certification, scope, and issuing auditor only once an attestation has actually been completed and a report is available — we do not claim a certification is in place before that happens. If your organization requires a signed customer security questionnaire or a specific control attestation ahead of a certification, contact security@burdenoff.com.

8. Reporting a Vulnerability

If you believe you have found a security vulnerability in the Service, please report it responsibly to security@burdenoff.com. Include enough detail to reproduce the issue. Please do not access, modify, or delete data that is not your own, and give us a reasonable opportunity to investigate and remediate before any public disclosure. We do not currently operate a paid bug bounty program.

Last updated: July 27, 2026