Data Processing Agreement

Read this first — an honest note

The short version, for a vendor questionnaire

• For the files you upload to BIMMER Cloud — your SAT, your IES and the .rfa we deliver — we are your processor. That is what this agreement covers.
• For your account, your team invites, trial and abuse accounting, billing and support, we are an independent controller, not your processor. See clause 2. Do not put those in a processor schedule; we could not perform the obligations if you did.
• One sub-processor sees your file content outside the UK/EEA: Autodesk, in the United States. See clause 12.
• On the Founding Edition desktop app there is no processor relationship at all — your files never reach us. A desktop-only customer does not need this agreement.

1. The parties, and how this agreement is accepted

Who we are

You are the company that holds the BIMMER Cloud workspace — the legal entity named at checkout, or named in the signature block below if we countersign. Where your workspace has several members, the company is the controller; the individual seat holders are not.

Two ways this becomes binding — pick either

• Automatically. These terms form part of your contract with us and apply from the moment you first upload a file to BIMMER Cloud while signed in — no signature needed, no email needed. If you never ask us for anything, you are already covered by this version.
• Countersigned. If your procurement process needs a signed document, print this page, fill in the signature block, and email it to admin@bimmer.lighting. We will countersign and return it, normally within one business day. Our side is pre-signed below, so a returned copy is a complete executed agreement.

When it starts and when it ends

It takes effect on the earlier of: the date we countersign a copy for you, and the date you first upload a file to BIMMER Cloud. It runs for as long as we hold any file of yours — which, because your library is not cleared on a schedule, means until you delete those files or delete your account. The obligations that need to outlive it (confidentiality, and the deletion duty in clause 10) do.

What it does not cover

It does not cover BIMMER Desktop (Founding Edition). The desktop app converts through your own Autodesk account: your geometry and photometry go from your machine to Autodesk and never reach BIMMER's servers at all. There is no upload to us, no library and no cache. We are therefore not your processor for anything on the desktop edition — the only personal data we hold is the licence record itself, and for that we are a controller (see clause 2). If your files must never leave your own vendor perimeter, the desktop edition is the honest answer.

2. Where we are your processor, and where we are a controller in our own right

Most DPAs assume the split runs along an "our data / your data" line. For BIMMER it does not, and getting this wrong causes real problems later — so here it is plainly.

We are your processor for exactly one thing

The content of the files you upload through the cloud converter, and what we derive from them: the .sat you upload, the .ies you upload, the .rfa we deliver, the file names you gave them, the identity overrides you type, and the photometric metadata we read out of your IES and store alongside the entry. We act on your instruction, we use it for nothing else, we never share it and we do not use it to train anything.

We are an independent controller for these

• Account data — the seat holder's email address, name, password hash, Google sign-in id, Stripe customer id, whether the address is verified, and when the account was created. We decide to run an account system at all, we set the 30-day session lifetime and the verification flow. The fact that the account holder works for you does not make us your processor for their account.
• Trial and anti-abuse accounting — the IP address a trial conversion came from, a one-way hash of browser characteristics, and a count of how many accounts on the same company email domain have taken a trial. This is our own fraud-prevention and fair-use purpose (legitimate interest). You do not instruct it and cannot switch it off.
• Team seats — when you invite a colleague, you decide whom to invite; we decide the token scheme, what the invitation email says, and the fact that your colleague becomes an account holder with us in their own right. That is a controller-to-controller disclosure, not processing on your behalf. Team data is deliberately not in Annex A.
• Founding Edition licence records — company name, contact email, edition, seat number, app version, and a one-way hash of each activated machine.
• Billing data and support correspondence — including anything you send us by email.

How we handle all of that as controller is set out in the privacy policy, which is the correct instrument for it. Article 28 does not apply to it, and we will not sign a schedule that says otherwise — not to be difficult, but because we could not perform it. We cannot, for example, delete an account holder's record "on your instruction" while that person still holds a working login with us.

3. What we process, why, and for how long

The full detail is in Annex A, which is part of this agreement. In summary: we convert luminaire geometry (ACIS .sat) and photometry (IES LM-63) into Revit lighting-fixture families (.rfa), we run automated validation gates over the result, and we keep the uploaded files and the delivered family in your private product library until you delete them.

