Security at Reqlio

Last updated 24 September 2026 · covers the application at <customer>.reqlio.eu

Reqlio holds the requirements, verification evidence and review history of engineering teams. This page says, in plain terms, where that data lives, who can reach it, what leaves the EU and why, what happens when something breaks, and what we have not done yet. The questionnaire at the end is pre-filled so your security review can start from answers rather than from a blank form.

On this page

1. Architecture and tenancy
2. Hosting and physical security
3. Encryption
4. Data location and sub-processors
5. AI: what is sent, where, and how to turn it off
6. Authentication and access control
7. Secure development and change control
8. Vulnerability management and disclosure
9. Logging and monitoring
10. Backups, recovery and continuity
11. Incident response
12. GDPR and the data processing agreement
13. People and organisation
14. Questionnaire (pre-filled)

1. Architecture and tenancy

Reqlio is a single-page web application talking to one API, backed by PostgreSQL. Each customer gets their own subdomain (yourcompany.reqlio.eu) and their own PostgreSQL database. There are no shared content tables and no tenant-id column that a missed WHERE clause could leak across; a query physically cannot reach another customer's data because it is connected to a different database.

• The tenant is resolved from the hostname on every request. An unknown hostname gets a 404, never a default tenant.
• Every session token carries the tenant it was issued for, and the user record is looked up inside that tenant's database. A token from one tenant is worthless on another.
• Each tenant has its own connection pool. Nothing is cached across tenants.
• The supplier portal (Business plan) gives external parties access to exactly the specifications a customer grants, scoped per party; the isolation between parties was part of the September 2026 adversarial review.

Web, API and database run as separate containers on one virtual server, behind a TLS-terminating reverse proxy. There is no content delivery network and no edge cache: a request from your browser goes to Frankfurt and back.

2. Hosting and physical security

Production runs on virtual servers operated by creoline GmbH, Bergstraße 9a, 48341 Altenberge, Germany, certified to ISO/IEC 27001:2022 by TÜV SÜD (registration 12 310 69090 TMS, valid to March 2028) for the operation and maintenance of virtual servers and infrastructure. The hardware stands in the FRA4 data centre of firstcolo GmbH, Kruppstraße 105, Frankfurt am Main, which holds ISO/IEC 27001:2022 with data-centre operation in scope (TÜV Rheinland, registration 01 153 1700043, valid to February 2028) and is a TÜV-certified data centre level 3 against DIN EN 50600 (TÜV Saarland, valid to February 2027).

firstcolo provides the building, power, cooling and physical access control. It has no logical access to the servers or the data on them, and is therefore not a sub-processor. creoline's certificate and data processing agreement are available on request, or from creoline's own certification page.

Staging and the analytics server run on the same provider. The build server, source repository and code-quality scanner are self-hosted with the same provider on a separate operations network reachable only over VPN.

3. Encryption

4. Data location and sub-processors

All customer data is stored in Germany. One thing leaves the EU, and it is optional: AI requests. This table is the authoritative sub-processor list referred to in our data processing agreement; we give 30 days' notice before adding to it.

Not sub-processors, for clarity: firstcolo GmbH (physical facility only, no data access); Plausible (self-hosted on our own server, cookieless, aggregate page counts under one label for the whole application, never per customer); Slack (only if you connect a workspace, in which case notifications go to your workspace on your instruction); email, which is sent from our own mail server through creoline's relay.

5. AI: what is sent, where, and how to turn it off

AI is part of the product: quality scoring against an INCOSE-style rubric, rewrite suggestions, decomposition, conflict and glossary scans, verification and risk suggestions, trace narratives and a project chat. Every one of those goes through a single code path with the following properties.

