Security at Reditus

Last updated: 5 August 2026.

> Page: getreditus.live/security

> Version 1.1. Effective 5 August 2026.

> Reditus B.V., Kapelweg 12, 3951 AC Maarn, Netherlands. KvK 77814487. VAT NL861156420B01.

Security at Reditus

This page answers the questions we are asked most often in security reviews. Where we do not have an answer yet, it says so rather than guessing.

Reditus is an affiliate and referral platform. When you use it, we process personal data about your affiliates, about the leads and customers they refer to you, and about the people on your team who log in. You are the controller of that data. We are your processor. That relationship is set out in our Data Processing Agreement.

We have written this page to be checkable. Where a security property belongs to one of our suppliers rather than to us, we say so. Where we do not yet have something, we say that too, under "What we are working on" further down. We would rather answer a follow-up question than have a sentence on this page read back to us later.

If you want to send us as little as possible about the people your affiliates refer, read section 4.2 first. Our tracking API accepts an internal identifier of your own in place of an email address. Where you send only that identifier and you do not connect the Stripe, HubSpot or Calendly integrations, Reditus does not receive the referred person's email address. That is a real reduction in scope, and it is worth taking, but it is pseudonymisation rather than anonymisation and section 4.2 sets out exactly what it does and does not remove. An earlier version of this page described it as a "UID mode" that guaranteed we never received an email address. There is no such switch, and section 4.2 is the accurate description.

One thing to be clear about up front: Reditus does not hold a security certification of its own. We are not SOC 2 audited and we are not ISO 27001 certified. Our infrastructure providers hold certifications, and those are theirs, not ours. Anyone who tells you otherwise is reading an out-of-date page. If you need certified assurance today, the honest answer is that we can give you our suppliers' certifications and our own written answers, and not a certificate with our name on it.

1. Where your data lives

Your affiliate, referral and account records are stored at rest in the European Union. The database and the application hosting are both in the EU. File storage is a separate question and it is answered in the table below: uploaded files are held in Cloudflare R2, not in the database platform, and the location of that store has to be confirmed before this paragraph can cover it.

The core of the platform is in the EU. A number of supporting services are not, and we would rather set the whole list out here than have you assemble it from the sub-processor page. Our own code audit of 4 August 2026 found vendors in production that the first version of this page did not mention, so this list is longer than the one we published that day. That is a correction to the disclosure, not a change to the estate.

Functional Software, Inc. d/b/a Sentry, frontend error monitoring, processes in its United States region, and its error records carry a user identifier, email address and name.
Twilio Inc., trading as Twilio SendGrid, which sends transactional and payout email as well as our own marketing email, is a US company and holds recipient names and email addresses.
Honeybadger Industries LLC, backend error tracking, is a US company whose error payloads and stack traces can carry request data and any personal data that happens to appear in an error. We do not attach user-context tags to what we send it, and its log-ingestion product is switched off, so it receives error reports rather than a stream of our application logs.
PostHog, Inc. is a US contracting entity, even though event data rests in Frankfurt and the analysis interface our team uses is served from a US host.
Cloudflare, Inc. is a US entity, terminates TLS at the point of presence nearest the visitor, so request data is readable at edge locations worldwide, and holds our uploaded files in Cloudflare R2, whose region is not yet confirmed.
Supabase Pte. Ltd contracts through a Singapore entity, which has no EU adequacy decision, even though the database itself sits in Frankfurt.
HubSpot runs the support chat inside the application and receives the email address of every logged-in user, with onward access reaching HubSpot, Inc. in the United States.
Calendly LLC (United States, with no EU residency option), Paragon (United States), Slack Technologies, Inc. (United States default data residency), User.com, LinkedIn, n8n Cloud and Google Tag Manager are all sub-processors of customer data whose contracting entity, processing location or both we have not yet established. They are on the sub-processor page with those gaps marked rather than filled with an assumption.
Plane Software, Inc. (Delaware, United States) is our issue tracker. We use the hosted cloud service, which runs on Amazon Web Services. A ticket can carry the identity and contact details of the person who raised it, together with whatever they put in their report.

The transfer safeguard we rely on in every one of these cases is the Standard Contractual Clauses, and each is listed on our sub-processor page with the mechanism stated per vendor.