The awkward, honest part about CAD files

In the ordinary case the files you upload contain no personal data at all. A solid model of a downlight and a candela distribution do not relate to an identifiable person. If that were reliably true of every upload, Article 28 would not be engaged and you would not need this agreement.

It is not reliably true. IES LM-63 headers carry free-text keywords — [TEST], [TESTLAB], [ISSUEDATE], [MANUFAC], [OTHER] — that routinely name a test engineer or a lab contact. SAT headers carry author and product strings. File names carry people's names constantly. And the identity overrides are free text you type.

Our pipeline is byte-transparent by design: we store your SAT and IES exactly as you gave them to us, and we store the file names verbatim. That is deliberate — it is what makes re-issue and reproducibility work — but it means we cannot tell in advance whether a given upload contains personal data, and we cannot strip it out. UK GDPR has no exemption for small amounts of incidental personal data, or for data the recipient never looks at.

So we do the only defensible thing: we run every file, for every customer, as if personal data may be present. That is why Annex A describes the data as an open-ended category rather than a tidy list, and it is why we will not tell your questionnaire that we process none of your personal data.

4. We act only on your instructions

• We process your files only to provide BIMMER Cloud to you, and only on your documented instructions. Your instructions are: this agreement, the terms of service, and the things you actually do in the product — uploading a file, converting it, re-issuing it, moving it, downloading it, deleting it, deleting your account. Anything else you want instructed, put it in an email to admin@bimmer.lighting and we will confirm in writing whether we can do it and what it costs.
• We do not use your files for any purpose of our own. Not product analytics, not benchmarking, not a shared parts library, and not training any model.
• We do not sell, rent or disclose your files to anyone, other than the sub-processors in Annex B doing the job you asked for.
• If the law requires us to process your data in some other way, we will tell you before we do it — unless the law that requires it also forbids us from telling you, in which case we will tell you as soon as we lawfully can.
• We will tell you if we think an instruction is unlawful. If an instruction from you appears to breach UK GDPR or other data protection law, we will say so, in writing, and we may pause that instruction until it is resolved. We are not your legal adviser and this is not a warranty that we will spot it.

5. Confidentiality of the people who can reach your data

• Access to the production systems that hold your files is limited to Orienjo Ltd personnel who need it to run and support the service. Orienjo Ltd is a small company and that is a very short list.
• Orienjo Ltd undertakes that anyone it gives such access to — employee or contractor — is placed under a written duty of confidentiality covering your files and everything in them, continuing after their engagement ends, before that access is granted. Today that list is the founder alone, who is bound by this agreement directly.
• We do not routinely open, view or inspect the contents of your library. We would look at a specific file only where you ask us to (a support request about a conversion), or where we must to fix a fault or meet a legal obligation.
• No contractor, agency or outsourced support desk has access. If that ever changes, they become a sub-processor and clause 7 applies to them.

6. Security

We keep appropriate technical and organisational measures in place to protect your files, taking into account the state of the art, the cost, and the risk. The measures we actually run today are listed in Annex C — they are the same ones described in Security & data, written out clause by clause rather than in marketing prose. Annex C is part of this agreement.

We may change a measure, but not in a way that materially reduces the overall level of protection. Where a change is material we will update Annex C and the date on this page.

What we do not have, said plainly: BIMMER holds no ISO 27001 and no SOC 2 certification, and we have no penetration-test report to hand you. We would rather tell you that up front than imply otherwise. What we can show you is exactly what Annex C says: where your files sit, who can reach them, and a delete button that really deletes.

7. Sub-processors

