Crewnyx
Features Pricing Security About Support Sign in Start free trial
Legal / Security

Security you can inspect

A practical overview of how Crewnyx protects your data — encryption, tenant isolation enforced at the database layer, defense-in-depth, and how we handle the incidents nobody wants to have. No marketing dust. Concrete controls, concrete numbers.

Last updated July 15, 2026 · Sparky Venture Labs LLC · Florida, USA

On this page

  1. 1. Our stance
  2. 2. Encryption
  3. 3. Tenant isolation
  4. 4. Authentication
  5. 5. Payments
  6. 6. Infrastructure
  7. 7. Audit logs
  8. 8. Backups
  9. 9. Continuous testing
  10. 10. Incident response
  11. 11. Certifications
  12. 12. Report a vulnerability

1. Our stance

Security isn't a feature we bolted on. It's the reason a small AV shop can trust a small software vendor with sensitive payroll and payment data. Every architectural choice here — from database-enforced row isolation to the deployment gate that blocks a release if the cross-tenant test fails — was made with one question in mind: if a bug ships, could Customer A ever see Customer B's data? The answer, by design, is no.

We disclose enough for a technical buyer to make an informed decision. We do not publish our specific vendor list on the open web because that hands attackers a target map. The full subprocessor register (with vendors, regions, DPAs, and SOC 2 reports) is available to Customer administrators on written request under confidentiality — email legal@crewnyx.com.

2. Encryption

  • In transit: TLS 1.3 with modern cipher suites everywhere — the marketing site, the app, and all internal service-to-service traffic. HSTS is enabled with a two-year max-age and includeSubDomains, preloaded.
  • At rest: AES-256 encryption on the database and on all backup storage. Uploaded files (receipts, documents) are encrypted at the object-storage layer with per-tenant key derivation.
  • Passwords: bcrypt with per-user salt and a work factor tuned to keep verification above 200 ms on our current hardware. Plaintext passwords are never logged, never emailed, and never written to disk.
  • Secrets: API keys, service-account credentials, and signing keys live in a dedicated secret manager, never in source control. Access is scoped per environment and rotated on a schedule.

3. Tenant isolation

This is the single most important claim on this page, so we'll be specific.

Every row in every user-facing table carries a company_id column. Row-Level Security policies enforced by the database engine itself refuse any query that does not scope by company_id. The policy runs before the row is returned — not in the application code, where a bug could bypass it.

-- Simplified example
create policy tenant_read_own_time_entries
  on time_entries for select
  using (company_id = current_setting('app.current_company_id')::uuid);

The application sets app.current_company_id from the authenticated JWT on every request. If the JWT is missing, expired, or points to a company the user doesn't belong to, the setting isn't populated and every query returns zero rows.

The safety net An automated cross-tenant isolation test runs on every code deploy. It creates two synthetic companies, logs in as a user from Company A, and attempts to read every table's Company B data. If any table returns even one Company B row, the deploy is blocked. We ship no code without this test passing.

4. Authentication and access control

  • Email + password with mandatory email verification before first sign-in
  • Session tokens are short-lived JWTs; refresh tokens rotate on use and are revoked on logout
  • Role-based access control with three tiers: super-admin (owner, one per Customer), admin, and employee. All sensitive or mutating actions require admin or super-admin — never employee.
  • Rate limiting on the login and password-reset endpoints. Brute-force attempts trigger progressive delays and, above threshold, temporary lockout with alerting.
  • Session cookies are HttpOnly, Secure, SameSite=Lax, host-scoped. CSRF is enforced with per-request tokens on all mutating endpoints.

5. Payments

All card data is handled by our PCI-DSS Level 1 payment processor. When you enter card details in the app, the field is a tokenized element hosted directly by the processor — your card number goes from your browser to their vault without ever transiting our servers. We store only the returned opaque customer identifier, the subscription identifier, subscription status, and the last four digits and brand of the card on file for display.

We are therefore out of scope for PCI-DSS storage requirements. Our processor is annually audited to PCI-DSS Level 1.

