Everything a security review asks for, before you ask us.
How ProLion is built, how it is operated and where your data sits — written for the people who have to sign off on it.
Syslog CEF and REST, into the tool you already run
The short version.
ProLion runs inside your estate. File names, contents and metadata never leave it — there is no ProLion cloud for them to go to. Everything below is the detail behind that sentence.
Fully on-premises
Dark sites included. No telemetry requirement, no cloud dependency for detection, nothing to open in the firewall for the product to work.
Austrian company, EU jurisdiction
ProLion GmbH is Austrian, with no US parent. Your file metadata stays inside your estate, under your own law, not ours.
Coordinated disclosure
A published security contact and a stated response window for vulnerability reports — including from people who are not customers.
Let’s solve your data challenges.
Connect with our engineers to find the right approach for your infrastructure.
The detail.
Ten sections, written for the people who have to sign off rather than for a brochure. Open the one you were sent here for.
What a trust center is — and what this one answers
Before an organization puts software next to its file data, somebody has to answer for it: an information security officer, a data protection officer, an auditor, often a procurement team working through a questionnaire. They ask the same questions every time. How is the software built? Who can reach our data? What happens when a vulnerability is found? What do you do with our information?
This page is where those answers live, so you can read them before you contact anyone. Where a document cannot be public — a penetration test report names weaknesses, for example — the page says so and tells you how to request it.
Product security — how the software is built
A secure development lifecycle with threat modeling per release. Static and dynamic application security testing in the build pipeline, dependency and open-source scanning on every build, and annual third-party penetration testing of the appliance.
Release artefacts are signed and published with checksums through my.prolion.com, so you can verify that the package you install is the package we built.
Deployment and operational security — who can do what
The appliance runs inside your network, under your own change control. Role-based access control, single sign-on via Entra ID, Okta, SAML or OIDC, and the four-eyes principle on destructive actions: a second person has to agree before anything irreversible happens.
Every administrative action in ProLion is itself audited — including who changed a detection rule, and when. Your administrators are in the log alongside everyone else.
Data privacy, residency and sovereignty — where your data sits
ProLion processes file metadata — paths, operations, users, timestamps — inside your own infrastructure. File contents are not transmitted to ProLion at any point, and classification runs locally on your hardware.
There is no ProLion-operated cloud tenant holding customer data. That is what makes dark-site operation possible at all, and it is what keeps the data under your own jurisdiction rather than ours.
Vulnerability handling and coordinated disclosure
A published security contact and a stated response window for vulnerability reports. Findings are triaged, fixed in a scheduled release or a hotfix depending on severity, and communicated to affected customers with the information needed to assess their own exposure.
Security contact address, PGP key and response-time commitments to be filled in by the security team.
Incident response and business continuity
What ProLion does when something goes wrong at our end, and what you can expect from us while it is being fixed: who you hear from, how quickly, and what information you get for your own notification duties under NIS2 or GDPR.
To be completed by the compliance team — notification timelines and the escalation path belong here.
AI and automated processing
Detection and classification run as local analysis on your hardware. Customer file contents are never used to train a model, and no file data is sent to a third-party AI service.
To be confirmed and completed by the compliance team before launch.
Certifications, frameworks and audit reports
To be completed by the compliance team — this section lists what ProLion itself holds, with the validity dates of each certificate and the audit history, not only the current report.
Separately, ProLion produces evidence toward your obligations under GDPR, NIS2, ISO 27001 and DORA. That is a different thing from the certificates above, and the people who build it will walk you through it — ask us.
Sub-processors
A sub-processor is a third party that could come into contact with personal data on our behalf. GDPR requires the list to be available, with each one’s purpose, location and the categories of data concerned.
For an on-premises deployment the list is short by design: the product does not send your file data anywhere, so most of what a SaaS vendor has to declare does not arise. What remains is the corporate side — support tooling, hosting of my.prolion.com, and the like.
The named list is to be completed by the compliance team.
Personnel and physical security
Background checks, confidentiality agreements, security training and the access controls at our own offices in Wiener Neustadt, Wiesbaden and New York.
To be completed by HR and the compliance team.
Talk to an engineer who knows your data.
Four fields, and somebody who knows ONTAP, PowerScale and what FPolicy does. Not a qualification call.