• You give us general authorisation to engage the sub-processors listed in Annex B, and to replace or add to them on the notice below. The service cannot run without them: there is no version of BIMMER Cloud with no cloud engine and no storage.
• Before we add or replace any sub-processor that can access your file content, we will email account holders at least 30 days beforehand. That is the whole of Annex B section 1 — Autodesk, AWS and Heroku. The rest of Annex B cannot reach your files.
• You can object. Reply within those 30 days with your reasons. We will try to find a way round it. If we cannot, you may cancel, and your plan then runs to the end of the period you have already paid for on the ordinary cancellation rules in the terms of service — this agreement does not create a refund right the terms do not give. That is the remedy: we cannot give one customer a different sub-processor stack. If a change of sub-processor is a genuine blocker for you, tell us before it takes effect and we will talk about it rather than let it be a surprise.
• Every sub-processor in Annex B section 1 is engaged under its own published data processing addendum, which we accept as part of taking the service and which binds it to obligations equivalent to those in this agreement. That addendum is the instrument; we do not negotiate bespoke data terms with companies of that size, and we would rather tell you that than imply otherwise. Ask us and we will point you at the exact version of each one that applies.
• We stay responsible to you for what our sub-processors do with your files, to the same extent as if we had done it ourselves. Where Annex B marks a company as an independent controller rather than our sub-processor, that responsibility does not apply — because their processing is not on our behalf, and is not covered by this agreement.
• Ask us and we will send you the sub-processor contracts we rely on — see clause 11.

8. Helping you answer people who ask about their data

• If someone contacts us asking to see, correct, delete, restrict or port personal data that turns out to be in your files, we will not answer the substance ourselves. We will tell them to contact you, and tell you within 5 business days.
• If you get such a request and need our help, email admin@bimmer.lighting. Taking into account the nature of our processing, we will help you with appropriate technical and organisational measures, at no charge for a reasonable volume of requests.
• In practice you will rarely need us. The seat holder can already do it themselves, without a ticket: Library → delete an entry removes the record and the stored files, and Account → Delete account erases every library entry, every stored SAT, IES and .rfa, and the account, immediately and permanently.
• What we cannot do is search inside your files for a person's name. We do not index file contents, and CAD and photometric formats are not searchable that way. If you need to find every file mentioning an individual, you will need to work from your own records of what you uploaded — we will give you the list of entries and file names to work from.

9. Security breaches, impact assessments and the regulator

If something goes wrong

If we become aware of a personal data breach affecting your files, we will notify you without undue delay, and in any event within 72 hours of becoming aware of it, by email to your account holders and to any security contact you have given us. We will tell you what happened, which data was involved, what we have done, what we are still doing, and what you should do. We will keep you updated as we learn more.

We would rather send you an early, incomplete notice than a late, tidy one. Notifying the ICO within the 72-hour window under Article 33 is your obligation as controller, not ours; we will give you what you need to do it, and we will notify the regulator ourselves where the law separately requires us to.

Impact assessments and prior consultation

If you have to carry out a data protection impact assessment, or consult the ICO before processing, we will give you the information about BIMMER that you need — again taking into account the nature of our processing and what we actually know. Most of it is already on this page and in Security & data. Ask us for the rest.

10. Getting your data back, and deleting it at the end

• Export, any time. Everything we hold for you is downloadable from your signed-in account, in its original format — the SAT and IES you uploaded, byte for byte, and the .rfa we delivered. There is nothing to request and no export fee.
• Deletion is self-service, immediate and cascading. Deleting a library entry removes the record at once and deletes the stored objects. Deleting your account removes every library entry, every stored file, your folders, your workspace and the account record itself. It cannot be undone. You do not have to raise a ticket to get your data off our systems — most vendors promise this and implement a queue.
• One deduplication caveat, stated honestly. Identical bytes are stored once. If the same SAT backs two library entries and you delete one, those bytes survive until the last entry referencing them is deleted too. Delete the account and all of it goes.
• At the end of the service, and at your choice, we will return or delete your files. If you do nothing, your library is not deleted just because a plan ends — you keep sign-in access to browse and download it, and only new conversions stop. Tell us to delete and we will, within 30 days, and confirm in writing.
• What survives deletion, and why. Invoices stay in Stripe, because we are required to keep records of sale. Ordinary server logs and email records may hold a file name or an account email for a short period before rotating. A Founding Edition desktop licence is untouched, because it lives on its own permanent page and not on a BIMMER account.
• We keep no backups of the library files themselves. Deleting an object in S3 removes it; there is no second copy of your SAT, IES or .rfa to hunt down afterwards. Our database is a different matter, and we would rather say so: it is hosted Postgres with the provider's automatic backups, and it holds the things around your files — the file names you uploaded, the identity values you typed, and the photometry we read out of the IES. A deletion takes effect in the live database at once, but a copy can survive in a provider backup until that backup ages out on the provider's own cycle. No such backup is ever restored except to recover the service from failure. Working copies made during a conversion — in our server's temporary folder, and in Autodesk's staging storage — are not records we keep: the server copy lives in storage that is never backed up and is discarded when the server restarts or redeploys, and the Autodesk staging bucket uses Autodesk's transient policy, which purges objects automatically. This cuts both ways, and you should know it: if you delete something, it is gone, and we cannot restore it for you.

