Privacy Policy — Render

How Render Technologies Limited uses data for Render.

Version v1.6-render — effective from 2026-07-28

Render payment data

Render uses Stripe for card entry and payment authorisation. Render stores payment evidence such as provider reference, amount, currency, authorisation, capture, cancellation, and webhook event status. Card numbers and sensitive payment-method details stay with Stripe.

# Privacy Policy — Render

**Version v1.6-render — effective from 28 July 2026**

## 1. Who we are

Render at render.my is operated by Render Technologies Limited ("Render", "we", "us"), the data controller for the personal data described below. Contact: privacy@render.my.

## 2. What we collect

- **Account data** — your email address, display name, and authentication identifier (via Clerk).
- **Company data** — the Companies House number(s) you add to your account.
- **Directorship check data** — to add a company you confirm you are one of its currently-appointed directors. You pick yourself from that company's public list of active directors and enter the month and year of your birth and the date you were appointed. We check both against Companies House. What we keep is the officer you picked and whether each check matched; the month and year of birth themselves are not stored.
- **Filing data** — the CT600 form fields you complete, plus the assembled iXBRL accounts and iXBRL computation; the GovTalk envelope we send to HMRC; HMRC's response.
- **Companies House send data** — if you send your accounts to Companies House from your account page, we keep a record of that send: the submission number and transaction reference, the timestamp Companies House gave it, a fingerprint of the accounts document sent, and anything Companies House said in reply. The record deliberately holds no user identifier and no authentication code.
- **Payment evidence** — Stripe provider reference, amount, currency, authorisation status, capture status, cancellation status, failure status, and webhook event ids.
- **Provenance metadata** — the version of the Authority manifest in effect at the moment your filing was submitted.
- **Operational telemetry and product analytics** — request logs, PostHog event data, a first-party interaction journal, and early-beta Codex/OpenAI monitoring evidence for service reliability, beta support, and understanding where users get stuck in the filing journey.

## 3. What we do not collect

- We do not store card numbers, CVCs, or sensitive payment-method details. Stripe handles card entry and payment-method processing.
- We do not hold per-user HMRC Gateway credentials in our database; transmission to HMRC uses Render Technologies Limited's own vendor credentials.
- We do not store your company's own six-character Companies House authentication code. You type it for a single send to Companies House; it is passed straight through, and is never written to our database, our logs, your data export, or any analytics event.
- We do not send exact tax-form values, UTRs, CT600 XML, iXBRL files, GovTalk envelopes, HMRC payload bodies, or payment details to PostHog session replay. Exact filing values remain in Render's own systems and submitted Filing Record.

## 4. Why we hold it — lawful bases

Under UK GDPR Article 6 we rely on:

- **Article 6(1)(b) — performance of a contract** — to hold your account, your draft, your submitted filings, and payment evidence needed to provide the paid filing service.
- **Article 6(1)(a) — consent** — only for marketing emails, if we later ask you to opt into them separately.

We do not rely on Article 6(1)(c) (legal obligation) — Render is a software supplier, not the legal record-holder for your tax returns. HMRC keeps its own copy of every submission, and your company is independently required to keep its own books.

## 5. How long we hold it

We hold your account and draft data only for as long as you maintain an account with us. Submitted filing records and non-sensitive payment evidence are treated differently because they are evidence of what was submitted and charged. When you delete your account, your login, account row, memberships, and mutable drafts are deleted. Submitted filing evidence may still be retained to prove what was sent to HMRC and to handle audit, dispute, legal, payment, or record-keeping questions. Retained filing evidence can include generated CT600 XML, iXBRL accounts, iXBRL computation, GovTalk envelope, IRmark, timestamps, HMRC response evidence, Companies House send evidence, payment evidence, and authority-manifest provenance.

## 6. Who we share it with