| Layer | Provider | Location | |---|---|---| | Application hosting, API and authentication | Hetzner Online GmbH, Industriestr. 25, 91710 Gunzenhausen, Germany | Nuremberg, Germany | | Primary application database, and nothing else | Supabase Pte. Ltd, 65 Chulia Street #38-02/03, OCBC Centre, Singapore 049513 | Frankfurt, Germany, with a Singapore contracting entity | | File storage for uploaded files, and hosting of the tracking script | Cloudflare, Inc., 101 Townsend Street, San Francisco, CA 94107, United States (Cloudflare R2 object storage) | |

| DNS, CDN, TLS termination and edge compute | Cloudflare, Inc., 101 Townsend Street, San Francisco, CA 94107, United States | Global edge network. Traffic is terminated at the point of presence nearest the visitor, which is not necessarily in the EU | | Transactional email, plus Reditus's own marketing email | Twilio Inc., trading as Twilio SendGrid | United States | | Payment processing | Stripe Payments Europe, Limited | European Economic Area. Stripe is our only payment processor | | Frontend error monitoring and masked session replay | Functional Software, Inc. d/b/a Sentry | United States (Sentry US region) | | Backend error tracking | Honeybadger Industries LLC | United States | | Product analytics | PostHog, Inc. | Frankfurt, Germany, for data at rest. The contracting entity is a US company | | In-product support chat, and Reditus's own CRM synchronisation of affiliate and advocate records | HubSpot | |

| Notification and messaging service receiving referral, lead and advocate data | User.com | |

| Internal Reditus notifications carrying affiliate identifying data | Slack Technologies Limited (Ireland) and Slack Technologies, Inc. (United States) | |

| Automation platform brokering the AI lead-discovery pipeline | n8n Cloud | |

| Tag container on the authenticated application (GTM-PSMWBCS) | Google Tag Manager, operated by Google | |

| Affiliate LinkedIn profile connection | LinkedIn Ireland Unlimited Company | |

| Issue tracking | Plane Software, Inc. (Delaware) | United States. Hosted cloud service, running on Amazon Web Services |

Authentication is ours, not a managed service. Sign-in, password storage and session handling run inside the Reditus application on Hetzner, not in the database platform's authentication product. Section 3 gives the detail. We say it here because an earlier version of this page attributed authentication to Supabase, and a reviewer sizing up the blast radius of a database-platform compromise deserves the accurate version.

What our suppliers are certified for, and what that does and does not mean

Hetzner Online GmbH holds ISO/IEC 27001:2022, certified by SOCOTEC Certification Deutschland GmbH, with a scope covering all of its hosting services and data centres, including Nuremberg, Falkenstein and Helsinki. That certificate is Hetzner's. It covers the physical and operational security of the facilities and the hosting platform our application runs on. It says nothing about how Reditus writes code or manages access, and we do not present it as if it does.

Supabase publishes SOC 2 Type 2 and ISO 27001. Those are Supabase's certifications, covering the Supabase platform.

Reditus holds neither. See "What we are working on".

A transfer point we would rather you heard from us

Our data sits in the EU, but the company we contract with for the database is registered in Singapore. Singapore does not have an EU adequacy decision. So even though your data never leaves the EU region, the Reditus-to-Supabase relationship is treated as a restricted transfer and is covered by Standard Contractual Clauses.

Supabase's Data Processing Addendum, version 1 of 1 August 2026, applies SCC Modules Two and Three under Irish law, with the UK Addendum and a Swiss addendum, and commits them to 30 days' notice of sub-processor changes with a five-day objection window.

We mention this because a careful reviewer will find it, and it is better coming from us. Data location and contracting entity are two different questions and both matter.

2. Encryption

In transit. All traffic to Reditus, to our API, and to our tracking endpoint is served over HTTPS. TLS is terminated at Cloudflare's edge.

At rest. Customer data stored in our database, in file storage and in backups is encrypted at rest by the storage platform.

On top of that, some fields are encrypted by the application itself. These are encrypted before they reach the database, using Rails ActiveRecord Encryption, so what the database holds is ciphertext rather than the value. That covers:

affiliate bank account identifiers (IBAN);
Reditus API key tokens;
the credentials and secrets for connected integrations, including payment-provider secrets, product and webhook secrets, and the Slack access token.