11. Information and audit

• We will give you the information you need to show that we are meeting our obligations under this agreement. Email admin@bimmer.lighting; we aim to answer a written security questionnaire within 30 days, and a human writes the answers.
• On request we will send you the data processing terms we have accepted from each sub-processor in Annex B section 1, and confirm which transfer safeguard applies to each.
• You may audit us, or appoint an independent auditor to, once in any 12-month period, on 30 days' written notice, during UK business hours, without unreasonable disruption, and under confidentiality. You may audit more often if a regulator requires it, or after a confirmed breach affecting your data.
• An audit covers this agreement and the systems that hold your files. It does not extend to another customer's data, to our commercial information, or to our sub-processors' own premises — for those, we will pass on what they give us.
• The first questionnaire response each year is free. Beyond that we may charge our reasonable time for on-site or repeated audits, and we will agree the figure with you before starting.
• Being straight with you: there is no certification report to substitute for this. We have no ISO 27001 and no SOC 2 — see clause 6.

12. Sending data outside the UK

The one that matters: Autodesk, in the United States

BIMMER Cloud converts your files using Autodesk's Design Automation service, which runs in the United States. On every cloud conversion your SAT and IES are staged in Autodesk's object storage and read by the Revit engine there, and the finished .rfa comes back. This is a restricted transfer of your data out of the UK, and it happens every time. It is not occasional and we do not rely on a derogation for it.

What limits the exposure: the staging bucket is created under Autodesk's transient policy, so Autodesk purges those copies automatically; the signed URLs used to hand files to and from the engine are short-lived; and the finished family comes back to your library in Ireland. Your library at rest is never in the United States.

The safeguard. We rely on Autodesk's own data processing terms and the Article 46 safeguard provided under them — either the UK Extension to the EU–US Data Privacy Framework, where the receiving Autodesk entity is certified for it, or the EU Standard Contractual Clauses with the ICO's UK International Data Transfer Addendum. Email admin@bimmer.lighting and we will confirm in writing which mechanism is in force for your contract and send you a copy — we would rather state the current position on request than print a claim on a web page that quietly goes stale.

The legs that stay in the UK and EEA

• Your library at rest is in a private Amazon S3 bucket in eu-west-1 (Ireland).
• The metadata around it — entry names, folders, sizes, file names, validation results — is in our Heroku Postgres database, EU region (Ireland).

Both are transfers from the UK to the EEA, which UK adequacy regulations cover — no Addendum is needed for the transfer itself. The residual point, which a thorough reviewer will raise before we do: both providers have US parent companies whose staff may access systems for support, and both cover that in their own DPAs with SCCs plus the UK Addendum.

The rest

Stripe (billing), Google (sign-in, only if the seat holder chooses that button), Resend (account email) and Cloudflare (DNS only) are covered in Annex B with their locations and roles. None of them can reach your file content. Stripe and Google are independent controllers, not our sub-processors, so their transfers are governed by their own terms with you and with them, not by this agreement.

If the US leg is a blocker

If your policy will not permit the Autodesk transfer at all, say so early and do not sign this. BIMMER Desktop (Founding Edition) is a genuinely different data flow, not a workaround: the app runs on your machine against your own Autodesk account, so your files reach Autodesk under your own agreement with Autodesk and never touch our servers. Email jiq@bimmer.lighting.

13. General

Which document wins

On anything about processing personal data, this agreement takes precedence over the terms of service. On everything else — credits, plans, refunds, liability, acceptable use — the terms of service govern. If we have separately signed your own DPA, that one wins over this page for the customer it names.

Liability

Each party's liability under this agreement is subject to the limits and exclusions in the terms of service, which cap Orienjo Ltd's total liability at the amount you paid us in the 12 months before the claim. Nothing here limits any liability that cannot lawfully be limited, and nothing here limits a data subject's rights or a regulator's powers against either of us.