- **HMRC** — your CT600 + iXBRL accounts + iXBRL computation are transmitted to HMRC.
- **Companies House** — two separate connections, and only the first happens automatically. *Reading:* public Data API lookups for company information, last-filed accounts, and the officer list used to check your directorship. *Sending:* if you choose to send your accounts to Companies House from your account page, we transmit the micro-entity accounts document, your company's name and number, the date the accounts were approved, and the company's own authentication code to the Companies House filing gateway. Those sends currently reach Companies House's **test** service only, so nothing sent through Render today reaches the public register. We will publish a new version of this policy before that changes.
- **Stripe** — payment authorisation, capture, cancellation, and payment-status webhooks.
- **Clerk** — authentication.
- **Neon** — Postgres database hosting.
- **Resend** — transactional email.
- **Sentry** — production error monitoring with sensitive filing contents removed before events are sent.
- **PostHog** — signed-in product analytics and, only when you switch on support replay, masked browser-session replay for support/debugging. We do not send raw CT600 XML, iXBRL files, GovTalk envelopes, HMRC payload bodies, cookies, authorisation headers, passwords, claim tokens, or payment details to PostHog event properties.
- **OpenAI/Codex** — for early beta users, Render may ask an OpenAI-hosted Codex agent to review a short-lived signed evidence bundle for your filing journey. The bundle is generated from Render's own systems and can include account/session identifiers, form progress, validation and submission status, Interaction Journal rows, PostHog event/replay references, payment-status evidence, and safe error summaries so we can check whether the service is working as expected. Codex monitoring is for support, debugging, and safety checks, not advertising.

Render also keeps a short-retention internal interaction journal during beta. It records structured facts such as which form field changed, whether it was empty, the broad value-length bucket, validation state, checkbox state, select/gate answer, save status, and submit/review blockers. It does not store raw sensitive field values unless the field is a checkbox, select/gate option, or support preference that is safe to record exactly.

Exact filing values remain in Render's own systems and submitted Filing Record. During early beta, those first-party records may be included in the short-lived Codex evidence review where needed to check the filing journey, after you accept the current terms and privacy wording. Codex evidence links expire and are not public links.

We do not sell your data.

## 7. Your rights

Under UK GDPR you have the right to access, correct, erase, restrict, port, or object to processing of your data. Contact privacy@render.my.

You can complain to the Information Commissioner's Office (ico.org.uk) about how we handle your data.

## 8. Cookies and tracking

Render uses essential authentication cookies, strictly necessary Stripe payment-session cookies or redirects, and PostHog analytics for signed-in users who have accepted the current terms. Detailed support replay is off unless you switch it on in the form support panel, and replay inputs are masked. During early beta, Render may also generate short-lived Codex/OpenAI monitoring evidence to check the filing journey almost live. We do not use advertising cookies in this filing app.

## 9. Changes to this policy

We will publish a new version of this policy here when we make material changes. The version number above moves on each change.

## 10. Contact

Render Technologies Limited 
Company number: 17088258 
Registered office: 39 Islingword Road, Brighton, BN2 9SF 
privacy@render.my

Complaints about privacy can be sent to privacy@render.my. You also have the right to complain to the UK Information Commissioner's Office.

Render is operated by Render Technologies Limited.

