fremforge Product Privacy Notice

title: fremforge Product Privacy Notice author: fremverk date: 2026-10-21 status: Published v1.27 version: “1.27” lang: en #

Last updated: 2026-10-21

Effective Date: 2026-04-25 — Current Version: 1.27 (effective 2026-11-12; until then version 1.25 applies from 2026-11-06, version 1.20 from 2026-11-03, and version 1.19 before that; full revision history in §Change log)

This notice supersedes the pre-launch marketing privacy policy for users of the hosted fremforge product at frem.sh. The marketing-site policy continues to cover visitors to www.frem.sh during and after launch.

1. Who this notice is for #

This privacy notice applies to you if you use the hosted fremforge product — that is, if you sign in to an organisation at frem.sh/<org> as a member, administrator, or owner, or if you use the public REST API at frem.sh/_app/api/v1/* as an authenticated user or via a registered agent.

Visitors to www.frem.sh, docs.frem.sh, and status.frem.sh are covered by the separate marketing-site privacy policy. Those sites are anonymous, cookie-free, and collect no personal data beyond server-access logs needed for edge delivery.

Anonymous visitors to public-docs wikis. If a tenant has opted in to anonymous public read of a repository wiki at frem.sh/<org>/<repo>/wiki[/...] (see Develop → Wiki and public docs), unauthenticated visitors to that surface are subject to this notice for the server-access logging only — no cookies are set, no authentication is required, no profiling is performed. Server-access logs capture IP, user-agent, requested path, and response status as part of normal edge-delivery telemetry; retention is the same as the §6 operational-logs retention (30 days hot, 3 years archive). The wiki content itself is published by the tenant Customer under their own determination of legal basis (typically legitimate-interest in publishing technical documentation); fremverk acts as hosting service provider under the DSA for that content. Custom CSS embedded by the tenant Customer in the wiki may include external-URL references (e.g. background-image: url(...)) — the tenant Customer is responsible for the privacy implications of any external URLs they reference; fremverk does not sanitise such references and does not control the third parties they reach.

2. Data controller and privacy contact #

fremverk ApS
CVR: 39150689
Ringager 4C, 2. tv, 2605 Brøndby, Denmark
Email: compliance@frem.sh

fremforge is a product brand of fremverk ApS. fremverk ApS is the legal and GDPR-responsible entity for all personal data processed in connection with the fremforge product.

Your organisation (the tenant) is the data controller for repository content, issues, pull requests, CI logs, and member activity produced within its organisation. fremverk ApS processes that data as a processor under the Data Processing Agreement (DPA) signed with the tenant at signup.

fremverk ApS is the data controller for account data, billing data, authentication metadata, audit logs, and other operational data required to run the fremforge service.

Data Protection Officer #

fremverk ApS is not required to designate a Data Protection Officer under GDPR Art. 37, because its core activities do not involve (a) processing by a public authority, (b) large-scale regular and systematic monitoring of data subjects, or (c) large-scale processing of special-category or criminal-offence data. This assessment is reviewed annually or when material changes to the Service are made.

The privacy contact for all data-protection questions, data-subject requests under GDPR Chapter III, and supervisory-authority liaison is compliance@frem.sh, routed to the data protection-responsible partner at fremverk ApS. This mailbox is the functional equivalent of a DPO contact for the purposes of data-subject communications.

If, following review, a DPO designation becomes required, fremverk will update this notice with the DPO’s name and contact details.

fremverk maintains a record of processing activities (ROPA) under GDPR Art. 30. The ROPA is reviewed annually and is available to the Danish supervisory authority on request.

3. What we process, why, and on what legal basis #

3.1 Account and authentication #

• What: email address, display name, password hash (if local auth is used), OIDC subject identifiers and claims mapped from your identity provider, TOTP secret (if 2FA is enabled), recovery codes (stored as bcrypt hashes; the original code is shown to the user once at generation and is never reversibly stored), session and API token identifiers, user-agent and IP of authentication events.
• Why: to authenticate you and enforce the access model (per-org session binding, SSO enforcement, SSH authorization via your IdP session).
• Legal basis — where fremverk ApS is controller of this account data (the authentication record itself and its operational metadata): contractual necessity under the agreement between fremverk ApS and your organisation (GDPR Art. 6(1)(b)) together with the legitimate interest (Art. 6(1)(f)) of maintaining access control and security of the Service. Your organisation remains the controller of its relationship with you as a user of its instance; its own legal basis (typically employment contract or a user-facing terms of service) applies to its processing of your data via fremforge, and fremverk ApS processes on its documented instructions per the DPA.

3.2 Repository and collaboration content #

• What: repositories, commits, issues, pull requests, comments, labels, wiki pages, releases, package registry artifacts, CI workflow definitions, CI run logs, webhook delivery records, audit log entries, SLSA provenance attestations.
• Why: because that is the product — a Git forge with CI/CD.
• Legal basis: contractual necessity under the tenant’s DPA. The tenant is the controller of this content; fremverk ApS is the processor.

3.3 Billing and commercial data #

• What: organisation name, legal entity, VAT number, billing contact, billing address, payment method (via Mollie; fremverk ApS never sees raw card data), seat count history, invoice records.
• Why: to invoice the tenant and comply with Danish bookkeeping obligations.
• Legal basis: contractual necessity (Art. 6(1)(b)); legal obligation (Art. 6(1)(c)) for invoice retention.

3.4 Operational and security logs #

• What: authentication events, admin-UI actions, API calls, policy enforcement decisions (push protection blocks, rate-limit hits, SSRF-filter rejections), infrastructure-level logs (T Cloud Public CES/LTS, T Cloud Public APIG access logs, runner controller), and the registry access log: one record for each request to an organisation’s package and container registry, including pulls through the dependency proxy, with the time, your login (or the bot or anonymous caller), your IP address, your client’s user agent, the package or image asked for, the action, and whether it was allowed or blocked. Routine requests that an organisation’s CI jobs make through the dependency proxy are the exception. When such a request is allowed and succeeds, a package metadata read is not recorded, and a download served from the proxy’s cache is only counted, per day, package version, repository and CI run. No login, IP address or user agent is kept for either. Access tokens, cookies and query strings are never recorded.
• Why: to operate the service securely, respond to incidents, and produce the audit-log export the tenant admin can pull on demand. The registry access log also gives the tenant admin a record of who fetched or published what from the organisation’s registry.
• Legal basis: legitimate interest (Art. 6(1)(f)) of fremverk ApS in maintaining service security and integrity; contractual necessity for audit-log availability to the tenant.

3.5 Cookies and local state #

We set four strictly-necessary cookies on the authenticated product surface. No non-essential cookies. No analytics. No consent banner required under ePrivacy Directive Art. 5(3). Full inventory:

www.frem.sh, docs.frem.sh, and status.frem.sh set zero cookies and contact no third-party operators. (The authenticated product surface at frem.sh and the status page each load brand fonts from https://www.frem.sh/fonts/ — same legal entity, same Bunny pull-zone, served from EU-only edges. No external CDN, no fonts.googleapis.com or equivalent. Per ePrivacy Article 5(3) this is not a third-party trace; per GDPR sub-processor disclosure, www.frem.sh is fremverk’s own surface, listed in DPA Annex B as part of the Bunny CDN sub-processor entry.)

Browser localStorage may hold UI preferences (theme, table density) set only in response to your explicit action in the admin UI. Never used for analytics, advertising, or cross-site tracking.

3.6 Support correspondence — split by channel #

3.6 Support correspondence — split by channel.

(a) Tenant support@frem.sh tickets: fremverk acts as processor on the Customer’s behalf for any personal data embedded in ticket bodies. Lawful basis (Customer side): performance of contract with the data subject or legitimate interest. Retention: 12 months from ticket closure.

(b) abuse@frem.sh reports under DSA Art. 16: fremverk acts as controller. Lawful basis: legal obligation (Regulation (EU) 2022/2065 — Digital Services Act). Retention: 5 years (DSA Art. 24 transparency-reporting horizon).

(c) security@frem.sh vulnerability reports: fremverk acts as controller. Lawful basis: legitimate interest in platform security (Art. 6(1)(f) GDPR, balancing test documented in fremverk’s ROPA). Retention: 24 months from report acknowledgement, or longer where actively used in defensive analysis.

3.7 Customer-configured AI processing #

If the Customer (the tenant admin) configures one or more AI vendors at Organisation admin → AI integrations, parts of repository content, pull-request diffs, issue text, and review prompts that you author may be sent through fremverk’s api to that AI vendor for processing. The AI vendor is chosen by the Customer, contracted directly between the Customer and the vendor, and is the Customer’s own processor — not a fremverk sub-processor (DPA Annex B §B.8).

What this means for you as a data subject:

• The Customer decides whether AI processing is enabled, which vendor (e.g. OpenAI, Anthropic, Google Vertex), and what prompts are sent.
• The Customer may choose a vendor incorporated outside the EU/EEA (including US-incorporated vendors); jurisdictional exposure of that processing is governed by the Customer’s own contract with the vendor, not by fremverk’s DPA.
• Prompts and responses transit fremverk’s api for routing plus an audit-trail emit — fremverk does not retain the prompt or response body beyond the request lifecycle. The audit-trail emit records the call (timestamp, actor, vendor identifier, model, token counts in and out, and latency) and never the prompt or response body. Corrected in privacy 1.13: this said “prompt-length / response-length”, which described character counts that are not what is recorded — the fields are the vendor’s own token counts. The substantive commitment, that no prompt or response body is stored, was and remains accurate, and is now machine-checked against the emit’s field list rather than asserted.
• fremverk’s commitment in AUP §3.7 (no training on Customer Content) applies to fremverk and its appointed sub-processors. It does not bind the Customer’s chosen AI vendor — the Customer is responsible for ensuring its chosen vendor’s terms align with the Customer’s own AI-training-data posture.
• If you want to know whether your tenant has AI processing enabled and which vendor, ask your tenant admin or contact fremverk per §15.

3.8 Dependency proxy #

If the Customer (the tenant admin) enables the dependency proxy, Users can pull container images and packages from public registries through fremforge. fremforge fetches each artifact from the upstream registry the User names and caches it for the Customer’s organisation.

What this means for you as a data subject:

• The upstream registry receives a request from fremforge’s IP address for the named artifact. It does not receive your identity or your IP address.
• The Customer may store its own credential for a registry, under the Customer’s agreement with that registry. Some registries require one (Docker Hub, and the Red Hat registries that require an account). For others the Customer may add one to reach its own private content (GitHub Container Registry and Quay). Where the Customer has stored a credential, every request to that registry carries it. Some of these registries are operated by US-incorporated companies; they are chosen by the Customer and are not fremverk sub-processors (DPA Annex B §B.9).
• Your pulls through the proxy are processed like other use of the package registry, as described in §3.4.

3.9 Product-update email (opt-in) #

If you turn on Product updates in your notification settings (frem.sh/_app/settings/notifications), fremverk ApS sends you occasional emails about significant new features and changes to the interface of fremforge. Each one is based on an entry of the public changelog. The setting is off unless you turn it on, and nothing is sent to you because of your organisation’s subscription alone.

• What: your username, the primary email address of your account, your interface language, and which fremforge organisations you are an owner of; the record of your consent (when you turned the setting on or off, how, and which wording you agreed to); and, for each email, the address it was sent to, its language, when it was sent, and whether it was delivered or bounced.
• Why: to send you the product updates you asked for, only while you are an owner of at least one fremforge organisation, and to be able to show that you asked for them.
• Legal basis: your consent (GDPR Art. 6(1)(a)). This is also the prior consent that the Danish Marketing Practices Act (markedsføringsloven) §10 requires before electronic marketing is sent. fremverk ApS is the controller of this processing. It is not processing on your organisation’s behalf, and your organisation does not decide whether you receive these emails.
• Withdrawal: turn the setting off in your notification settings, or use the one-click unsubscribe link in any product-update email. Withdrawal takes effect immediately and does not affect the lawfulness of emails sent before it (Art. 7(3)). It does not affect service, security, billing or legal notices, which do not depend on this setting.
• Recipients: Lettermint B.V. delivers the email (§4, §8). The data is not shared with anyone else.

4. Where the data is processed #

Every processing surface is operated by entities with no US parent. Full sub-processor list, including each sub-processor’s certifications, is maintained on the trust page.

5. CLOUD Act / US extraterritorial-law posture #

fremforge has no CLOUD Act exposure on any processing path fremverk chooses. All Customer Personal Data — repositories, CI runs, audit logs, authentication, billing, payment-instrument data, outbound transactional email, and inbound shared-mailbox correspondence — is processed by entities with no US parent: Deutsche Telekom AG inside Germany, Heinlein Hosting GmbH inside Germany, Mollie B.V. in the Netherlands, Lettermint B.V. in the Netherlands, and Bunny CDN at EU edge PoPs only.

fremverk ApS is a Danish entity. Neither fremverk ApS nor any of its sub-processors is subject to the US CLOUD Act, Foreign Intelligence Surveillance Act, Executive Order 12333, or related US compelled-disclosure statutes. See DPA §11.3 for the full posture.

Schrems II transfer assessment: not applicable. No Customer Personal Data is transferred outside the EEA on any processing path fremverk chooses. The AI vendors and upstream registries a Customer chooses are described in §3.7 and §3.8.

6. Retention #

• Account data: for the lifetime of your active membership in a fremforge organisation. Deleted within 30 days of your removal from all organisations, subject to any legal-hold obligations.
• Repository and collaboration content: for the lifetime of the tenant’s subscription. On tenant offboarding, retained for 90 days to allow full export (Terms §16.5), hard-deleted from primary storage within 30 days thereafter, and then expires from the encrypted live-tier backups within up to 90 days, as the snapshots that contain it age out (DPA §9). Total time from termination to expiry from the live-tier backups is up to 210 days. Disaster-recovery tier: in addition to the live-tier retention above, fremverk holds a separate DR tier of sealed snapshots — 13-month (395-day) retention for object-store payloads, 30 days for repository content (DPA Annex A.9) for catastrophic-recovery scenarios; these snapshots are sealed, fremverk-side-only, and used only to restore the platform after a catastrophic failure. Tenant-initiated audit-log exports are the one object-store payload excluded from this DR tier: they are not replicated cross-region at all, and live 7 days in-region in the signed download bucket before purge (see the export row in §Retention). Excluded deliberately — a signed, tenant-downloadable export is reproducible on demand from the audit log itself, so a sealed 13-month second copy of it would extend the life of Customer data well beyond the window the Customer was told about, for no recovery benefit. Corrected in DPA 1.26 / privacy 1.13: the replication toggle was set false on 2026-08-04 and the two Annex sentences still said every object-store payload carried the 13-month copy. Actions artifacts and CI run logs are also excluded from this DR tier: since 2026-10-21 they are not replicated cross-region, and the copies made before that date were permanently removed from eu-nl the same day. Excluded for the same reason as exports: an artifact or log lives only as long as your organisation’s own retention setting allows and is reproducible by re-running the workflow that produced it, so a sealed 13-month second copy would extend the life of that data well beyond the window your organisation chose, for no recovery benefit. Personal data inside DR-tier copies is purged on those rolling schedules independent of tenant offboarding — enforced by an object-lifecycle rule on each cross-region bucket, not by manual housekeeping: each object-store copy is permanently removed within 395 days, plus at most one day, of the day it was written to the DR region.
• Operational logs (HTTP, runner, infrastructure): 30 days hot, 3 years immutable archive.
• Authentication and security audit events: queryable hot tier per tenant choice (90 / 180 / 365 / 730 days; default 90 — enterprise plans default 365); 3 years immutable archive (hash chain only — payload redacted after the hot-tier cutoff). Tenant admins on enterprise plans set the hot-tier window at Authentication policy → Audit log retention. Data-subject access requests against a row past the hot-tier cutoff return the redacted record (chain hashes remain verifiable).
• Registry access log (§3.4): for the period the tenant chooses, between 30 and 730 days. If the tenant has not chosen one, it follows the tenant’s audit-log retention above (default 90 days; enterprise plans 365 days). Older records are deleted once a day. While a legal hold applies to the tenant’s organisation, no records are deleted.
• Billing records: 5 years per Bogføringsloven.
• Closed support tickets: 12 months.
• Product-update email (§3.9): the setting itself for as long as your account exists. The record of each time you turned it on or off, for 3 years after you withdraw consent or your account is deleted, whichever is later, as proof of consent (GDPR Art. 7(1)). The record of each email sent to you (address, language, time, delivery status), for 3 years after it was sent.
• DSA abuse reports: 5 years (DSA Art. 24).
• Audit-log exports initiated by the tenant: 7 days in the signed OBS bucket from which the tenant downloads, then purged.
• Waitlist data (legacy from pre-launch): purged at launch + 90 days, or earlier on request.

7. Your rights #

Under GDPR (Chapter III), you have the right to:

• Access (Art. 15) — obtain confirmation that we process data about you and a copy of it.
• Rectification (Art. 16) — correct inaccurate data.
• Erasure (Art. 17) — have your personal data erased, subject to legal retention obligations.
• Restriction of processing (Art. 18) — limit how we use your data in specific circumstances.
• Portability (Art. 20) — receive your personal data in a structured, machine-readable format. For fremforge tenant data, the self-service signed export provides this at org level; for your individual account data, contact compliance@frem.sh.
• Objection (Art. 21) — object to processing based on legitimate interests.
• Withdrawal of consent (Art. 7(3)) — where we rely on consent, withdraw it without affecting the lawfulness of prior processing.
• Complaint to a supervisory authority (Art. 77).

How to exercise: email compliance@frem.sh. We respond within 30 days (Art. 12(3)). For requests that involve repository or collaboration content owned by your organisation, we will route you to the organisation’s administrator where fremverk ApS acts as processor only.

Your organisation’s controller obligations: if your organisation is a GDPR controller in the EU, it has separate obligations to you directly under GDPR. fremverk ApS cannot answer controller-level data-subject requests on your employer’s behalf; the DPA defines the hand-off.

8. Sub-processors #

The current sub-processor list is maintained on the trust page and updated with 30 days’ advance notice of any change, per the standard DPA clause.

At the date of this notice, the sub-processors are:

P1-LEG-09: VIES (the EU Commission’s VAT-number validation service at https://ec.europa.eu/taxation_customs/vies/) is contacted at signup time to validate Customer-supplied VAT identifiers and qualify the reverse-charge mechanism. VIES is a non-commercial public-sector service operated by the European Commission and is not a sub-processor under Article 28: the only data submitted is the VAT identifier (a business-registration number, not personal data of the data subject), and lookup results (valid / invalid / unavailable) are stored against the tenancy record. Disclosed for transparency.

P1-LEG-10: Simply.com A/S (DK) is the registrar + DNS provider for the brand-redirect domains fremforge.com, fremforge.eu, fremforge.dk (all 301-redirect to www.frem.sh). No Customer Personal Data transits Simply.com — only DNS lookups for the redirect targets. Listed for transparency; not a sub-processor under Article 28 (DNS is generally treated as utility infrastructure, equivalent to internet routing). The product domain frem.sh and customer-facing surfaces use BunnyDNS (BunnyWay d.o.o., Slovenia — same sub-processor as the CDN/WAF/edge tier, already disclosed in Annex B row 2) for DNS — no Simply.com dependency on the customer-facing path.

Bunny: EU-only edge configured at pull-zone level; geo-replication outside EU disabled.

Mollie: Card-network sub-sub-processors (Visa Europe Services Inc. UK branch — parent Visa Inc. is US; Mastercard Europe SA — Belgium) operate under PCI-DSS. The Visa Inc. parent caveat is disclosed in DPA §11.3. Customers preferring zero US-parent exposure on the payment path may pay by SEPA Direct Debit.

9. Security #

Technical and organisational measures include, but are not limited to:

• TLS 1.2+ on every customer-facing surface. The certificates served at the public edge (frem.sh, www.frem.sh, etc.) are managed by Bunny CDN’s integrated certificate provisioning. The internal origin-TLS pipeline (Bunny edge → fremforge load balancers) uses certificates issued by Actalis S.p.A. (Italy, Aruba Group), an eIDAS Qualified Trust Service Provider on the EU Commission’s Trusted List under Regulation 910/2014. The CA receives only the FQDN being certified (*-origin.frem.sh) — never customer personal data — and is therefore not a sub-processor under Article 28 (same posture as VIES). See DPA Annex B for the full disclosure.
• AES-256 encryption at rest for repositories, databases, object storage, and backups, with keys managed in T Cloud Public DEW (Data Encryption Workshop).
• Scoped service accounts for every control-plane function; no super-admin tokens in normal operation.
• Mandatory MFA for platform administrators and break-glass accounts.
• Immutable audit log with tamper-evident hash chaining, anchored to OBS WORM storage.
• Pre-receive secret scanning on every push; dependency scanning on every PR; signed commits via OIDC identity (optional); SLSA provenance on build artifacts.
• Hosted runners run as ephemeral T Cloud Public Elastic Cloud Server virtual machines, one per job and destroyed when the job ends; no shared kernel between tenant jobs.
• SSRF hardening on every outbound path: per-pod VPC Security Group egress allowlist (Cloud Native Network 2.0) + a forced outbound-proxy CONNECT tunnel with SSRF deny-set + an app-layer SSRF guard; the three layers compose such that no tenant-influenced code path can bypass them.
• Published security-patching SLA: Critical CVEs (CVSS ≥ 9.0) patched within 48 hours of upstream fixed release, High (7.0–8.9) within 72 hours, Medium (4.0–6.9) within 7 days, Low at the next scheduled maintenance window (see trust page §Security patching). This SLA is cited verbatim in the DPA security annex.

Details and additional measures are documented in the DPA security annex.

10. International transfers #

No Customer Personal Data is transferred outside the EEA on any processing path fremverk chooses. All processing — repositories, CI runs, audit logs, authentication metadata, billing, payments, outbound transactional email (Lettermint B.V., Zwolle, Netherlands), and inbound shared-mailbox correspondence (Heinlein Hosting GmbH / mailbox.org, Berlin, Germany) — takes place inside the EU/EEA at entities with no US parent. No Article 46 GDPR safeguard is required. If your organisation enables an AI vendor (§3.7) or uses the dependency proxy with an upstream registry outside the EEA (§3.8), what the Customer sends there is governed by the Customer’s own agreement with that party.

11. Profiling and automated decision-making #

fremforge does not subject you to automated decisions producing legal or similarly significant effects on you (GDPR Art. 22). Automated decisions within the product — push-protection rejection of a commit containing a secret, merge-block on a CRITICAL dependency CVE, rate-limiter throttle on abusive traffic — are product rules that affect commits and requests, not data subjects, and can be reviewed or overridden by the tenant administrator per the policy hierarchy. Customer-configured AI features (§3.7) are similarly tenant-admin-controlled product rules: the tenant admin chooses whether AI processing is enabled and which vendor receives prompts; fremverk does not initiate AI processing on data subjects without the Customer’s explicit configuration.

The automated controls described above (commit push-protection, CI policy gates, dependency-scan blocks) do not produce legal or similarly significant effects on the data subject within the meaning of Art. 22(1): the controls operate on the technical content of a Git or CI request, not on the person, and the Customer’s tenant administrator can review and override every decision through the audit log and the policy-override workflow described in the documentation.

12. Children #

The Service is not directed to children. Where Customer Content includes personal data of a child, the Customer is responsible for the legal basis. The Danish digital-consent age under Databeskyttelsesloven §6(3) is 13; some other EU member states set 16. Customers should configure their organisations consistently with the age in the data subject’s member state.

fremforge is a B2B product and is not directed to children. We do not knowingly collect data from children. If you believe a child has signed up or been added as a member, contact compliance@frem.sh.

13. Supervisory authority #

Datatilsynet (Danish Data Protection Agency)
Carl Jacobsens Vej 35, 2500 Valby, Denmark
Phone: +45 33 19 32 00
Website: datatilsynet.dk
Email: dt@datatilsynet.dk

You may also lodge a complaint with the supervisory authority in your own EU member state.

14. Changes to this notice #

We may update this notice from time to time. Material changes are announced through two parallel channels so a Customer who watches either channel learns of changes: (a) the trust page (Watch the trust page or its RSS feed for in-product changes) AND (b) direct email to each Customer’s designated billing contact for changes affecting the legal basis of processing or adding a sub-processor. Both channels deliver at least 30 days’ advance notice for changes that are adverse to you or otherwise materially change how we process your data. Corrections of inaccuracy take effect immediately, disclosed through the change log at the foot of this notice: where a published statement is found to be wrong, holding the correction back for 30 days would mean knowingly continuing to publish something we know to be untrue, which is worse for you than a prompt correction. Neither route reduces your rights — the dual-channel mechanism guarantees notification even if one channel is missed (mailing-list opt-out, billing-contact email change, etc.). The effective date at the top of this page reflects the last meaningful content change. Prior versions are retained in Git and available on request.

Annex A — Processing activities by role #

Annex B — Contact quick reference #

• Privacy questions, data-subject requests: compliance@frem.sh
• General support: support@frem.sh
• Security vulnerabilities: security@frem.sh
• Abuse reports (DSA Art. 16): abuse@frem.sh
• Legal and law-enforcement contact: compliance@frem.sh
• Commercial inquiries: hello@frem.sh

Change log #

Versions track the DPA change-log — substantive sub-processor or processing-purpose updates published in the DPA are reflected here in the same numbered version, on the same effective date.