Greyframe Data Processing Agreement (Logstatus)

This Data Processing Agreement ("DPA") is entered into between Andreas Braa, sole proprietor (enkeltpersonforetak) trading as Greyframe ("Processor", "Greyframe", "we"), and the Customer named in the Terms of Service or order form to which this DPA is attached ("Controller", "Customer", "you"). This DPA applies to all processing of personal data carried out by the Processor on behalf of the Controller in connection with the Logstatus service and forms part of the Terms of Service between the Parties. In case of conflict between this DPA and the Terms, this DPA prevails as to data-protection matters.

1. Definitions

Capitalised terms not defined here have the meaning given in the Terms of Service or in the General Data Protection Regulation (EU) 2016/679 ("GDPR"). In particular: - "Personal Data" means personal data within Customer Data, as defined in the Terms of Service. - "Special-Category Data" means data described in Article 9(1) GDPR, including health data. - "Processing" means any operation performed on Personal Data within the meaning of Article 4(2) GDPR. - "Data Subject" means an identified or identifiable natural person whose Personal Data is processed. - "Subprocessor" means any third party engaged by the Processor to process Personal Data on the Controller's behalf. - "Supervisory Authority" means a competent authority under Article 51 GDPR; the Processor's lead authority is Datatilsynet (Norway). - "EU SCCs" means the Standard Contractual Clauses set out in Commission Implementing Decision (EU) 2021/914.

2. Subject matter, duration, and scope

2.1. Subject matter. The Processor processes Personal Data on the Controller's behalf for the purpose of providing the Logstatus service. 2.2. Duration. This DPA applies for as long as the Processor processes Personal Data for the Controller under the Terms of Service, and survives termination to the extent necessary for the return or deletion of Personal Data. 2.3. Nature and purpose. The nature and purpose of the processing, the categories of Data Subjects, and the categories of Personal Data are described in Annex 1.

3. Roles

3.1. The Controller is the controller and the Processor is the processor of Personal Data within the meaning of the GDPR. 3.2. The Controller is responsible for ensuring it has a lawful basis under Article 6 GDPR for all processing carried out via the Service and, where Special-Category Data is involved, a permitted condition under Article 9 GDPR. 3.3. The Controller is responsible for providing fair-processing information (Articles 13 and 14 GDPR) to Data Subjects whose Personal Data is processed via the Service, including crew, contractors, and members of the public whose data appears in submissions.

4. Processor's processing of Personal Data

4.1. Documented instructions. The Processor will process Personal Data only on the Controller's documented instructions, including with regard to transfers to a third country or an international organisation, unless required to do otherwise by a law to which the Processor is subject, in which case the Processor will inform the Controller before processing (unless that law prohibits notification on important grounds of public interest). 4.2. General instructions. The Controller's instructions for processing are set out in this DPA, the Terms of Service, the Service's standard configuration and features, and any documented instructions the Controller provides via the Service or in writing to the Processor. 4.3. Notice of conflict. The Processor will inform the Controller without undue delay if, in its opinion, an instruction infringes the GDPR or applicable EU or member-state data-protection law.

5. Confidentiality of personnel

The Processor will ensure that persons authorised to process Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality.

6. Security of processing

6.1. The Processor will implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, taking into account the state of the art, the costs of implementation, the nature, scope, context, and purposes of processing, and the risks of varying likelihood and severity to the rights and freedoms of natural persons. 6.2. The current technical and organisational measures are described in Annex 2. The Processor may update these measures over time, provided that the level of security is not materially degraded. 6.3. Special-Category Data. Because the Service is designed to record HSE incidents and may process Special-Category Data, the Processor's measures include encryption in transit and at rest, role-based access controls, audit logging of access, and restrictions on staff access to production environments.

7. Subprocessors