Changes to this agreement

We may publish a new version. Where a change materially reduces your protections we will email account holders before it takes effect, and if you do not accept it you may terminate the affected part of the service. The version number and date at the top of this page change with every revision. If we have countersigned a copy for you, that copy stays in force until you and we agree a new one.

Law and jurisdiction

This agreement is governed by the law of England and Wales, and the courts of England and Wales have exclusive jurisdiction. "UK GDPR", "controller", "processor", "personal data", "processing", "personal data breach" and "data subject" have the meanings given in the UK GDPR and the Data Protection Act 2018.

Severability

If any part of this agreement is held unenforceable, the rest continues in force.

Signature

Our side is already signed. If you need a countersigned copy, fill in your side, email the page to admin@bimmer.lighting, and we will return it executed — normally within one business day. If you would rather not sign anything, you do not have to: see clause 1.

Annex A — the processing, in detail

Required by Article 28(3) UK GDPR. This annex covers only the processing where we are your processor. It deliberately does not cover account data, team invites, trial and abuse accounting, licence records, billing or support — for those we are a controller, and the privacy policy is the right document. See clause 2.

Subject matter

Conversion of customer-supplied luminaire CAD geometry (ACIS .sat) and photometry (IES LM-63 .ies) into Revit lighting-fixture families (.rfa), and the hosted storage of those files in the customer's private product library.

Duration

From your first upload until you delete the files or delete your account, plus up to 30 days to complete deletion if you instruct it at the end of the service. We do not clear libraries on a schedule, and ending a plan does not delete anything.

Nature of the processing

• Receiving your uploaded files over HTTPS.
• Holding a short-lived working copy on our server while the job runs.
• Staging the files with Autodesk and having Autodesk's Design Automation service run the Revit engine over them in the United States.
• Reading photometric values out of your IES and running automated validation gates over the produced family.
• Returning the family to you, and storing the SAT, the IES, the .rfa and the entry's metadata in your private library.
• Serving your own downloads, re-issues, renames, moves and deletions on your instruction.
• Deleting on your instruction — an entry at a time, or the whole account.

Purpose

Providing the BIMMER Cloud service to you, and nothing else. Not analytics, not benchmarking, not a shared parts library, and not training any model.

Types of personal data

This is deliberately an open-ended category, because we cannot inspect your files to narrow it and we will not pretend otherwise:

• Any personal data incidentally contained in customer-supplied CAD geometry, photometric files, their file names, and the metadata inside them.

In practice that means, non-exhaustively:

• Names, job titles, email addresses or phone numbers appearing in IES LM-63 header keywords — [TEST], [TESTLAB], [ISSUEDATE], [MANUFAC], [OTHER] — typically identifying a test engineer or a lab contact.
• Author, operator or contact strings embedded in SAT headers by the CAD tool that wrote them.
• People's names carried in the file names you upload, which we store verbatim and indefinitely alongside the entry.
• Any personal data you type into the Revit identity overrides — for example a designer's or approver's name in a family parameter.

We do not seek this data, we do not index it, we do not look at it, and we cannot remove it. In most uploads there is none. Please do not upload special category data or criminal offence data (Articles 9 and 10) — BIMMER is not designed for it and we would not know it was there.

Categories of data subject

• Your employees and contractors, where they are named in a file you upload or in its name.
• Third parties named in files you upload — most often test-laboratory staff, photometric test engineers, and manufacturer or supplier contacts.
• Anyone else you choose to put in a file name, a header or an identity override.

Note that the account holders themselves are not in this list. We hold their data as a controller, not on your behalf.

Obligations and rights of the controller

Yours are set out in UK GDPR and in this agreement. In short: you decide what to upload, you confirm you are entitled to convert it, and you are responsible for having a lawful basis for any personal data that travels inside it.

Annex B — sub-processors

Current as at 26 July 2026. We will email account holders at least 30 days before adding or replacing anything in section 1.

1. Sub-processors that can access your file content

2. Everything else — none of these can reach your files