This matters more than storage-level encryption, because it survives a copy of the database being read by anything other than our application.

Two fields are not covered, and we would rather say so. PayPal payout email addresses and affiliate tax identifiers are stored in plain text. They are protected by access control, not by encryption. Bringing them under the same scheme is in section 9.

What encryption at rest does not do, and we will not pretend otherwise. Encryption at rest protects against someone walking off with a disk. It does not stop an infrastructure provider with legitimate platform access from reading data, and it does not stop an attacker who has compromised a running application, because at that point the application decrypts data as a matter of course. Any vendor telling you that encryption at rest means "not even our suppliers can see your data" is describing something else.

What actually limits who can read your data is access control, which is the next section.

> NOT FOR PUBLICATION. This section deliberately corrects the live help-centre claim at /help/privacy-summary that "all data stored in our database is fully encrypted, ensuring that even our subprocessors or hackers can't access any personal information". That sentence is false and must come down in the same change that publishes this page, not later. Defect H8 in the discovery brief.

> Also unresolved and relevant here: none of the three Reditus cookies (_gr_id, _gr_cookietest, _gr_referral_widget) sets Secure, SameSite or HttpOnly, and _gr_referral_widget holds cleartext JSON including email, first name, last name, company name, company id, product id and an auth_token. Do not publish anything about cookie security posture until those flags are set and the auth_token question is answered. Three further corrections from the CTO audit, for whoever writes the cookie policy: _gr_cookietest is set by the referral widget, not by the tracking script; the configurable cookie window is 1 to 119 days, not 1 to 120, with 60 days the default; and _gr_id uses a sliding expiry, so actual retention exceeds the stated window whenever a visitor returns. The _gr_id payload carries eleven fields, including the Customer's own uid and a free-form session id.

3. Access control

Your team. Access to a Reditus account is controlled by you. Users sign in with an email address and password. Authentication runs inside our own application (Devise), not in a third-party identity platform, and passwords are stored only as bcrypt hashes with a cost factor of 11. We never hold the password itself, and nobody at Reditus can read one. Merchant account users and affiliates are separate roles with separate views: an affiliate signing into your programme sees the affiliate view, not your account.

Sessions. Sessions are token-based. We store only a SHA-256 hash of each session token, never the token itself, alongside the IP address and browser user agent the session was created from. A session lasts two weeks. The expiry is enforced on every request that presents the token, so an expired token stops working the moment it expires. One honest caveat: expired session rows are not yet purged from the database, so the hash, the IP address and the user agent of an old session persist until the account is deleted. That cleanup job is in section 9.

Keeping your account separate from every other account. Reditus is a shared-schema multi-tenant application: your records sit in the same database as other customers' records and are separated by application-level access controls. Every action in the API goes through a Pundit authorisation policy, and that check is mandatory rather than opt-in: a request that reaches an action without an authorisation decision having been taken is refused, not allowed through. There is no database row-level security underneath that, so application-level access control is exactly what we call it, and we will not describe it to you as database-enforced isolation.

Our team. Reditus is a small, fully remote company. We have no offices that process customer data: production data sits with the infrastructure providers named in section 1.

The principle we work to is least privilege: a person or a system gets the narrowest access that lets them do the job, and nothing beyond it. We would rather describe the mechanism than assert the principle, which is why the questions above are marked rather than answered.

4. What the product holds, what it records, and how we build it

The cheapest way to secure personal data is not to hold it. Two parts of the product are designed around that, and one part currently holds more than it needs to. This section also covers what we do with an IP address, how we build and ship, and what happens to production data when it is copied into staging, because those are the follow-up questions we get every time.

4.1 What affiliates see about referred customers

When an affiliate looks at the referrals they have generated, they need to know that a referral happened and whether it converted. They do not need the person's identity.

Masking the referred person's email address is the default. It is also a setting: for a given partnership you can switch full visibility on if you decide your affiliate needs it. The default is the private one, and the choice to change it is yours rather than ours.

4.2 Sending us an internal identifier instead of an email address

Our tracking API accepts an identifier of your own in place of the referred person's email address. Where you send only that identifier, and you do not connect the Stripe, HubSpot or Calendly integrations, Reditus does not receive the referred person's email address.