7.1. The Controller grants the Processor general authorisation to engage Subprocessors for the provision of the Service, subject to the requirements in this Section 7. 7.2. Current Subprocessors. The Processor's current Subprocessors are listed in Annex 3 and are published, with any updates, at logstatus.app/legal/subprocessors. 7.3. New or replacement Subprocessors. The Processor will give the Controller at least fourteen (14) days' prior written notice before engaging a new Subprocessor or replacing an existing one. Notice is given by email to the Controller's billing or designated notice contact and by updating the public Subprocessor list. 7.4. Objection. The Controller may object to a new Subprocessor on reasonable data-protection grounds within fourteen (14) days of notice. The Processor will work in good faith to address the objection. If the objection cannot be resolved, the Controller may terminate the affected subscription with a pro-rata refund of pre-paid fees for the unused portion of the term; that is the Controller's sole remedy. 7.5. Subprocessor contracts. Each Subprocessor is bound by written terms imposing data-protection obligations no less protective than those set out in this DPA, as required by Article 28(4) GDPR. 7.6. Liability for Subprocessors. The Processor remains liable to the Controller for the performance of its Subprocessors' obligations.

8. International transfers

8.1. The Processor stores Personal Data within the European Economic Area (EEA) where the underlying infrastructure supports a regional pin (see § 10 of the Terms of Service and Annex 3 of this DPA). 8.2. Where Personal Data is transferred outside the EEA to a Subprocessor, the Processor relies on the EU SCCs as incorporated in the relevant Subprocessor agreement, together with any supplementary measures required by applicable law and Court of Justice of the European Union case law. 8.3. The Processor's reliance on the EU SCCs as between itself and its Subprocessors does not, by itself, require execution of EU SCCs between the Processor and the Controller, both of whom are established in the EEA.

9. Data Subject rights

9.1. The Processor will, taking into account the nature of the processing, assist the Controller by appropriate technical and organisational measures, insofar as possible, for the fulfilment of the Controller's obligation to respond to requests by Data Subjects to exercise their rights under Chapter III of the GDPR. 9.2. The Processor will, without undue delay, forward to the Controller any Data Subject request received directly that relates to Personal Data processed under this DPA. The Processor will not respond to such requests on its own initiative, except to acknowledge receipt and direct the Data Subject to the Controller. 9.3. The Service provides in-product tools that enable the Controller to access, correct, export, and delete Personal Data without the Processor's intervention.

10. Assistance with controller's other obligations

The Processor will assist the Controller, taking into account the nature of the processing and the information available to it, in ensuring compliance with the obligations under Articles 32 to 36 of the GDPR, including: (a) implementing appropriate security measures (Article 32); (b) notifying Personal Data breaches to the Supervisory Authority (Article 33); (c) communicating Personal Data breaches to Data Subjects where required (Article 34); (d) conducting data protection impact assessments (Article 35); and (e) prior consultation with the Supervisory Authority where required (Article 36).

11. Personal Data breaches

11.1. The Processor will notify the Controller without undue delay, and in any event within seventy-two (72) hours, after becoming aware of a Personal Data breach affecting Personal Data processed under this DPA. 11.2. The notification will, to the extent then known, describe: (a) the nature of the breach, including the categories and approximate number of Data Subjects and records affected; (b) the name and contact details of the Processor's contact point for follow-up; (c) the likely consequences of the breach; and (d) the measures taken or proposed to address the breach, including measures to mitigate its possible adverse effects. 11.3. Where it is not possible to provide all information at once, the Processor may provide it in phases, in line with Article 33(4) GDPR. 11.4. The Processor will cooperate with the Controller in the Controller's notifications to its Supervisory Authority and, where required, to Data Subjects.

12. Audits

12.1. The Processor will make available to the Controller all information necessary to demonstrate compliance with the obligations laid down in Article 28 GDPR and this DPA. 12.2. The Processor's documented compliance — including this DPA, the Subprocessor list, security overview documents, and certifications (where held) — is the Processor's primary means of demonstrating compliance. The Controller may submit reasonable written questions about the Processor's compliance, to which the Processor will respond within thirty (30) days. 12.3. On-site audits. Where the Controller's documented audit obligations under applicable law cannot be satisfied by the means set out in § 12.2, the Processor will permit an audit conducted by the Controller or an independent auditor mandated by the Controller, subject to: (a) at least sixty (60) days' written notice; (b) audits occurring no more than once in any twelve-month period (or more frequently where required by a Supervisory Authority); (c) the auditor signing the Processor's reasonable confidentiality undertaking; (d) audits being conducted during normal business hours, in a manner that minimises disruption to the Processor's operations; (e) the Controller bearing its own costs, and reimbursing the Processor for reasonable costs incurred in supporting an audit, unless the audit identifies a material breach by the Processor, in which case the Processor bears its own costs. 12.4. Audit findings are Confidential Information of both Parties.

