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 closed | Register / case text |
|---|---|---|
| Default (most EU Member States) | 180 calendar days | 5 years, then hard delete |
| Germany (workspace configured for 3-year register) | 180 calendar days | 3 years, then hard delete |
| Client configuration | Within applicable law | Within 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.
Related documents
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.