That is worth doing. Here is what it does not do, stated plainly, because this is the kind of claim a reviewer will test.

It is pseudonymisation, not anonymisation. The identifier is free text that you choose, we do not validate it, and it still points at a real person in your systems. It remains personal data under the GDPR and it remains covered by our DPA.
There is no account-level switch that blocks email addresses. The identifier and the email address are two fields on the same request, either one satisfies our validation, and both are stored if both are sent. Our own installation documentation shows both being sent, and the snippet builder inside the app currently offers the email field only. Running identifier-only is therefore a property of what your pages send, not a mode we can turn on for you, so check the payload your pages actually produce. Tell us during onboarding and we will go through it with you.
Connected integrations still carry email addresses. If your Stripe, HubSpot or Calendly integration is connected, the referred person's email address reaches us through that integration whatever your page sends.
The tracking request itself still carries the page URL, the referring URL and the visitor's IP address. We truncate the IP address at the point we record it, as described in 4.4.

What our tracking script does not do. Our script sets a first-party cookie containing a randomly generated identifier so that a referral can be attributed to the affiliate who earned it. It writes that cookie only when an attribution parameter is present in the address, so a visitor who arrives at your site from search, from a direct link or from anywhere else without one receives no cookie from Reditus at all. That is worth stating precisely, because it means our script is not setting an identifier on your general traffic: it sets one on the traffic an affiliate sent you. It does not fingerprint the device. We have checked this against our own source: the script reads no user agent, no installed plugins, no language, no screen dimensions, no colour depth, no canvas, no WebGL, no AudioContext, no device memory, no hardware concurrency, no touch points and no timezone. It does not read local storage or session storage. There is no probing of any kind.

Two caveats on that, because "no fingerprinting" is a claim people test. First, the tracking call is an image request, so the browser attaches the headers it attaches to any image request, including the user agent string and the IP address. We do not read them from JavaScript, but they arrive with the request. Second, we do use the IP address, truncated, as a fraud signal, which is 4.4 below. Neither of those is device fingerprinting, and we would rather name them than have you discover them.

What the script sends is mostly under your control, and our server accepts a fixed list. Beyond attribution, the script transmits whatever your own page passes to it. If you configure it to send customer metadata, we receive that metadata. Please do not send us special-category data.

Our tracking endpoint does not simply store whatever arrives. It reads a fixed allowlist of parameters and discards everything else, so a stray query string on your page does not end up in our database. The list is evt, ref, url, ip, grid, m_email, m_uid, m_source, m_cal_event, m_cal_user, m_hub_utk, customer_id, affiliate_slug, cslug, ctype, pk, rl and sid. An earlier version of this page said there was no fixed allowlist. There is one, and it is a better answer than the one we gave.

The exception, and it is on us: where you run our script alongside a HubSpot form or meetings widget, or alongside a Calendly booking widget, our own integration code reads the end user's email address from that submission and sends it to us by default, in the query string of the tracking request. You did not configure that, we did, and we are changing it. If you want it addressed now, tell us and we will work with you on it.

We also read Google advertising parameters out of the URLs you send us. Where a stored page URL contains gclid, gad_source or gad_campaignid, we parse those values to detect referrals that arrived through paid search, which many programmes prohibit their affiliates from using. That is a fraud signal, described in 4.4. We do not use those values for advertising measurement and we do not use them to target anyone.

What our tracking script also reads. Where a visitor arrives with a referral parameter belonging to another affiliate network in the URL (via, wpcr, fpr, fp_ref, ps_partner_key or awinmid), our script records that value and the network it came from, stores it in our own attribution cookie, and sends it to our tracking endpoint. We read it from the URL only. We do not read any other network's cookies or storage. For one of the six the value is the merchant's identifier rather than the affiliate's.

> NOT FOR PUBLICATION. Risk 7.6 in the discovery brief: Reditus's own shipped HubSpot integration in v2.js extracts the end user's email address from HubSpot form submissions and sends it as m_email in a GET query string, by default, on any merchant page carrying both the script and a HubSpot widget. The CTO audit adds Calendly: the Calendly path behaves exactly the same way and was missing from every earlier description, so the public text above now names both. The script also logs the HubSpot token and Calendly UUIDs to the browser console outside the debug flag. The public wording above ("what the script sends is under your control") is true of merchant-supplied m_* keys but is not a full account while those defaults exist. Either fix them and the console logging, or keep the explicit disclosure above. Do not publish this section as-is if the disclosure sentence has been removed while the defaults are still live.

