Security & Trust Center

SparrowHawk CRM is built on the principle that security is a discipline, not a checklist. We assume that every request could be malicious, every dependency could contain a vulnerability, and every user could be having a bad day. Controls are layered so that the failure of any single control does not become the failure of the platform.

The controls below reflect what SparrowHawk CRM LLC actually operates today. Where certifications, external audits, or attestations are still on the roadmap, they are clearly labeled as such. We would rather understate our posture than misrepresent it.

Traffic to the platform is protected with TLS on modern cipher suites. Customer Data at rest — including database rows, object storage, and backups — is encrypted using industry-standard algorithms managed by the underlying cloud providers described in the Subprocessor List. Integration secrets and OAuth refresh tokens are additionally encrypted at the application layer before being written to the database.

Each Customer organization has its own tenant boundary enforced at the database layer. Row-level security policies attached to every table gate every read and write on the caller's identity and organization membership. A misconfigured client cannot reach data belonging to another organization because the database rejects the query, not because a UI check is careful.

User accounts are authenticated by email plus password or federated identity providers such as Google. Passwords are stored using strong one-way hashing and are never returned to the browser or the server code base. Sessions issued to the browser are short-lived, scoped, and can be revoked. Administrators can force sign-out and reset flows can invalidate all outstanding sessions for the affected account.

Multi-factor authentication is supported where available and is recommended for every user with administrative privileges.

Access decisions are driven by a defined role hierarchy — super admin, organization admin, organization user, FBO admin, FBO user — plus feature entitlements per plan. Roles are stored in a dedicated table, checked through a security-definer helper, and enforced by row-level security policies. Application code checks roles too, but the database is the enforcement boundary.

Sensitive administrative and financial actions — role changes, invoice adjustments, payment refunds, integration credential changes, permission changes, super-admin actions — are recorded in append-only audit logs with actor identity, target, timestamp, and originating IP. Audit logs are used for investigation, dispute resolution, and internal review.

The managed database supports automated backups and point-in-time recovery. Object storage is versioned. Backup retention windows are aligned with the Data Retention & Deletion Policy. Restoration is available in the event of accidental deletion, corruption, or a serious infrastructure incident, with the caveat that no restoration program can guarantee recovery of every specific record.

Our engineering practices include:

• code review and automated static and dependency analysis before merge
• separation of preview and published environments
• server-side input validation on every server function and public API route
• least-privilege access for production database and infrastructure roles
• secret scanning to keep credentials out of source control
• rapid rollback of any deployment that misbehaves in production

SparrowHawk CRM depends on a small number of vetted subprocessors described on the Subprocessor List page. Subprocessors are chosen based on security posture, published compliance attestations, and operational reliability, and are bound by contractual data-protection obligations consistent with the Data Processing Addendum.

The Incident Response Policy describes how SparrowHawk CRM LLC prepares for, detects, contains, investigates, and communicates security incidents. Where an incident is legally reportable, we will notify affected Customers within the timeframe required by applicable law.

Security researchers can report suspected vulnerabilities through the Vulnerability Disclosure Policy. We appreciate good-faith reporting and will work with researchers who follow the rules of engagement described there.

Even the strongest platform can be undone by weak account hygiene. Customers are asked to:

• enable multi-factor authentication for every administrator
• require strong, unique passwords and rotate on suspected compromise
• review user roles and permissions on a regular schedule
• remove access for departed personnel promptly
• protect devices used to access the platform
• keep integration secrets confidential and rotate on suspected compromise
• notify SparrowHawk CRM LLC as soon as suspicious activity is observed

• SOC 2 Type II — targeted for a future audit cycle once the platform reaches program readiness.
• ISO / IEC 27001 — under evaluation for the mid-term compliance roadmap.
• Additional regional privacy attestations and third-party penetration testing as customer demand and program maturity warrant.

Report suspected security issues to security@sparrowhawkcrm.com (or support@sparrowhawkcrm.com if the security address is not yet monitored). For urgent, actively exploited vulnerabilities, mark the subject line with URGENT SECURITY.