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.
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.
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.
HttpOnly, Secure, SameSite=Lax, host-scoped. CSRF is enforced with per-request tokens on all mutating endpoints.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.
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.
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.
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.
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:
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.