• What is sent. The requirement text and the context the feature needs (neighbouring requirements, glossary terms, the rule profile). Never attachments, never account data, never other customers' data.
• Where it goes. To Anthropic's API in the United States by default, or to Google's Gemini API if the project's admin selects it. There is no EU-only model endpoint today; a bring-your-own-endpoint option (your key, your region) is planned for the Business plan.
• What the provider keeps. Neither provider trains on API traffic. Anthropic retains prompts for up to 30 days for abuse monitoring and offers zero-data-retention on request; Google's paid tier retains for up to 55 days. Both are terms of the commercial APIs, not of the consumer products.
• How to turn it off. Each project has an AI switch. When it is off the API refuses every AI route before any model is contacted. An organisation can also hide the AI tools module for all its users, and the daily background quality sweep runs only for projects that opt in.
• What we log. Provider, model, feature, token counts, project and user id per call, for the usage meter and the monthly allowance. Not the prompt, not the answer.
• What the model can change. Nothing on its own. A suggested rewrite becomes a requirement only when a user applies it, and that goes through the ordinary edit path with history, so it is reviewable and reversible like any other change.

The MCP server (early access) lets an agent such as Claude work in your project through the same permission model as a user: it authenticates with OAuth 2.1 and PKCE, stops at an explicit consent screen, and holds a personal access token you can revoke at any time.

6. Authentication and access control

7. Secure development and change control

• Every change reaches production through one pipeline and nothing else: build, lint, the full backend test suite against a real database, the frontend type check and unit tests, a dependency audit, static analysis with a security quality gate, and an end-to-end suite that walks the golden path (create project, import ReqIF, assess, link, baseline, review, approve, export) in a browser. A red gate blocks the deploy.
• Changes deploy to a VPN-only staging environment first, from the development branch, and to production from the main branch.
• Database migrations are hand-written SQL, versioned in the repository and applied by the deploy job before the new API starts; a failed migration stops the release.
• The application sets standard browser hardening headers, uses parameterised queries throughout, validates input with schemas at the API boundary, and sanitises every rich-text render site. Spreadsheet exports neutralise formula injection.
• Third-party code loaded by the browser: none. Fonts, scripts and styles are served from our own origin, enforced by a content security policy on the website.

8. Vulnerability management and disclosure

• Dependencies. The pipeline fails on any high or critical advisory in production dependencies, on every run. A weekly scheduled job reports all advisories and outdated packages, dev tooling included, so drift is seen within seven days.
• Static analysis. SonarQube with a security quality gate that production deploys wait on.
• Reviews. In September 2026 the authentication surface (sessions, MFA, tenant isolation, SSO, the OAuth provider, the supplier portal) went through a structured adversarial review; every critical, high and medium finding was fixed and deployed within two days. A summary is available on request.
• External test. Not yet. A manual penetration test by a named EU firm, with an attestation letter and a retest, is scheduled for the first quarter of 2027, before the pricing page opens to self-serve signups. The letter will be linked here.
• Reporting a vulnerability. Write to security@reqlio.eu. We acknowledge within two working days, keep you informed, and do not pursue good-faith research that stays within your own test data and avoids service disruption. Details are in our security.txt.

9. Logging and monitoring

10. Backups, recovery and continuity

What is backed up. Every tenant database, nightly at 02:00 UTC, as a compressed PostgreSQL dump. New tenants are picked up automatically. Retention on the host is tiered: 7 daily, 4 weekly (Sundays) and 6 monthly copies. At 02:30 the dumps, all file attachments, the database roles and the configuration needed to rebuild the service are staged into one export.

Off-site copy. Every night at 03:30 a machine outside the hosting provider's infrastructure pulls that export over the VPN and SSH. The pull is one-way: the backup machine holds a read-only key pinned to its own VPN address, and the production server cannot reach the backup machine at all, so a compromised server cannot alter or delete the copies. The hosting provider additionally keeps daily full-server images for seven days.

Restore is tested, not assumed. A scripted drill restores a production dump into a throwaway database on the staging host and checks row counts, latest baseline and latest review. Last run 9 September 2026: 3.6 MB dump, 94 tables, 583 requirements, restore in 14 seconds end to end. The drill is repeated quarterly and after any change to the backup script or the database version; the log is kept in the repository.