13. Return or deletion of Personal Data

13.1. Upon termination of the Service for any reason, the Processor will, at the Controller's choice, delete or return all Personal Data and delete existing copies, unless EU or Norwegian law requires storage of the Personal Data. 13.2. The Controller may export Personal Data using the in-product export tools at any time, including for thirty (30) days after termination. 13.3. After the export window closes, the Processor will delete Personal Data from production systems within thirty (30) days. Backup copies are deleted within ninety (90) days of the last backup containing the data, in line with the Processor's standard backup retention schedule. 13.4. Statutory retention by the Processor. The Processor may retain Personal Data to the extent required by Norwegian or EU law (for example, billing records under the Norwegian Bookkeeping Act). Such retained data continues to be subject to the confidentiality and security obligations of this DPA.

14. Liability

14.1. The Processor's liability under this DPA is subject to the limitations set out in the Terms of Service, except where mandatory law (including Articles 82 and 83 GDPR) requires otherwise. 14.2. Each Party is liable to Data Subjects in accordance with Article 82 GDPR. As between the Parties, liability is allocated in accordance with each Party's contribution to the damage.

15. Order of precedence and miscellaneous

15.1. Order of precedence. In case of conflict between this DPA and the Terms of Service or any other agreement between the Parties, this DPA prevails as to data-protection matters. 15.2. Variation. This DPA may only be varied in writing, signed by both Parties or by the Processor giving notice of a material update (see § 16 of the Terms of Service). 15.3. Governing law and jurisdiction. This DPA is governed by the laws of Norway. Disputes are subject to the jurisdiction of the Oslo District Court (Oslo tingrett).

Annex 1 — Description of processing

| | | | --- | --- | | Controller | The Customer (organisation) named in the Terms of Service or applicable order form | | Processor | Andreas Braa, sole proprietor (enkeltpersonforetak) trading as Greyframe; org.nr. [ORG.NR] | | Subject matter | Provision of the Logstatus incident, fault, HSE, and FOH submission and review service | | Nature and purpose of processing | Hosting, organising, storing, retrieving, displaying, and erasing Customer Data submitted via the Service, so that the Customer can record and review operational and incident information at its venues, tours, or events | | Categories of Data Subjects | (a) Authorised Users of the Customer (admins, operators); (b) Submitters (crew, contractors, others using soft-auth submission tokens); (c) Individuals named in submission content, including injured persons, members of the public, and other Data Subjects identified in incident descriptions or attachments | | Categories of Personal Data | (a) Account and authentication data: name, work email, role, authentication credentials (hashed), session metadata, IP address, audit-log entries; (b) Submission content: free-text descriptions, structured fields, timestamps, geolocation (where provided), attachments such as photos; (c) Special-Category Data under Article 9 GDPR, where submissions describe health, injury, or other special categories, processed only because the Service supports HSE recording | | Frequency of processing | Continuous, for the duration of the subscription | | Duration / retention | Per the Customer's plan: free tier 30 days; Solo Venue 12 months; Group, Tour, Festival 24 months; Extended Retention add-on up to 7 years; audit-log entries 12 months from event | | Recipients | Subprocessors listed in Annex 3 and at logstatus.app/legal/subprocessors | | Transfers outside the EEA | Some processing during the operation of the Service occurs across our infrastructure provider's global network; transfers are covered by EU SCCs as set out in § 8 |

Annex 2 — Technical and organisational measures

