Security at Privify
We sell security software, so we'll be direct about our own posture — including what we haven't done yet. If you're evaluating FORGE, this page should tell you what you need before your security review does.
Compliance status
Privify is an early-stage company. We publish our compliance status plainly rather than implying more than we have.
| Item | Status |
|---|---|
| Security practices aligned to SOC 2 Trust Services Criteria | In place |
| Independent SOC 2 Type I / Type II audit | Not started |
| CPA-issued SOC 2 report available | Not available |
| ISO 27001 certification | Not started |
| Penetration test by third party | Planned |
You'll see a badge on our homepage reading "Security Practices Aligned with SOC 2." That wording is deliberate. It means we have mapped our internal controls to the Trust Services Criteria and operate against them.
It does not mean we are SOC 2 certified, attested or audited. No independent auditor has examined our controls, and no CPA-issued report exists. If a vendor questionnaire asks whether we hold a SOC 2 report, the answer today is no.
How FORGE is architected
The most significant security property of FORGE is where it runs. It is designed for deployment inside your own environment, which changes the shape of the trust question.
- Self-hosted deployment. FORGE runs on infrastructure you control. The management plane, database and event store are yours.
- Probes are local. Discovery probes execute on the endpoint and report to your management plane — not to Privify.
- No customer telemetry to Privify. In a self-hosted deployment, agent activity, traces and DLP findings stay inside your network.
- API-first. Every capability in the platform is reachable through the API, so FORGE fits your existing controls rather than replacing them.
- Audit trail by default. Governance actions, policy decisions and approvals are recorded and exportable to your SIEM.
Kernel components
FORGE blocks inline on Windows, macOS and Linux. On Windows it can additionally enforce through a WFP callout driver operating in the network stack, which evaluates policy at the TCP connect boundary and therefore applies regardless of how an agent routes its traffic. Because this is a kernel-mode component, we treat it with corresponding care: it fails open into a pass-through mode rather than risking system instability, and it is a documented part of any deployment review. Deployment guidance and driver signing status are covered during technical evaluation.
Reporting a vulnerability
If you believe you've found a security issue in our software or on this website, please tell us before disclosing it publicly. Email security@privify.io with enough detail to reproduce the issue.
- We aim to acknowledge reports within 3 business days.
- We will keep you updated on remediation progress.
- We will not pursue legal action against good-faith research that respects user privacy and avoids service disruption.
We don't currently run a paid bug bounty program, but we're glad to credit researchers who report responsibly.
Questions from your security team
We're happy to work through vendor questionnaires, architecture reviews and data-flow diagrams as part of an evaluation. Detailed technical documentation is available under NDA — get in touch and we'll route it to the right person.