Our privacy policy groups all of these under the everyday heading "processors we use". This annex is the accurate legal classification, and where the two differ this annex governs. Stripe and Google determine their own purposes for the processing above — payment services and their own anti-fraud and regulatory duties in Stripe's case, account and authentication services in Google's — which makes them independent controllers rather than our sub-processors, and means we are not answerable under Article 28(4) for their own processing.

3. Named here so you do not have to ask

• GoDaddy is our domain registrar. It holds the domain registration record, which is Orienjo Ltd's own corporate data. It is not a sub-processor of anything of yours.
• Render appears in our deployment documentation as a fallback hosting option. It is not in use, holds nothing, and is not a sub-processor. If we ever move to it, clause 7's 30-day notice applies first.
• We use no analytics, advertising or tracking provider at all — there is no Google Analytics, no tag manager and no cross-site tracking on bimmer.lighting.

Annex C — technical and organisational measures

These are the measures actually in place, not a template. They are the same ones described in Security & data.

Encryption

• In transit: everything to and from bimmer.lighting runs over HTTPS/TLS, and so does every hop we make onward — to AWS, to Autodesk, to Stripe and to our mail provider.
• At rest: library objects are encrypted by S3's server-side encryption (AES-256).
• Passwords are stored as salted scrypt hashes. We cannot read them, and no reset ever reveals one.
• Card details never reach us at all — Stripe holds them.

Access control

• Every library route checks the signed-in session and that the file belongs to that user. There is no route that returns another user's object.
• Downloads are served as pre-signed links to one specific object that expire after five minutes. There are no public or long-lived file URLs.
• The S3 bucket allows no public or anonymous access.
• The credentials our server holds for that bucket are scoped to putting, getting and deleting objects in that one bucket — nothing else in the AWS account.
• The session cookie is httpOnly, SameSite=Lax and Secure. Sessions are held server-side, last 30 days, and can be revoked.
• Repeated failed sign-ins are rate-limited and temporarily blocked; conversions are throttled against bulk abuse.

Separation of customers

• Stored objects are content-addressed under a per-user key prefix, so one customer's objects are namespaced away from another's and deduplication never crosses accounts.
• A product library belongs to the person who converted, not to the workspace. Teammates on a plan share credits, not each other's files.

Handling of working copies

• While a conversion runs, your files also exist as short-lived working copies — in a temporary folder on our server, and in Autodesk's staging storage so the Revit engine can read them.
• The server copy lives in temporary storage that is never backed up and is discarded whenever the server restarts or redeploys.
• The Autodesk staging bucket is created under Autodesk's transient policy, which purges objects automatically. The signed URLs used to hand files to and from the engine are short-lived.
• A conversion that fails, or one your library cannot take because storage is full, leaves nothing behind.

Deletion

• Deletion is self-service and immediate. Deleting an entry removes the database record and deletes the stored objects; deleting an account cascades through every library entry, folder, workspace and session and removes the stored objects too.
• There is no separate backup copy of library files to recover from — which is a real limitation as well as a privacy property. See clause 10.

Use limitation

• Your files are used only to run the job you asked for and to serve them back to you. They are not shared, not sold, and not used to train anything.
• We set essential cookies only — a session cookie and a short-lived state cookie during Google sign-in. No analytics, no advertising, no cross-site tracking.

Organisational

• Access to production systems is limited to Orienjo Ltd personnel who need it — today, the founder alone. Anyone added is placed under a written duty of confidentiality surviving the end of their engagement before access is granted (clause 5).
• Orienjo Ltd is registered with the ICO (registration ZB532168) and pays the data-protection fee.
• Breaches are notified to affected account holders by email without undue delay — see clause 9.
• We accept vulnerability reports at admin@bimmer.lighting and will not pursue researchers who report privately and give us a reasonable chance to fix. There is no bug bounty.

Measures we do not have

• No ISO 27001 and no SOC 2 certification, and no third-party penetration test report.
• No separate security team, no 24/7 SOC, and no formal on-call rota. Orienjo Ltd is a small UK company; we would rather you knew that before you signed than after an incident.
• No customer-managed encryption keys, no data residency choice for the conversion engine, and no single sign-on integration.
• If any of those is a hard requirement for you, tell us before you buy — and consider BIMMER Desktop, where your files never reach us at all.