# Privacy Policy — Render **Version v1.6-render — effective from 28 July 2026** ## 1. Who we are Render at render.my is operated by Render Technologies Limited ("Render", "we", "us"), the data controller for the personal data described below. Contact: privacy@render.my. ## 2. What we collect - **Account data** — your email address, display name, and authentication identifier (via Clerk). - **Company data** — the Companies House number(s) you add to your account. - **Directorship check data** — to add a company you confirm you are one of its currently-appointed directors. You pick yourself from that company's public list of active directors and enter the month and year of your birth and the date you were appointed. We check both against Companies House. What we keep is the officer you picked and whether each check matched; the month and year of birth themselves are not stored. - **Filing data** — the CT600 form fields you complete, plus the assembled iXBRL accounts and iXBRL computation; the GovTalk envelope we send to HMRC; HMRC's response. - **Companies House send data** — if you send your accounts to Companies House from your account page, we keep a record of that send: the submission number and transaction reference, the timestamp Companies House gave it, a fingerprint of the accounts document sent, and anything Companies House said in reply. The record deliberately holds no user identifier and no authentication code. - **Payment evidence** — Stripe provider reference, amount, currency, authorisation status, capture status, cancellation status, failure status, and webhook event ids. - **Provenance metadata** — the version of the Authority manifest in effect at the moment your filing was submitted. - **Operational telemetry and product analytics** — request logs, PostHog event data, a first-party interaction journal, and early-beta Codex/OpenAI monitoring evidence for service reliability, beta support, and understanding where users get stuck in the filing journey. ## 3. What we do not collect - We do not store card numbers, CVCs, or sensitive payment-method details. Stripe handles card entry and payment-method processing. - We do not hold per-user HMRC Gateway credentials in our database; transmission to HMRC uses Render Technologies Limited's own vendor credentials. - We do not store your company's own six-character Companies House authentication code. You type it for a single send to Companies House; it is passed straight through, and is never written to our database, our logs, your data export, or any analytics event. - We do not send exact tax-form values, UTRs, CT600 XML, iXBRL files, GovTalk envelopes, HMRC payload bodies, or payment details to PostHog session replay. Exact filing values remain in Render's own systems and submitted Filing Record. ## 4. Why we hold it — lawful bases Under UK GDPR Article 6 we rely on: - **Article 6(1)(b) — performance of a contract** — to hold your account, your draft, your submitted filings, and payment evidence needed to provide the paid filing service. - **Article 6(1)(a) — consent** — only for marketing emails, if we later ask you to opt into them separately. We do not rely on Article 6(1)(c) (legal obligation) — Render is a software supplier, not the legal record-holder for your tax returns. HMRC keeps its own copy of every submission, and your company is independently required to keep its own books. ## 5. How long we hold it We hold your account and draft data only for as long as you maintain an account with us. Submitted filing records and non-sensitive payment evidence are treated differently because they are evidence of what was submitted and charged. When you delete your account, your login, account row, memberships, and mutable drafts are deleted. Submitted filing evidence may still be retained to prove what was sent to HMRC and to handle audit, dispute, legal, payment, or record-keeping questions. Retained filing evidence can include generated CT600 XML, iXBRL accounts, iXBRL computation, GovTalk envelope, IRmark, timestamps, HMRC response evidence, Companies House send evidence, payment evidence, and authority-manifest provenance. ## 6. Who we share it with - **HMRC** — your CT600 + iXBRL accounts + iXBRL computation are transmitted to HMRC. - **Companies House** — two separate connections, and only the first happens automatically. *Reading:* public Data API lookups for company information, last-filed accounts, and the officer list used to check your directorship. *Sending:* if you choose to send your accounts to Companies House from your account page, we transmit the micro-entity accounts document, your company's name and number, the date the accounts were approved, and the company's own authentication code to the Companies House filing gateway. Those sends currently reach Companies House's **test** service only, so nothing sent through Render today reaches the public register. We will publish a new version of this policy before that changes. - **Stripe** — payment authorisation, capture, cancellation, and payment-status webhooks. - **Clerk** — authentication. - **Neon** — Postgres database hosting. - **Resend** — transactional email. - **Sentry** — production error monitoring with sensitive filing contents removed before events are sent. - **PostHog** — signed-in product analytics and, only when you switch on support replay, masked browser-session replay for support/debugging. We do not send raw CT600 XML, iXBRL files, GovTalk envelopes, HMRC payload bodies, cookies, authorisation headers, passwords, claim tokens, or payment details to PostHog event properties. - **OpenAI/Codex** — for early beta users, Render may ask an OpenAI-hosted Codex agent to review a short-lived signed evidence bundle for your filing journey. The bundle is generated from Render's own systems and can include account/session identifiers, form progress, validation and submission status, Interaction Journal rows, PostHog event/replay references, payment-status evidence, and safe error summaries so we can check whether the service is working as expected. Codex monitoring is for support, debugging, and safety checks, not advertising. Render also keeps a short-retention internal interaction journal during beta. It records structured facts such as which form field changed, whether it was empty, the broad value-length bucket, validation state, checkbox state, select/gate answer, save status, and submit/review blockers. It does not store raw sensitive field values unless the field is a checkbox, select/gate option, or support preference that is safe to record exactly. Exact filing values remain in Render's own systems and submitted Filing Record. During early beta, those first-party records may be included in the short-lived Codex evidence review where needed to check the filing journey, after you accept the current terms and privacy wording. Codex evidence links expire and are not public links. We do not sell your data. ## 7. Your rights Under UK GDPR you have the right to access, correct, erase, restrict, port, or object to processing of your data. Contact privacy@render.my. You can complain to the Information Commissioner's Office (ico.org.uk) about how we handle your data. ## 8. Cookies and tracking Render uses essential authentication cookies, strictly necessary Stripe payment-session cookies or redirects, and PostHog analytics for signed-in users who have accepted the current terms. Detailed support replay is off unless you switch it on in the form support panel, and replay inputs are masked. During early beta, Render may also generate short-lived Codex/OpenAI monitoring evidence to check the filing journey almost live. We do not use advertising cookies in this filing app. ## 9. Changes to this policy We will publish a new version of this policy here when we make material changes. The version number above moves on each change. ## 10. Contact Render Technologies Limited Company number: 17088258 Registered office: 39 Islingword Road, Brighton, BN2 9SF privacy@render.my Complaints about privacy can be sent to privacy@render.my. You also have the right to complain to the UK Information Commissioner's Office.