The Processor implements appropriate measures pursuant to Article 32 GDPR. A summary follows; the engineering record is maintained in docs/security-audit.md and is available to Customers on request. Encryption. TLS 1.2 or higher for all data in transit. At-rest encryption provided by the underlying infrastructure provider for database, object storage, and key-value storage. Access control. Role-based access within the application; least privilege. The Processor's personnel (currently a single individual) accesses production data only where strictly necessary and is bound by confidentiality. All sensitive admin actions are written to an immutable audit log. Authentication. Modern session-based authentication via a vetted authentication library; passwords hashed with current best-practice algorithms; session tokens stored in encrypted key-value storage with time-to-live limits. Bot and abuse protection. Cloudflare Turnstile on public submission endpoints; rate-limiting on authentication and submission endpoints. Network security. All public endpoints served over HTTPS. Strict transport security and content-security-policy headers applied (see docs/security-audit.md). Logical separation. Customer Data is logically separated by tenant identifier in the underlying database. Application-level controls enforce tenant boundaries. Vulnerability management. Dependencies pinned and reviewed; security advisories monitored; code reviewed before deploy. Backups. Database snapshots retained for ninety (90) days. Backups encrypted at rest. Deletion. Production data purged within thirty (30) days of customer termination or Data Subject erasure request, where applicable. Backups purged within ninety (90) days. Incident response. Documented breach response procedure with seventy-two-hour notification commitments. Maintained at ../entity/internal/breach-runbook.md. Sub-processor management. Subprocessors vetted for data-protection posture before engagement. Public Subprocessor list maintained; change-notification process per § 7. Personnel. Personnel authorised to process Personal Data are bound by confidentiality.

Annex 3 — Subprocessors

The current Subprocessors are listed and kept current at logstatus.app/legal/subprocessors. As of 2026-05-17, the principal Subprocessors processing Customer Data are: - Cloudflare, Inc. — application hosting, primary database, object storage, key-value, queues, transactional email, bot protection. Storage pinned to EU regions where supported. Transfer mechanism: Cloudflare DPA + EU SCCs. - Stripe Payments Europe, Limited — payment processing, billing, invoicing. Does not process Customer Data submitted into Logstatus; processes billing-contact Personal Data only. Transfer mechanism: Stripe DPA + EU SCCs. Subprocessors processing only the Processor's own controller data (for example, error monitoring) are listed on the public Subprocessor page but do not appear here.

Annex 4 — Standard Contractual Clauses

Where Personal Data is transferred outside the EEA to a Subprocessor, the Processor and the relevant Subprocessor have entered into the EU SCCs (Commission Implementing Decision (EU) 2021/914), Module 3 (processor-to-processor) where the Subprocessor acts as a sub-processor on the Processor's behalf, or Module 2 (controller-to-processor) where the Subprocessor processes the Processor's own controller data. Copies of the relevant SCCs, with the Annexes completed, are available to the Controller on written request. If at any point a Controller is established outside the EEA and EU SCCs are required between the Controller and the Processor, the Parties will enter into Module 2 (controller-to-processor) on the standard terms set out in Decision (EU) 2021/914.

Changelog

- v0.1 — 2026-05-17. Initial draft, pre-launch.

Drafting notes (delete before publishing)

- Module choice. The EU SCCs have four modules; the most relevant for Logstatus are Module 2 (where a non-EEA controller signs with us as processor) and Module 3 (where we engage a non-EEA subprocessor). Annex 4 anticipates both. For Norwegian-and-EEA-only customer mix in year one, neither is needed at the Customer ↔ Processor level — but it has to be there for when a UK or US customer signs. - Audit clause (§ 12). I went with the "Standard SaaS" audit posture: written documentation as primary, on-site audits permitted under reasonable conditions. Some Enterprise customers will push for "SOC 2 report in lieu of audit" — when you have a SOC 2 you can update this. Until then, the structure is defensible. - Annex 1. The categories of Data Subjects explicitly include "individuals named in submission content" — this is the bystander problem (a crew member writes "Marie from Bar 2 saw it happen"). Important to be explicit because it's GDPR-relevant and not obvious from looking at the product. - § 13.4 statutory retention. Carve-out for Norwegian Bookkeeping Act retention of invoices etc. Without this, you'd technically be obligated to delete billing records on termination — which conflicts with mandatory law. - Sentry not listed in Annex 3. Because Sentry, if activated, processes only Processor controller data (error telemetry), not Customer Data. The Privacy Policy and public Subprocessor list cover it; the DPA Annex doesn't need to. - Lawyer review priority. Of all the customer-facing documents, this is the second-highest stakes after the Terms. A Norwegian tech lawyer should review both as a pair, and ideally check that the order-of-precedence and audit-clause structures are consistent with what enterprise procurement teams in Norway typically demand. - The audit cost-recovery wording (§ 12.3(e)) is fairly aggressive in the Processor's favour. Some Customers will push back; the fallback position is "audit costs are split equally unless audit identifies material breach." Don't volunteer the fallback in the draft.