4.3 Session recording and error reporting in the application, stated plainly

Two tools watch what happens inside the logged-in Reditus application. This is the sort of thing a controller needs to know before approving a processor, so it is here rather than only in our privacy notice.

Sentry is our frontend error monitoring, and it is frontend only: there is no Sentry agent in our backend. It records 10% of all sessions, plus 100% of sessions in which an error occurs. Its replay is explicitly configured to mask all text and block all media, so a recording carries page structure, navigation, click sequences and console output rather than the words on the screen or the contents of a field. That masking is a deliberate setting in our code, not a default we happen not to have changed. Error events, as distinct from replays, carry the user identifier, email address and name by design. Sentry data goes to Sentry's United States region; the transfer safeguard for that leg is the Standard Contractual Clauses, and the Sentry row of our sub-processor page carries the open point on the execution status of that agreement.

PostHog is our product analytics. Session replay is not enabled in the application's PostHog configuration, so what PostHog receives is events and page views rather than recordings of your screens. What we attach to those events does identify the logged-in user: email address, full name, plan and monthly recurring revenue. Events are sent through an EU endpoint and rest in Frankfurt, Germany; the PostHog interface our own team logs into is the US one, and PostHog, Inc. is a US company, which is why it appears on our sub-processor list with the Standard Contractual Clauses as the safeguard rather than being described as an EU vendor.

We are still tightening this. The remaining work is to confirm at the project level that PostHog recording is off, to reduce the identifying attributes we attach to analytics events, and to set and publish a retention period for both tools. The row in section 9 carries the target date.

> NOT FOR PUBLICATION. This subsection was rewritten against the CTO code audit of 4 August 2026, which overrides the earlier account in the discovery brief and the founder's verbal answers. Two things changed and both matter. (a) PostHog session replay is not enabled in code. The previous text stated 100% capture with urlBlocklist: [] and masking: null; that configuration is not what the repository contains. The marker above is the only honest position until the PostHog project settings have actually been read, because recording can be enabled server-side. Check it before publication and close the marker either way. (b) Sentry replay is masked (maskAllText, blockAllMedia), which is a genuine control and supports DPA clause 2.2, so it is now stated as one. The escalated IBAN-in-session-replay risk recorded in the ground-truth file rested on the PostHog configuration described in (a); re-run that assessment once the project settings are known. What has not changed: publish the disclosure and the remediation date in the same release, and do not hold the disclosure back for the fix.

4.4 Fraud signals, rate limiting, and what we do with an IP address

We truncate IP addresses at the point of collection. Referral events, lead events and widget clicks all record where the visit came from, and the address is cut down before it is written: an IPv4 address loses its final octet, leaving a /24 network, and an IPv6 address is truncated to a /40 prefix. The full address of a referred visitor is not stored on those records. The only Reditus record that retains a full IP address is the session row for a signed-in Reditus user, described in section 3. That is a statement about our own records and not about the whole estate, so two things sit alongside it rather than inside it: the edge, analytics and company-lookup vendors named in our privacy notice receive request IP addresses in the ordinary course, and the edge key-value store behind the tools on our marketing site holds a visitor's email address and IP address for up to 24 hours. Section 9 of the privacy notice sets out both, and an earlier version of this page implied a scope for the sentence that it does not have.

Fraud detection, described accurately. Affiliate programmes attract self-referral, so the platform looks for it. Three checks run today:

1. whether the referred person's email address is the affiliate's own;

2. whether the referral came from the same IP range as the affiliate, using the truncated addresses above;

3. whether the visit arrived through a paid Google ad, detected from the advertising parameters described in 4.2.

These produce advisory flags for you to review. Nothing is rejected automatically, and there is no duplicate detection. If you have seen duplicate detection attributed to Reditus in an older document of ours, that was wrong; this is the accurate list.

Rate limiting. The production API applies application-layer rate limiting, with six throttle rules in force. It is on in production by default rather than being something an operator has to remember to enable.

4.5 How we build, test and ship

