Privacy policy

1. Who we are

Qorionix is the identity, privileged access, log analysis and endpoint detection platform described on this site, and we operate the website and the services at qorionix.com.

The operating company is being formed and is not registered yet. There is no registered name, registered office, trade-register number or VAT number to state here, and we are not going to invent one on a privacy policy. The registered particulars are published on the company details page as soon as the entity is registered, and this section is updated to name it on the same day.

For any privacy question, write to [email protected]. For a matter specifically for our data protection contact, use the subject prefix [DPO]. A person reads it and answers it.

For personal data inside your Qorionix tenant — your staff's accounts, sign-in records and endpoint telemetry — you are the controller and we are your processor. The lawful basis, the retention decision and the response to a data subject are yours; we provide the mechanism, the export and the evidence. For this website and our own business records, we are the controller.

2. What we collect

This website

• Technical data. IP address, user agent, referrer and pages viewed, held in server logs for security and to see which pages are read.
• Local storage. Your light or dark theme preference, and — on the support portal only — the fixture data described in the cookie policy. No third-party advertising or behavioural trackers.

Support requests

• Your name, email address, organisation, and the content of your request including any attachments you send.
• Support requests about a security matter frequently contain a description of your organisation's weaknesses. We treat them accordingly: same tenancy scoping and same residency binding as platform data, and access limited to the people handling the case.

The platform

• Account data. Names, email addresses, roles, authentication methods and session records for the people you give access to.
• Security telemetry. Sign-in events, directory and privileged-access records, endpoint process activity, and the events you send us from your own sources.
• Microsoft 365 inventory, where you connect it: users, groups, roles, policies, licences, devices, application consents, sign-in logs and inbox rules. We request only the fields the checks actually read rather than accepting Microsoft Graph's default projection, which is a data-minimisation requirement and not an optimisation.
• Billing data. Company details and the identity count your subscription is based on.

3. Why we process it

• To provide the service you have bought, which is the performance of our contract.
• To keep the service and its customers secure, which is our legitimate interest and yours.
• To answer your support requests, and to keep a record of them because that record is frequently the evidence of what was decided.
• To meet our own legal and regulatory obligations, including accounting.

Legal basis under Article 6 GDPR: performance of a contract for the platform; legitimate interest for security and for the operation of this website; consent where you have given it for marketing communications, withdrawable at any time.

4. Artificial intelligence, stated plainly

Sentinel-Q and the posture narration use a large language model. Three facts about that, because the vague version of this section is where vendors hide things:

• Your data is not used to train any model. Not ours, not our provider's.
• Prompts contain excerpts of your events. That is how an assessment gets written at all. We are not going to imply the model works without seeing your data.
• The inference region is reported as unverified unless we can derive it from the endpoint itself. A cloud provider may route an inference request outside the region of the endpoint it was sent to, and ours currently offers no contractual regional guarantee. Setting a region in our own configuration does not clear this — that is recorded as an assertion and still reports as unverified, because it is a claim rather than evidence. Your organisation's AI system card shows the current value. The posture assessment, the detection library and the evidence bundle all work with the model features switched off.

Every model-generated assessment carries a standing disclosure that it is AI-generated, and what the model told your operator is persisted so a later reviewer can check it.

5. Where data is stored

Qorionix runs one production region, in the EU (Ireland), and every organisation is bound to it on first write. A request carrying a token issued in another region is refused rather than served. Data is encrypted in transit with TLS 1.2 or better, and at rest; privileged credential vaults use AES-256-GCM under envelope encryption with the key-encrypting key held in a managed key service.

The architectural binding above applies on every tier and is a property of the software rather than of a contract. A contractual data-residency addendum on the Enterprise tier is planned and cannot be offered yet: an addendum is executed by a legal person and the operating company is being formed. We will not take a signature on a document we cannot countersign.

6. Retention

• Security events are retained for the period your subscription tier provides — 30, 90, 365 or 730 days — configurable per event classification across hot, warm and archive tiers.
• Audit records are retained longer than events, because they are the evidence that answers a regulator, and are hash-chained so alteration is detectable.
• Support tickets are retained for 24 months after closure, with attachments purged at 12 months.
• Website server logs are retained for 90 days.
• On termination, your data is deleted within 30 days on request, or 90 days by default. Compliance artefacts you have asked us to hold are retained for the period you specified.

These periods describe current practice and intended defaults rather than contractual commitments. Several of them are still awaiting legal review, and a retention commitment is a term of a signed agreement — which follows the registration of the operating company. Where you hold a subscription agreement, that agreement governs and takes precedence over this list.

7. Sub-processors

We notify customers at least 30 days before adding a sub-processor that processes customer data, so you have time to object.

The current list is in the trust packet. Request it from [email protected] with the subject [TRUST REQUEST].

We have not executed sub-processor agreements yet, because a data-processing agreement is signed by a legal person and the operating company is being formed. Each sub-processor above is used under its own published terms today. Executing our own DPAs is the first commercial task after registration, and the packet carries them from that point.

8. Your rights

Under GDPR and equivalent laws, you may request:

• Access to the personal data we hold about you
• Correction of inaccurate data
• Erasure — the right to be forgotten
• Restriction of, or objection to, processing
• Portability in a machine-readable format
• Withdrawal of consent at any time, where consent was the basis

Email [email protected] to exercise any of these. If you are one of our customer's staff rather than our direct customer, contact your own organisation first — they are the controller and we will refer your request to them, as we are required to.

You may lodge a complaint with the supervisory authority in your own country — the authority of your member state of residence or of your place of work, which is your right under Article 77 GDPR and does not depend on where we are. The authority competent for us as a controller follows from where the operating company is established, and it is named here as soon as the company is registered.

In the platform, an administrator of your organisation can produce a machine-readable export or a cascading erasure directly. How that works, step by step.

9. If something goes wrong

Where we are your processor and become aware of a personal-data breach affecting your data, we notify you without undue delay so you can meet your own Article 33 obligation. Where we are the controller, we notify the supervisory authority within 72 hours where required. Incidents affecting the availability of the service are published on our status page within one hour of confirmation.

10. Changes

We post changes here and update the date above. Material changes affecting how we use your data are emailed to customers, and a sub-processor addition is notified at least 30 days before it takes effect.