QReportly

QReportly

Sign in

Trust Center

Security and architecture built for confidential reporting

QReportly is a production EU SaaS platform for internal whistleblowing channels — with company isolation, role-based access, encrypted transport, and a public reporting flow designed to minimise identification risk.

This page is written for technical buyers, DPO reviewers, and leadership teams evaluating whether QReportly is suitable for confidential internal reporting. We describe controls we actually operate — without publishing details that would help an attacker.

Trust pillars

01

Confidential reporting by design

The public channel is built for people who need to speak up without creating an employee account.

  • Anonymous reports use a tracking code and access key separate from workplace identity.
  • The public reporting flow is designed not to persist IP address, User-Agent, or fingerprinting data.
  • Image attachments are reprocessed on upload to strip EXIF and similar metadata before storage.
  • Follow-up messaging stays inside the case — not in shared inboxes or generic email threads.

02

Access control and separation of duties

Only authorised company roles can open case material. Partner and officer flows are separated from the main dashboard.

  • Workspace data is scoped by organisation — reports and files are not mixed across companies.
  • Platform roles include owner, admin, member, and designated officer with distinct responsibilities.
  • Partner accounts and designated-officer access use separate authentication paths from the main company dashboard.
  • Session-based authentication protects administrative surfaces; public report URLs alone are not enough to manage a company.

03

Infrastructure and payments

Production workloads run on established EU cloud providers, with card payments handled by a specialised processor.

  • Platform infrastructure is hosted in the European Union (application and managed database/storage services).
  • All browser and API traffic uses TLS encryption in transit.
  • Object storage for attachments uses per-organisation access control.
  • Subscription billing goes through Stripe Checkout and customer portal — card data stays with Stripe.

04

Operational integrity

Compliance workflows are product features, not spreadsheets bolted on afterwards.

  • Acknowledgement and case handling are built into the product workflow for Directive (EU) 2019/1937-style channels.
  • Retention can follow the employer’s internal policy; attachments can be purged when retention ends.
  • An electronic register supports audit-oriented case documentation.
  • Legal notices, privacy policy, and cookie policy are published alongside the product — not hidden behind sales calls.

Architecture at a glance

Multi-tenant application model
Each customer organisation is a separate logical workspace. Reports, membership, and attachments are tied to that organisation’s boundary.
Authentication layers
Company users authenticate to the dashboard with account credentials (and optional Google sign-in where configured). Officers and partners use dedicated flows so privileges stay separated.
Password protection
Account passwords are stored as one-way bcrypt hashes — not reversible plaintext.
Transport security
HTTPS/TLS protects data between browsers, APIs, and the platform edge. We do not claim client-side end-to-end encryption of report bodies as a product feature.
Attachment handling
Uploads are sanitised for identifying metadata where applicable, then stored under organisation-scoped access rules.
Billing isolation
Payment instruments are handled by Stripe. QReportly keeps subscription and customer references needed to run the service — not full card PANs.
Administrator authentication today
Email/password (bcrypt) with authenticator-app TOTP and hashed recovery codes. MFA is required for organisation owners, admins and designated officers, and remains optional for other members. Privileged Google sign-in still requires the platform authenticator after login.

Technical and organisational measures

Transport encryption
Browser, API and edge traffic uses TLS. We do not claim client-side end-to-end encryption of report bodies.
Access control
Role-based access and logical isolation of each organisation’s workspace, reports, members and attachments.
Passwords
Account passwords are stored as bcrypt hashes, not reversible plaintext.
MFA
Native TOTP with encrypted secrets at rest and hashed recovery codes. Required for owners, admins and designated officers. Optional for other members.
Independent pentest
We have not published a third-party penetration-test report. We do not claim ISO 27001, SOC 2, or a completed external pentest on this page.
Backups
Primary production data is backed up in EU-hosted infrastructure, with encrypted backups as operated by the hosting stack.
Attachment sanitisation
Image and document uploads are processed to strip EXIF and similar identifying metadata before storage.
Reporter identifiers
The public reporting flow is designed not to persist reporter IP, User-Agent or fingerprinting data.
Incidents
If a personal-data breach affects Channel Data we notify the Client without undue delay, as described in the DPA.
Status page
This site includes a live reachability probe (not a historical status.qreportly.com SLA dashboard). Material incidents that affect availability are still communicated to administrators through operational channels.

Data retention matrix

These are the product defaults described in the Privacy Policy. The Client as controller may configure retention within the limits of the law that applies to its organisation. This table is not legal advice.

Jurisdiction (product default)Attachments after case closedRegister / case text
Default (most EU Member States)180 calendar days5 years, then hard delete
Germany (workspace configured for 3-year register)180 calendar days3 years, then hard delete
Client configurationWithin applicable lawWithin applicable law

Responsible transparency

Trust also means knowing what we will not publish. Oversharing infrastructure details can increase risk for every customer.

What we share here
Security principles, access model, hosting region posture, payment handling, anonymity design of the public channel, and links to legal documents.
What we do not publish
Internal network diagrams, exact firewall rules, unpublished vulnerability details, staff credentials, or step-by-step attack surface maps.
Certifications
We describe controls we operate today. We do not claim SOC 2, ISO 27001, or similar certifications on this page unless independently completed and listed here.
Security contact
Report security issues to contact@qreportly.com. For privacy questions use contact@qreportly.com. Do not send live credentials or exploit payloads by email.

Technical & security FAQ

Where is customer data hosted?
Customer report content and primary production application, database and object-storage workloads are hosted in the European Union. Certain ancillary providers (billing, and where used authentication) may process limited account or operational data outside the EEA under Standard Contractual Clauses or other GDPR-permitted safeguards.
Can one company see another company’s reports?
No. Reports, members, and attachments are scoped to the organisation. Administrative access requires an authorised role in that organisation.
Is the reporting channel anonymous?
Reporters can submit without creating an employee account, using a tracking code and access key. The public channel is designed not to store reporter IP or fingerprinting data. Absolute anonymity also depends on what the reporter chooses to write or attach.
Do you use end-to-end encryption for report content?
Traffic is protected with TLS in transit, and storage access is controlled per organisation. We do not market true client-side end-to-end encryption of report bodies as a core feature — we prefer accurate wording over buzzwords.
Who can read a case inside the company?
Only users with the appropriate company role (for example owners, admins, or designated officers according to how the organisation is configured). Partner and officer portals are separated from general company settings where applicable.
How are payments secured?
Subscriptions are billed through Stripe. Card numbers are entered on Stripe-hosted checkout surfaces; QReportly does not store full card numbers on its own servers.
What should a DPO or IT reviewer ask next?
Review the Privacy Policy, Data Processing Agreement, Subprocessors list, Cookie Policy, and Terms, then validate organisational roles and retention settings for your deployment. For vendor questionnaires, contact support with your checklist — we answer with facts, not marketing fluff.
Do you enforce MFA for administrators?
Yes for privileged roles: organisation owner, admin and designated officer must enable authenticator-app TOTP. Other members may enable it optionally. Enforcement is on the server for reports, attachments and organisation administration. Google sign-in does not skip that requirement.
Do you have ISO 27001, SOC 2 or an independent pentest?
No published ISO 27001, SOC 2, or third-party pentest report at this time. We describe controls we actually operate. When an independent assessment exists, it will be listed here rather than implied.

Evaluate QReportly with clear expectations

Start a workspace, review pricing, or ask a security question before you commit. Confidential reporting deserves a platform that explains its controls honestly.