Review before merge, then an automatic deploy. Work happens on branches in our GitLab repositories and reaches production through a merge request. Merging to master deploys to production automatically. The gate is therefore the merge request and its review, not a separate manual button at deploy time. Earlier Reditus documents described production deploys as a manual, deliberate action. That was wrong, and this is the accurate description.

What runs on every build. Static application security testing with Brakeman, and linting with RuboCop on the backend and ESLint on the frontend. Our RSpec suite covers approximately 95% of lines.

Two qualifications on that, because both would otherwise be overstatements. Coverage is measured when we ask for it and is not enforced: there is no minimum-coverage threshold that fails a build when coverage drops. And we do not currently run automated dependency vulnerability scanning. The Bundler Audit step exists in our pipeline configuration but is switched off, pending a framework upgrade it depends on. Any Reditus document that lists dependency scanning as an active control is out of date, and re-enabling it is in section 9.

4.6 Staging and test data

Production data does get copied into our staging environment, and the copy is anonymised on the way in: personal fields are replaced with generated values as part of the sync, so what a developer sees in staging is not your customers' data. The pipeline is backed by an audit task that fails if a column holding personal data has not been classified, which is the part that makes it hold up over time: a new column carrying personal data cannot quietly pass through unanonymised.

This is a control over our own internal copies, and it is not an erasure mechanism. Anonymising staging does nothing whatsoever to production data. Nothing on this page should be read as saying that a deletion request is satisfied by a staging refresh. Deletion of production data is governed by our DPA and described in our privacy notice.

> NOT FOR PUBLICATION. The anonymisation pipeline reduces the exposure in Task 3c but does not close it. Before relying on this subsection, confirm that the current staging database was populated through the pipeline rather than restored from a raw dump, and gate the host regardless. If any real affiliate email address, payout email address or IBAN is found in staging, this subsection cannot publish as written and Task 3c becomes an Article 33 assessment, not a housekeeping item.

5. Sub-processor governance

We publish the full list of the companies that process personal data on our behalf, with the legal entity, the country, the purpose, the categories of data and the transfer mechanism for each one:

www.getreditus.live/sub-processors

That page is on a domain we control, and it will stay at that address. It is the URL our Data Processing Agreement names.

Before we add a new sub-processor that will process your data, we give you at least 30 days' notice. We publish a dated update on our trust centre and we email the privacy or admin contact on your account. We do not rely on you having noticed a website change.

If you object within 14 days of that notice, we will work with you to resolve it, for example by offering an alternative sub-processor or a different configuration, and we will keep the objected-to sub-processor away from your data while the objection is unresolved wherever that is technically possible. If we cannot resolve it within 30 days of your objection, you may terminate the affected service without penalty and we will refund prepaid fees for the unused period on a pro-rated basis, with transition assistance and a full export at no charge. Clause 9.3 of the DPA is the binding version, and it carries the export and assistance commitment as well as the refund. Clause 9.5 is a different clause: it is the flow-down obligation we owe on every sub-processor contract.

There is one carve-out, and it is a real one. If a change is needed urgently to keep the service available, secure or intact, or if a sub-processor stops being able to provide its service, we may make the change immediately and tell you as soon as we practically can, saying which of those circumstances applied. Your objection window then runs from that notice instead.

You can subscribe to sub-processor change notices here:

6. Security incidents

If we become aware of a personal data breach affecting your data, we will tell you within 48 hours.

That is a hard commitment, not "without undue delay". We chose 48 hours deliberately: if you are a controller with a 72-hour notification duty to your supervisory authority, a vague promise from your processor makes your own deadline impossible to hit. "Become aware" means the point at which any member of our team has a reasonable degree of certainty that an incident has occurred. Our own triage does not postpone the clock.

What you get from us:

1. Within 48 hours of becoming aware of the incident, notice to the privacy or admin contact on your account, with what we know so far: what happened, which categories of data and roughly how many records are affected, what we have done to contain it, and who to talk to at Reditus.

2. Updates as the picture changes. Early notice necessarily means incomplete notice. We would rather tell you something incomplete on time than something complete too late.

3. A written root-cause analysis within 30 days of containment, including what we are changing so that it does not happen again.

We will not ask you to keep an incident confidential from your own regulator, and we will not condition notification on you signing anything.