Recovery model. Production is one virtual server in one facility; there is no live replica. Recovery from a host failure is restore from the latest nightly dump onto a fresh server, so the realistic data-loss window is up to 24 hours and the recovery time is a few hours. We say this plainly because a questionnaire will ask, and because the plans at this price do not include a multi-site database.

Continuity, in writing. Reqlio is built and operated by a small company. The following are commitments, and they appear in the data processing agreement:

• Exports in ReqIF, XLSX and CSV are available on every plan, at any time, including during the trial and after cancellation. No export is paywalled.
• After cancellation you keep read-only access to your workspace, with exports, for twelve months. After a trial that is not converted, the workspace is read-only, not deleted, for 60 days.
• On Enterprise, source-code escrow is available.
• At the end of the read-only period, or earlier on request, your database is deleted, and it ages out of the backup tiers within six months.

11. Incident response

• Errors and outages surface through monitoring and the uptime probe, not through customer reports, and are handled by the operator directly; there is no queue between you and the person who can fix it.
• If we confirm a personal data breach affecting your data, we notify your named contact within 24 hours of confirming it, with what we know, what is affected, what we have done and what we advise, and we update as the picture changes. This is the processor duty under GDPR article 33(2); 24 hours is our stated maximum rather than "without undue delay" left undefined.
• Suspicious authentication activity is visible to your own admins in the security log without waiting for us: failed logins, MFA failures, token reuse and role changes are recorded as they happen.
• A post-incident summary, with cause, timeline and corrective action, is provided to affected customers.

12. GDPR and the data processing agreement

For the data you put in Reqlio, you are the controller and we are the processor. We sign a data processing agreement under article 28 GDPR with every customer, in English (an AVV in German usage; the terms are the same). It contains:

• the subject matter, duration, nature and purpose of processing, and the categories of data and data subjects (Annex 1);
• the technical and organisational measures under article 32, which are the concrete controls described on this page (Annex 2);
• the sub-processor list in §4, with 30 days' notice of changes and a right to object (Annex 3);
• the transfer mechanism for the AI providers: EU standard contractual clauses, and the EU–US Data Privacy Framework where the provider is certified, plus the fact that AI is per-project optional and can be disabled entirely;
• breach notification within 24 hours, assistance with data-subject requests and impact assessments, audit rights, and deletion or return at the end of the contract.

Request the current version, the TOMs and creoline's own DPA and certificate from info@reqlio.eu. The privacy policy for this website, where we are the controller, is a separate document: privacy.html.

13. People and organisation

Reqlio is developed and operated by Holtstiege Consulting, Amsterdam. One person has production access. A single operator is a real question on a questionnaire, so here is the honest answer and what compensates for it:

• No change reaches production without passing the automated gates in §7; the operator does not deploy by hand, only through the pipeline, and every deploy is tied to a commit.
• Production access is over VPN with a personal key; SSH sessions and privileged commands are logged on the host.
• Runtime secrets are mirrored encrypted so that the service can be rebuilt by a successor from the repository, the secrets mirror and a backup, and that rebuild is what the restore drill rehearses.
• The continuity terms in §10 exist precisely for the case that the company does not.

No data protection officer is appointed, and none is required (article 37 GDPR). Our supervisory authority is the Dutch Autoriteit Persoonsgegevens.

14. Questionnaire

Pre-filled answers to the questions security reviews usually ask, grouped the way the Cloud Security Alliance's CAIQ-Lite groups them. If your template asks something not here, send it; we answer questionnaires as part of the sales process, not as a paid extra.

Application and interface security

Business continuity and resilience

Change control

Data security and privacy

Encryption and key management

Governance and compliance

Human resources

Identity and access management

Infrastructure and virtualisation

Logging and monitoring

Security incident management

Supply chain and sub-processors

Threat and vulnerability management

Questions about anything on this page: info@reqlio.eu. Vulnerability reports: security@reqlio.eu.