This agreement applies when an organisation buys ScienceShot Compliance, starting with the EED reporting pilot. It forms part of the contract made under our terms of sale and is accepted, in electronic form, at checkout. ScienceShot is a Swiss company, and its data protection law is the Swiss Federal Act on Data Protection of 25 September 2020 (FADP). Where the EU General Data Protection Regulation (Regulation (EU) 2016/679, “GDPR”) applies to the customer’s processing, this agreement also sets out the processor terms Article 28(3) GDPR requires. Version of 19 October 2026, revision 2.
1. Parties and roles
- Controller. The organisation that buys ScienceShot Compliance (the customer), acting through the member account that bought it and the named users it adds.
- Processor. ScienceShot, Rue de la Dole 02, 1203 Geneva, Switzerland, the publisher of scienceshot.com. Contact: [email protected].
ScienceShot is the processor for the records the customer enters in ScienceShot Compliance (Annex A). For the member accounts its users create, for billing and for support correspondence, ScienceShot is a separate controller under its privacy policy, and this agreement does not apply to them. The customer warrants that it has a lawful basis for the records it enters and informs its site leads and contributors that their name and work email are stored with each figure.
Switzerland holds an adequacy decision of the European Commission (Decision 2000/518/EC, confirmed in the Commission’s review of 15 January 2024), so personal data may flow from the customer in the EU to ScienceShot without further safeguards. Onward transfers by ScienceShot to its subprocessors are covered by the safeguards in Annex C.
2. Subject matter, duration, nature and purpose
- Subject matter. Coordination of the customer’s annual data-centre reporting under the Energy Efficiency Directive (Directive (EU) 2023/1791 and Delegated Regulation (EU) 2024/1364) and, for German sites, the Energieeffizienzgesetz.
- Duration. The term bought (30 days for the pilot, a year for an annual plan), then the retention period in Annex D. Processing ends with erasure under section 10.
- Nature. Collection of site figures through a form link per site and reporting year, storage, automatic checks, a dated and hashed snapshot at sign-off, an Excel export and a printable evidence summary, and reminder emails to site leads if the customer turns them on.
- Purpose. To let the customer collect, check, sign off and export the figures its sites must report. ScienceShot uses the records for nothing else: no benchmarking, no aggregation across customers, no training of models, no marketing and no sale.
3. Instructions
ScienceShot processes the records only on the customer’s documented instructions, including with regard to transfers outside Switzerland and the European Economic Area. The terms of sale, this agreement and the actions the customer’s users take in the application are those instructions. ScienceShot tells the customer at once if, in its opinion, an instruction breaches data protection law. If the law requires ScienceShot to process the records otherwise, ScienceShot informs the customer first, unless that law forbids it.
4. Confidentiality
Only ScienceShot’s administrators can reach the application’s systems, and each is bound to confidentiality before access. Administrators do not open a customer’s records in the application; they read them outside it only on the customer’s written support request, and the customer is told what was read and when. No contractor or other third party is given access to a customer’s records.
5. Security
ScienceShot keeps the technical and organisational measures in Annex B, which take into account the state of the art, the cost, and the nature, scope and purpose of the processing, as Article 32 GDPR requires. ScienceShot may improve them and will not lower the level of protection during the term.
6. Subprocessors
The customer gives general written authorisation to the subprocessors in Annex C. ScienceShot tells the customer by email at least 14 days before adding or replacing one, and the customer may object on reasonable data protection grounds within that period. If the objection cannot be resolved, the customer may end the contract and receives a refund of the unused part of the term. ScienceShot binds each subprocessor to data protection obligations equivalent to these and remains liable to the customer for their performance.
7. Assistance
Taking into account the nature of the processing and the information available to it, ScienceShot helps the customer answer data subject requests (section 8) and meet its obligations on security, breach notification, data protection impact assessments and prior consultation (Articles 32 to 36 GDPR). On request, ScienceShot gives the customer its own written screening of whether this processing needs an impact assessment. Help beyond the application’s own functions is charged at a reasonable rate agreed in advance, except where a breach or a failure of ScienceShot’s makes it necessary.
8. Data subject rights
The customer answers requests from its site leads, contributors and named users. The application gives it the means: the activity log, the history of each value, the Excel export with its Contributors sheet, and the erase function. ScienceShot passes any request it receives directly to the customer within five working days and does not answer it for the customer unless instructed in writing.
9. Personal data breaches
ScienceShot notifies the customer without undue delay, and in any case within 72 hours of becoming aware of a personal data breach affecting the records. The notice states, as far as known, the nature of the breach, the categories and approximate number of data subjects and records, the likely consequences, the measures taken or proposed, and a contact. What is not yet known follows in stages. ScienceShot documents every breach, its effects and the remedial action.
10. End of processing: return and deletion
At the end of the term the records stay readable and exportable, with writes closed, until the retention date in Annex D. At any time the customer may export everything through the Excel export, and its owner may erase the organisation, which deletes all its records in one step. If the customer has not erased the organisation by the retention date, ScienceShot erases it within 14 days after that date and confirms by email. Erasure leaves only a marker holding the organisation’s internal number, the time and the scope. After any restore from a backup, ScienceShot checks these markers and deletes again whatever the restore brought back before the service reopens. Backup copies are not deleted on a fixed schedule (Annex D). Until ScienceShot removes them they are held beyond use: encrypted, outside the hosting account, accessible only to ScienceShot’s administrators, used for nothing but restoring or testing the restore of the service, and still covered by this agreement. If one is ever restored, the erasure is applied again before the service reopens. Where the law requires ScienceShot to keep a record, ScienceShot tells the customer which and why.
11. Audits
ScienceShot makes available all information needed to demonstrate compliance with Article 28 GDPR, including written answers to a security questionnaire within 20 working days. The customer, or an independent auditor it mandates who is bound to confidentiality and is not a competitor of ScienceShot, may audit once a year, and after any breach, with 30 days’ written notice, in a way that does not expose other customers’ data. Each party bears its own costs.
12. Liability, term and law
Liability follows the terms of sale (section 7), without limiting what Article 82 GDPR imposes. This agreement lasts as long as ScienceShot holds the records. It is governed by Swiss law, and the courts of Geneva have jurisdiction, without prejudice to the data protection law that applies to the customer and to the competence of its supervisory authority. Where this agreement and the terms of sale differ on the processing of personal data, this agreement prevails.
Annex A. Description of the processing
| Data subjects | The customer’s named users (up to three member accounts); site leads; people who enter figures through a form link (the customer’s employees or contractors, including anyone a link was forwarded to); the manager who signs off. |
| Personal data | Name and work email of site leads and of each person who enters a figure, kept with that figure’s history, in the signed snapshot and in the export’s Contributors sheet; the signing user’s name; the account numbers of the users who confirm definitions, resolve checks or sign off; who did what and when in the activity log; the written reasons a manager gives on checks. |
| Other records | Site figures for the 32 EU items and the German additions (energy, water, floor areas, refrigerants, renewable energy and the rest), units, whether each is measured or estimated, definitions per site, checks, reporting years and dates, template order, organisation name. These are the customer’s business data. |
| Special categories | None. The application has no field for them. |
| Frequency | Continuous during the term. Reminder emails at most one per site every 3 to 14 days, only when the customer turns them on. |
| Location | The database of scienceshot.com at our host’s European datacentre (Annex C), and the encrypted backups in Annex B. A contributor’s name and email are also kept in their own browser so the form asks once per device. |
Annex B. Technical and organisational measures
- Tenant isolation. Every record carries its organisation, first in every key, and every child record is checked against its parent’s organisation. Each request resolves one organisation from the signed-in session and re-checks the user’s active membership; the organisation is never taken from the request itself. Our administrators cannot read a customer organisation’s records through the application; their access there is limited to test organisations.
- Roles. Owner (everything, including sign-off, form links, users and erasure) and member (edit, no sign-off), with at most three named users.
- Form links. Each link reaches one site and one reporting year. It is a random 32-byte token, shown once and stored only as a keyed hash, valid 90 days, revocable by the owner and closed at sign-off. The token travels in the part of the address after #, so it does not reach server logs, caches or other sites.
- Encryption in transit. HTTPS (TLS) on every page and request. Pages and responses carrying records are marked never to be cached, by the browser, our server or the network in front of it.
- Page protections. The application pages hold no records in their HTML, load no analytics, advertising or third-party script, cannot be framed, and send no referrer.
- Activity log. Every change writes a log entry in the same database transaction. The log names the user, the item and the time, never the submitted values, and the customer can read it.
- Backups. An encrypted copy of the database is taken off the host at least once a month and stored encrypted outside the host, with a restore test after each copy. The host also keeps its own backups.
- Erasure. On request, at the end of retention, or by the customer’s owner in one step; checked and rolled back as a whole if any part fails.
- Exports. Every export is logged, and refused if it cannot be logged. Text that could run as a spreadsheet formula is neutralised.
- Limits on use. Hourly rate limits on writes, exports and form links. Reminder emails carry the site name, the site lead’s name, the reporting year, the count of open items, the due date and a fresh link, never figures.
- Organisation. Credentials and keys are kept outside the code. Every code change runs the test suite, including the isolation tests, before it goes live.
What the service does not have, stated plainly: it runs on shared hosting, so there is no separate database per customer, no encryption of the live database beyond the host’s own measures, and no point-in-time recovery; access to the database through the hosting control panel is not shown in the customer’s activity log, and is governed by section 4.
Annex C. Subprocessors
| Subprocessor | What it does | Where | Safeguard |
|---|---|---|---|
| Namecheap, Inc. | Web hosting of scienceshot.com: the database holding the records, the web server, the host’s own backups, and the mail server that sends reminder emails | Namecheap’s European datacentre in Amsterdam, the Netherlands | Namecheap’s data processing terms; the EU standard contractual clauses for any access from the United States |
| Cloudflare, Inc. | Network in front of scienceshot.com: encrypts the connection and passes requests through without caching the records | Cloudflare’s global network | Cloudflare’s data processing addendum with the EU standard contractual clauses; EU-US Data Privacy Framework |
| Google LLC (Gmail) | The support mailbox, which receives the customer’s support and data protection correspondence; never the records themselves | Google’s datacentres in the EU and the United States | Google’s data processing terms; EU-US Data Privacy Framework |
Stripe processes the buyer’s name, email, company and payment details to sell ScienceShot Compliance, as the merchant of record. It receives none of the records and no site, contributor or site-lead data, and acts as an independent controller for payment data under its own terms. It is the payment provider named at checkout and on the receipt.
Annex D. Retention
| Data | Kept | Then |
|---|---|---|
| The organisation’s records: sites, values and their history, form links, checks, definitions, snapshots, reminder log, activity log | The term plus 90 days | Erased by the customer, or by ScienceShot on request within 30 days, or by ScienceShot within 14 days after the retention date, confirmed by email |
| Erasure marker (internal number, time, scope) | Indefinitely | Holds no personal data |
| Purchase record (payment reference, amount, credit) | Ten years, for accounting | Separated from the organisation at erasure |
| Backups | Our copies: kept encrypted outside the hosting account, with no fixed deletion date, and removed only on ScienceShot’s decision. The host’s own backups: the host’s rotation | Used only to restore the service or test the restore; after any restore, every erasure is applied again before the service reopens |
Questions about this agreement: [email protected]. See also the terms of sale, the refund policy and the privacy policy.