If you are subject to NIS2 and have a 24-hour early-warning duty of your own, tell us in writing and we will notify you within 24 hours of becoming aware instead of 48. That is a standing commitment under clause 6.5 of the DPA, not something you have to negotiate. See section 8.

Reporting a vulnerability. Send it to

7. Availability and business continuity

Uptime.

Status page. Live and historical availability is published at status.getreditus.live. It is operated by a separate vendor on a separate account from the Reditus application, so an application-level failure does not take it down. It is not on wholly independent infrastructure: the status page is itself served from Hetzner in Germany, so a provider-level event could affect both.

Infrastructure resilience. The application runs in ISO/IEC 27001:2022 certified Hetzner data centres. The database platform is operated by Supabase with its own redundancy and backup arrangements.

Backups. The production database is snapshotted daily and supports rollback to any day in the preceding 7 days, so the backup retention window is 7 days. That is the same evidenced figure stated at row 9 of the DPA retention schedule (Annex A1) and in section 12 of our privacy notice.

Buyers should read the absence of numbers above as exactly what it is: we have not yet formalised and published our recovery objectives. That work is listed below.

> NOT FOR PUBLICATION. status.getreditus.live currently loads Better Stack's own Google Ads tag AW-10805602682 and GA4 property G-CM1E1N1Q4R and fires a page view on every load, with no consent gate, on a getreditus.live subdomain. Fix or disclose before linking to the status page from a security page. It is a small thing that looks bad in exactly the audience this page is written for.

8. NIS2 and supply-chain security

The Dutch Cyberbeveiligingswet, which implements the NIS2 Directive in the Netherlands, was adopted by the Eerste Kamer on 7 July 2026 and takes effect on 15 August 2026 with no transition period.

If you are a regulated entity under NIS2, Article 21(2)(d) requires you to manage the security of your supply chain, including the security of your direct suppliers. That means you will be sending security requirements to vendors like us. We would rather answer here, once, than negotiate the same rider forty times.

Our own position

Reditus is not a directly regulated entity under the Cyberbeveiligingswet. We are a small enterprise, below the size threshold at which NIS2 applies, and we are not one of the entity types to which the rules apply regardless of size, such as DNS service providers, TLD name registries or trust service providers.

Being out of direct scope does not make us irrelevant to your compliance. It makes us a supplier you have to be able to evidence.

What we commit to, so you do not have to draft a rider

These commitments apply to every customer, and we will restate them in a signed addendum if your procurement process needs one.

1. Incident notification within 48 hours of becoming aware of an incident that affects your data, as set out in section 6. If your own regulatory duty needs a shorter window, tell us in writing and 24 hours applies automatically under clause 6.5 of the DPA, as section 6 above states; only a period shorter than 24 hours needs to be agreed in your order form.

2. A named security contact who will respond to your security questionnaires and incident queries, rather than a shared inbox that routes to support.

3. A published, maintained sub-processor list with legal entity, country, purpose, data categories and transfer mechanism, at a URL on our own domain, with 30 days' notice of changes and a genuine right to object.

4. Written answers on request, without an NDA, covering hosting, encryption, access control, retention and transfers. If you need something under NDA, ask and we will handle it.

5. Flow-down. We engage a sub-processor only under a written data processing agreement imposing obligations no weaker than the ones we owe you, and we remain fully liable to you for their performance under Article 28(4) GDPR.

6. No unilateral downgrade. We will not reduce a security commitment made on this page without telling affected customers first.

What we do not commit to, and why

We will not agree to an on-site audit of our offices, because we do not have offices that process customer data. We are fully remote and production data sits in the data centres named in section 1. What we will do instead is answer questionnaires, provide our suppliers' certifications, and, once we have our own audit reports, share those under NDA. If your regulated obligation genuinely cannot be satisfied that way, we will do a remote audit by video conference on 30 days' notice, once per twelve months.

We will not accept a security clause that requires us to hold a certification we do not hold. Where a rider asks for SOC 2 or ISO 27001, we will tell you the truth about where we are, which is the section below.

9. What we are working on

Everything above describes what is in place today. This is what is not, and what we are doing about it.

| Item | Where we are | Target | |---|---|---| | Independent security certification (SOC 2 Type 2 or ISO/IEC 27001) | Not held. Reditus has no certification of its own. | |

