An honest summary of the technical measures we currently use to protect customer data. BoardHasA is an early-stage product and our security program is still maturing — this page describes what is actually in place today, not an aspirational baseline.
BoardHasA is a small, actively-developed product. We do not yet hold SOC 2, ISO 27001, or any other third-party security certification, and we have not commissioned an external penetration test. What follows is a factual description of the controls we've built into the application and its infrastructure, along with where we know we still have work to do.
We run our own internal security reviews against the OWASP Top 10 and track findings to remediation. We'd rather tell you what's really there than describe a program we don't have.
The application runs on managed web hosting with a MySQL database. All traffic to the app is served over HTTPS. We do not currently operate a multi-region or multi-availability-zone deployment, and we do not have dedicated DDoS-mitigation infrastructure beyond what our hosting provider offers by default.
We know that hardening our deployment — including moving configuration secrets out of the web-servable directory and onto a proper secrets store — is an open item, and it's the top priority on our internal remediation list.
In transit: all traffic between your browser and our servers is encrypted with TLS.
At rest: uploaded files are protected with envelope encryption — each file gets its own AES-256-GCM data encryption key, which is itself wrapped by a master key. We do not currently offer customer-managed keys (BYOK) or cloud-provider KMS-based rotation.
Passwords are hashed using scrypt with a timing-safe comparison on login — passwords are never stored or logged in plain text.
Access inside the product is governed by role-based permissions (e.g. admin vs. regular member vs. observer), and board-level access checks gate most data access. We are in the process of tightening authorization checks across every API endpoint to make this consistently enforced — some lower-traffic endpoints are still being audited and hardened.
We do not currently offer multi-factor authentication, SSO, or SCIM provisioning. Sessions are currently long-lived; we're working on shortening session lifetimes and adding the ability to revoke a session (e.g. "sign out everywhere") independent of expiry.
Login attempts are rate-limited by IP and by account, and we keep an audit log of login activity (timestamp, IP, user agent) to support investigation if something looks wrong. We do not currently run a SIEM, endpoint detection and response (EDR) tooling, or a formal 24/7 on-call security rotation — monitoring today is manual and founder-operated.
We do not yet run automated dependency vulnerability scanning in our deploy pipeline; this is on our near-term roadmap.
We do not yet have a formally documented, drilled incident response plan. If we confirm a security incident affecting customer data, we will investigate, take corrective action, and notify affected customers without undue delay and consistent with applicable law. We're building out a more formal process as the team and customer base grow.
Database access goes through a query builder (Drizzle ORM) using parametrized queries, which protects against SQL injection. We run internal security reviews mapped to the OWASP Top 10 and track findings through to a fix. We do not currently require a second reviewer's sign-off on every production deploy, and we do not run automated static-analysis security scanning as part of CI today — both are on our roadmap.
BoardHasA is operated by a small team. Production access is limited to the people who need it to run the service, and we follow least-privilege practices when granting it. We do not currently run formal background checks or mandate company-managed hardware, as you'd expect from a larger organization with a dedicated security or IT function — we'll revisit this as the team grows.
Security researchers are welcome. If you believe you've found a vulnerability, please email info@boardhasa.name with reproduction steps. We read every report and will respond to acknowledge receipt as soon as we can — we're a small team, so response times may vary, but we take every report seriously.
We won't pursue legal action against good-faith researchers who report issues privately and give us a reasonable chance to fix them before any public disclosure.
For any questions about this page or our security practices:
Security
BoardHasA
info@boardhasa.name
Happy to talk through any of this directly, especially if you're evaluating us for your team.