6. Infrastructure

  • The application runs on managed cloud infrastructure with hardened, minimal-image compute — no long-lived SSH access, all changes shipped through the CI/CD pipeline.
  • Primary data is stored in a managed relational-database cluster with encryption at rest, point-in-time recovery, and daily encrypted backups. Backups are retained up to 12 months and destroyed on schedule.
  • All ingress passes through a DDoS-mitigated CDN edge with a Web Application Firewall. Standard OWASP rule sets are enabled by default, plus custom rules for our routes.
  • Application services enforce strict network egress controls. Only whitelisted destinations (the database, the payment processor's API, the email delivery API, the push-notification API) are reachable.
  • Deployments are Git-signed and immutable. Every deploy is traceable to the commit and the actor.

7. Audit logs

Every sensitive action is written to an append-only audit_log table with actor, action, before/after values, IP address, user agent, and timestamp. Super-admins can review the audit trail from Settings → Audit. Audit logs are retained one year and cannot be edited from the application UI.

8. Backups and recovery

  • Automated daily encrypted backups of primary data
  • Point-in-time recovery to any second within the last seven days
  • Quarterly restore drills validated against a target Recovery Point Objective of ≤ 15 minutes and Recovery Time Objective of ≤ 4 hours
  • Backups are stored in a region separate from the primary production region

9. Continuous security testing

  • Dependency scanning on every pull request. Known-vulnerable dependencies are blocked from merge.
  • Static analysis for common web-app vulnerability classes on every commit.
  • Secret scanning on every commit and on push. A leaked key blocks the merge.
  • Cross-tenant isolation test on every deploy (see Section 3). Deployment is blocked if any table leaks.
  • Manual security review of any change that touches authentication, authorization, or the row-level-security policies.

10. Incident response

If a security incident affects your data, we will notify your super-admin(s) by email within 72 hours of confirmation, in accordance with GDPR Article 33 and applicable US state breach-notification laws. The notification will describe what happened, what data was involved, what we're doing about it, and what — if anything — you need to do.

Our incident-response playbook is aligned with NIST SP 800-61r2. It covers preparation, detection, containment, eradication, recovery, and post-incident review.

11. Certifications and third-party audits

Crewnyx is not yet SOC 2 Type II certified as a company — we are a small, engineering-led studio and formal certification is on the roadmap for the next fiscal year. Our underlying infrastructure providers all hold SOC 2 Type II and ISO 27001 certifications. Their audit reports are available to enterprise Customers on written request under NDA.

We are willing to complete customer-supplied vendor security questionnaires (CAIQ, SIG-Lite, or custom) as part of an enterprise procurement process.

12. Report a vulnerability

If you believe you've found a security vulnerability, please email security@crewnyx.com — or legal@crewnyx.com if security is unreachable — with as much detail as you can share. We commit to:

  • Acknowledge your report within one business day
  • Keep you informed of triage and remediation
  • Never pursue legal action against good-faith researchers who follow responsible disclosure
  • Publicly credit you (if you want it) in our release notes when the fix ships

Please do not test against production data belonging to other Customers, do not perform denial-of-service or physical attacks, and do not exfiltrate more data than needed to demonstrate the bug.

Crewnyx

Field ops software built for AV, low-voltage, and service crews. Built by Sparky Venture Labs.

Product

  • Features
  • Pricing
  • Security
  • Start free trial

Company

  • About
  • Blog
  • Contact
  • Sparky Venture Labs

Support

  • Help center
  • support@crewnyx.com
  • Privacy
  • Terms
© 2026 Sparky Venture Labs LLC. All rights reserved.
Privacy · Terms · Security
QuickBooks and Intuit are trademarks of Intuit Inc. Xero is a trademark of Xero Limited. Gusto is a trademark of Gusto, Inc. Google Calendar is a trademark of Google LLC. Slack is a trademark of Slack Technologies, LLC. All other names and logos are the property of their respective owners and are used only to identify services Crewnyx can connect to. Crewnyx is not affiliated with, endorsed by, or sponsored by any of them.