| Independent penetration test | | | | Formal information security policy set | In progress. We are building the policy set in our compliance platform. | |

| Published recovery objectives (RTO and RPO) and a tested restore | Not yet formalised. See section 7. | |

| Published Transfer Impact Assessment covering our US sub-processors | Not yet published. We are EU-established, so the assessment is limited to our own US sub-processors, which makes it a short document. | |

| Consent management across our websites and application | In progress. | |

| Analytics and session recording: confirmed project-level settings, fewer identifying attributes on events, and a stated retention period for both tools | Partly done. Sentry replay is masked and PostHog replay is off in our code. What remains is the PostHog project-level check, the attribute reduction and the retention period. See section 4.3. | |

| Automated dependency vulnerability scanning re-enabled, and a coverage threshold that fails the build | Not running. The Bundler Audit step is disabled pending a framework upgrade, and coverage is measured without a minimum. See section 4.5. | |

| Application-level encryption extended to PayPal payout email addresses and affiliate tax identifiers | Not done. Both are stored in plain text today. IBANs, API tokens and integration secrets are already encrypted. See section 2. | |

| Expired session rows purged rather than left in place | Not done. Expiry is enforced on read, so an expired token cannot be used, but the row and its IP address and user agent persist. See section 3. | |

| Legacy Paddle payer records deleted | Not done. Our Paddle connection is switched off and customers no longer pay through it: Stripe is our only payment processor. What remains is data rather than a vendor. Payer records holding an email address and a name, and the stored Paddle webhooks, are still in the database from before the Stripe migration, and neither has a cleanup job. They are scheduled for deletion. | |

| Self-service deletion: an account-deletion route for customers and affiliates, and self-service removal of payout details | Not available. Deletion is handled by us on request today, and removing payout details requires asking us. Deleting an account does cascade through the data; deleting a single programme does not. | |

| Advertising tags removed from authenticated and affiliate-facing pages | Not done. Google Ads, DoubleClick and the LinkedIn Insight Tag currently load on the sign-in page and the public marketplace. | |

| Single sign-on, and customer-visible audit logs of authentication, permission changes and exports | | |

We publish this table because a page that only lists strengths tells a reviewer nothing. If a competitor's security page has no equivalent section, that does not mean they have nothing missing.

A previous certification, for the record. Reditus previously advertised a "Privacy Verified" certification. It is not current: it expired and was not renewed. Any Reditus page still referring to it is out of date and is being corrected. We do not hold it today and we do not claim it.

10. Questions

For security questionnaires, the DPA, or anything on this page: privacy@getreditus.live. Until privacy@getreditus.live and security@getreditus.live are live, mail to info@getreditus.live reaches the same people and we will not treat a request as invalid for having been sent there.

Reditus B.V., Kapelweg 12, 3951 AC Maarn, Netherlands. KvK 77814487. VAT NL861156420B01.

Related documents: Data Processing Agreement · Sub-processors · Privacy Policy · Terms of Service

> NOT FOR PUBLICATION: sequencing warning for Part 1.

> This page should not go live before, or separately from, the following, or it will create new contradictions rather than resolve them:

> 1. The "Privacy Verified" claim is removed from /help/privacy-summary.

> 2. The false encryption claim at /help/privacy-summary is rewritten.

> 3. The Terms of Service sentence stating that content "may be transferred unencrypted" is deleted. It directly contradicts section 2 of this page and will be found.

> 4. The Terms of Service "Communications Not Confidential" disclaimer is deleted. It contradicts section 8 commitment 5 and the Article 28(3)(b) confidentiality duty.

> 5. The privacy policy's wrong controller address (currently "Europalaan 100, Utrecht") is corrected to Kapelweg 12, 3951 AC Maarn. The same wrong address is live on /affiliate-terms.

> 6. DPAs are executed with Sentry (Functional Software, Inc.) and PostHog, Inc. Commitment 5 in section 8 is a written Article 28(4) representation and is untrue until they are.

> 7. The Trust Centre AI Posture page, which names a large language model vendor that appears on no Reditus sub-processor list and commits Reditus to a CCPA "Do Not Sell" mechanism that does not exist, is unpublished. See Part 3, Task 1.

> Publishing a candid security page while other live Reditus documents contradict it is worse than publishing nothing, because it proves the contradictions were known.