Data processing agreement for Inxo

This is a draft. It is not ready for signature, and it binds no one until agreed and signed.

1 What this document is

1.1

This is the data processing agreement between the organisation using Inxo (the controller) and CIRON AS, company no. 922 148 759 (the processor). It satisfies Article 28(3) of the General Data Protection Regulation, which requires processing on behalf of another to be governed by a binding contract.

1.2

The agreement applies alongside the terms of use and the privacy notice. In the event of conflict, this agreement prevails for the processing of personal data.

1.3 A self-service trial account has a click-accepted trial agreement, not this one.

The full data processing agreement applies from signature. Which agreement applies to you is always shown in the app under Organisation. This is not a formality: a trial agreement does not bind CIRON to the annexes here.

1.4 The Norwegian text is authoritative.

This English version is a translation. In the event of conflict, the Norwegian text prevails.

2 The Commission's standard contractual clauses

2.1

The general part of this agreement is Commission Implementing Decision (EU) 2021/915 of 4 June 2021 on standard contractual clauses between controllers and processors under Article 28(7) GDPR. The clauses were incorporated into the EEA Agreement by EEA Joint Committee Decision No 336/2022 of 9 December 2022.

2.2 The clauses are reproduced unchanged.

Clause 2 of the Decision prohibits modifying them; only the annexes are completed. They have therefore not been rewritten here. The signed agreement contains the clauses in the official wording from the Official Journal of the European Union (OJ L 199, 7.6.2021, p. 18), together with the annexes in chapters 3 to 10.

2.3 Why we have not written our own.

The standard clauses carry a presumption of compliance with Article 28(3) and (4). A bespoke agreement has to be defended clause by clause in every customer review, and a customer with its own legal function will compare it with these anyway. We would rather spend the time on the annexes, which is where anything is actually said about this particular service.

2.4 The elections made in the clauses

Clause	CIRON's election
Clause 5 — docking clause	Used. Affiliates of the customer may accede by completing and signing Annex I
Clause 7.7 — sub-processors	Option 2: general written authorisation of the list in Annex IV, with changes notified under 6.3
Clause 9 — breach notification	See Annex VI. The deadlines there are shorter than the Regulation's "without undue delay"

2.5

The annexes in this document are numbered as in the Decision, so that an auditor can read them side by side without translating between two numbering schemes.

3 Annex I — The parties

3.1 Processor

CIRON AS, company number 922 148 759, Norway. Contact point for all matters under this agreement: contact@ciron.no.

3.2 Controller

The organisation named in the signed agreement, at the contact point given there.

3.3 Docking

Affiliates of the controller may accede under Clause 5 by completing and signing this annex. Acceding does not change Annexes II to VIII.

3.4 Data protection officer

CIRON AS is not required to appoint a data protection officer under Article 37. Data protection enquiries go to contact@ciron.no and are answered by the person responsible for data protection at CIRON.

4 Annex II — The processing

4.1 Subject matter

Provision of Inxo, a tool for preparedness work: plans, exercises, incident response, notification deadlines and logging.

4.2 Duration

The processing lasts as long as the service agreement runs, subject to the deadlines in Annex VII on termination and retrieval.

4.3 Nature and purpose

CIRON processes personal data solely to provide, operate, secure and troubleshoot the service on the controller's documented instructions. The data are never used to train models, for marketing, for profiling, or for analysis across customers.

4.4 Categories of data subjects

Employees and contractors of the controller who are given access to the tool
People named in the controller's own plans, for example in a role or a contact list
People mentioned in a log entry or in an incident the controller records

4.5 Types of personal data

Category	What	Source
Identity	Name, and the person's role in the preparedness organisation	The controller
Credentials	Passkey credentials: public key, credential id, counter, device type	The user's own device
Activity	Who did what, when, in the organisation's own log	Use of the service
Sessions	Digests of active sessions per device, so access can be revoked	Use of the service
Content	What the controller enters: plans, exercises, incidents, log	The controller
Billing	Billing contact details, where the organisation provides them	The controller

CIRON collects no email address at registration, and the service sends no email. There is no code that could.

4.6 Special categories

The service is not built for special categories of personal data under Article 9, nor for data on criminal convictions under Article 10. The controller shall not enter such data into the tool.

Attachments are off by default. Turning them on happens per organisation, after a data protection impact assessment by the controller. That switch is what makes 4.6 more than an exhortation.

4.7 Classified information

The service is not approved for information classified under the Norwegian Security Act, and shall not be used for it.

4.8 Processing by sub-processors

The subject matter, nature and duration of the processing carried out by each sub-processor are set out in Annex IV.

5 Annex III — Technical and organisational measures

5.1

The measures are described concretely, not as a list of good intentions. That is a requirement: EDPB Guidelines 07/2020 state that the contract must give "more specific, concrete information as to how the requirements will be met and which level of security is required", and the explanatory note to Annex III of the Decision requires the same.

5.2 Isolation between organisations

Measure	How
Own address	Each organisation sits at its own hostname. The host decides which organisation is opened — no path, header or query string can influence it
Own data store	Each organisation has its own store. There are no shared tables of organisation data, and therefore no filter condition that can be forgotten
Own store per case	Each case has its own store. Smaller blast radius, and total ordering in the log without locks
Credentials bound to the address	Passkeys are bound to the organisation's own hostname. The browser cannot produce a valid assertion for one organisation with a credential issued at another
Wrong scope returns "does not exist"	An unknown host, a closed organisation, a foreign session and an unknown route all give the same answer. A "no access" would confirm that the resource exists

5.3 Encryption

State	Measure
At rest	All customer content is encrypted in the store with AES-256-GCM, under a data encryption key unique to each organisation and wrapped by a key encryption key. Encryption happens inside the store, never outside — otherwise the store could not search or sort the content
In transit	TLS 1.3, HSTS. No cleartext fallback, including between internal components
In use	Cleartext exists only in the isolated store's memory, field by field. Never in the control plane, never in a log, never in an error message
Missing key	Key supply throws. A service that silently falls back to cleartext when the secret is missing is lying about what it does

Key lengths and algorithms are named in one place in the code, and every encrypted field carries a version marker, so a primitive can be replaced without migrating all data at once.

5.4 Access control

No passwords. The passkey is the identity. There is no recovery path by email, because there is no email address
Access is granted on the server, never by the client. Roles and permissions are derived from a permission map, not from a list that can drift
Session state is read on every request, so revocation takes effect at once, not at the next expiry
One row per session, so one device can be revoked without logging the user out of the others
Removing a member deletes the credential and revokes open sessions, in the same operation

5.5 CIRON holds no standing access to the content

This is the measure that matters most, and it is also a limitation: CIRON cannot read a customer's content, and therefore cannot retrieve it for the customer either. An operator sees which organisations exist, whether they are open, and what bindings they have — never a single row at a customer.

5.6 What CIRON's control plane contains

May contain	May not contain
Organisation: id, short name, status, gates, wrapped key, key digest	Names, email addresses, telephone numbers
Audit index with internal ids	Passkeys and devices
Contract basis: form, trial expiry, subscription, document version	Sessions and session digests
Operational counters with no link to people	Case content of any kind

A breach of the control plane therefore does not leak the user directory for any customer.

5.7 Logging and traceability

The organisation's own log is append-only. An entry can be corrected by a new entry, not removed. The audit trail also documents deletion, and contains only internal identifiers.

5.8 Integrity and recovery

AES-256-GCM turns any alteration of ciphertext into a decryption failure. Tampering is self-revealing
Redundant storage, with an encrypted backup in the EU
Every export package carries a manifest with a checksum, so the customer can confirm it is whole
Recovery is exercised regularly by actually reading a backup back and verifying it

5.9 Jurisdiction

Stores are opened with the jurisdiction pinned to the EU, in code, at the point the store is opened. It is enforced, not documented: there is no code path that opens a store without that pin.

5.10 Security in development

Every release passes gates that measure the finished surface and run the real code path, not merely read source text
Security headers are set in one shared layer and measured on a real response, including on 404 and 503
The application loads nothing from third parties in production. No tracking, no analytics, no fonts or scripts from anyone else's server
A vulnerability reporting policy and contact point are published under RFC 9116 at /.well-known/security.txt

5.11 Certification

CIRON AS currently holds no certification against ISO/IEC 27001, ISO/IEC 27701 or ISO/IEC 27018, and no SOC 2 or ISAE 3402 report. This is stated here because a missing certification is information the customer should have without asking, and because an agreement that is silent about it reads as though one exists. The controls above are described so that they can be verified without a certificate.

5.12 Measures that make the assistance in Clause 8 possible

Self-service export of all the organisation's content, machine-readable and human-readable in the same package
Self-service extraction per data subject, to answer an access request
Deletion of a single data subject, and of the whole organisation
The information the controller needs for its own record under Article 30(1), and for a data protection impact assessment

6 Annex IV — Sub-processors

6.1 General authorisation

The controller gives general written authorisation under Clause 7.7 Option 2 to the sub-processors in 6.2.

6.2 The list

Sub-processor	What they do	Where processing takes place
Cloudflare, Inc.	Operation of the service: compute, data stores, object storage and the edge. Processes all content, but in encrypted form under the organisation's own key	EU jurisdiction, pinned on every store
Stripe Payments Europe, Ltd.	Subscription and payment. Processes billing contact details, not service content. Does not apply to trial accounts	EU

The list is exhaustive. If a row is not here, the processor is not authorised.

6.3 Notification of changes

CIRON notifies the controller in writing at least 30 days before a sub-processor is added or replaced. The notice states who, what they will do, where, and which transfer mechanism applies.

6.4 Objection

The controller may object within the deadline. If the matter is not resolved in dialogue, the controller may terminate the agreement at no cost, with retrieval under Annex VII.

6.5 Flow-down of obligations

CIRON imposes on each sub-processor the same obligations as follow from this agreement, by contract or other legal act, and CIRON remains fully liable to the controller for the sub-processor's performance.

7 Annex V — Transfers outside the EEA

7.1

Service content is processed in EU jurisdiction. Stores are opened with the jurisdiction pinned, and there is no code path that bypasses the pin.

7.2

Cloudflare, Inc. and Stripe Payments Europe, Ltd. both belong to groups with a US parent. Where intra-group access may occur for operations and support, the transfer mechanism is the Commission's standard data protection clauses in Decision (EU) 2021/914, Module Three (processor to processor), with a documented transfer impact assessment under Clause 14.

7.3 We do not rely on the EU–US framework alone.

The adequacy decision for the EU–US Data Privacy Framework is in force, but is under challenge before the Court of Justice (Case C-703/25 P, appealed on 31 October 2025 after the General Court dismissed the action on 3 September 2025). A transfer mechanism that may fall away while the agreement runs should not be the only one. The standard clauses therefore stand as an independent basis.

7.4 Transparency about government access

If CIRON receives a request from a public authority for disclosure of personal data processed for the controller, CIRON notifies the controller before disclosing, unless prohibited by law. If prohibited, CIRON works to have the prohibition lifted, and records the attempt in writing.

7.5

Because content is encrypted under the organisation's own key, and CIRON holds no standing access to it, such a request could not in practice be answered with readable content.

8 Annex VI — Notification of breaches and incidents

8.1 Two regimes, two clocks, two notifications.

They are often conflated. A personal data breach and an operational incident affecting availability are not the same thing, and they do not share a deadline.

8.2 Personal data breach

CIRON notifies the controller without undue delay, and within 24 hours at the latest, after becoming aware of the breach. Article 33(2) says "without undue delay"; the 24 hours is CIRON's own commitment, set so that the controller can meet its own 72-hour deadline.

8.3 Content of the notification

The notification gives what Article 33(3) requires, so far as known:

What happened, and when
Which categories and approximately how many data subjects, and how many records
Likely consequences
Measures taken or proposed, and what the controller should do
Contact point: contact@ciron.no

If not everything is known, the notification is sent within the deadline anyway and supplemented as matters develop. A complete notification after the deadline is worse than an incomplete one within it.

8.4 Operational incidents for a customer subject to NIS2

Where the controller is an essential or important entity under national law implementing Directive (EU) 2022/2555, CIRON notifies a significant incident affecting the service within 24 hours, with follow-up within 72 hours and a final report within one month. The deadlines follow the customer's own deadlines, so the customer can meet them.

This applies whether or not personal data are affected. An incident that affects only availability is not a breach under 8.2, but it is an incident under this clause.

8.5

CIRON is not itself subject to NIS2 today. Norway has implemented NIS1 in the Digital Security Act, in force 1 October 2025; NIS2 is not yet Norwegian law. The obligation in 8.4 is contractual, not statutory, and it applies in full nonetheless.

8.6 Assistance

CIRON assists the controller in complying with Articles 32 to 36: security, notification to the supervisory authority and to data subjects, data protection impact assessment and prior consultation.

9 Annex VII — Termination, retrieval and switching

9.1 This annex covers two regimes at once.

Article 28(3)(g) GDPR gives the controller a choice between deletion and return. Chapter VI of the Data Act (Regulation (EU) 2023/2854) gives the customer a retrieval window and an erasure guarantee. We keep them in one annex so that they do not say different things.

9.2 We apply the Data Act to all customers.

The Regulation has not yet been incorporated into the EEA Agreement, and is therefore not Norwegian law. It binds us nonetheless through customers established in the EU, and Article 29 prohibits switching charges from 12 January 2027. Two contract variants to keep aligned would be one customer relocation away from an error. This annex therefore applies to everyone.

9.3 Exportable data — exhaustive

Plans with all versions and approvals
Exercises, scripts and runs
Incidents, measures and deadlines
Decision and audit log
Roles, functions and preparedness organisation
The organisation's settings
Attachments, where the organisation has turned them on

9.4 Data that cannot be exported — exhaustive

Passkey credentials. They are bound to the user's device and to the organisation's address, and can be neither moved nor reused. This does not impede switching: users register new keys with the new provider
Digests of active sessions. They are security state, not customer data, and are worthless outside the service

9.5 Format and interfaces

The export is JSON and CSV, UTF-8, time in ISO 8601, with a versioned schema and a manifest with a checksum. The schema is included in the package, so it can be read without access to CIRON's source code. A register of formats and schemas is available on request to contact@ciron.no.

9.6 Transitional period

On notice of switching or termination, CIRON provides assistance for up to 30 calendar days, and maintains the service and the level of security throughout. The customer may extend the period once, for a period the customer determines. Where 30 days is technically unfeasible in a particular case, CIRON notifies within 14 working days, justifies it, and proposes another period of no more than seven months.

9.7 Retrieval window

After the transitional period ends, the customer has at least 30 calendar days to retrieve data. Export and read access work throughout the window.

9.8 Deletion

When the retrieval window expires, content is permanently deleted. The organisation's encryption key is deleted first. After that the content is unreadable, including in backups that have not yet expired. Then the stores, the object storage and the control-plane rows are deleted.

Deletion cannot be undone, and CIRON cannot recover the content. The cooling-off period therefore sits before deletion starts, not after.

9.9 The audit trail remains

The audit index of internal identifiers is preserved, and documents the deletion itself. It contains no names, no email addresses and no content.

9.10 Switching charges

CIRON charges nothing for switching or retrieval.

9.11 Trial accounts

For a trial account, clauses 7.2.1 to 7.2.3 of the terms of use apply: 14 days of trial, then up to 90 days of read and export access, then permanent deletion. If the organisation moves to a paid subscription before the deadline, the account reopens with the content intact.

10 Annex VIII — Audit and access to information

10.1

CIRON makes available all information necessary to demonstrate compliance with the obligations in Article 28, and allows for and contributes to audits, including inspections, conducted by the controller or an auditor mandated by the controller.

10.2 In the ordinary case

The information duty is met through documentation: this agreement with its annexes, the architecture and security documentation, and the results from the gates in the release chain.

10.3 On-site audit

The controller may require an audit once a year, on at least 30 days' notice — and at any time where there are indications of non-compliance, on whatever notice the circumstances allow.

10.4 Costs

Each party bears its own costs for the annual audit. If an audit reveals material non-compliance by CIRON, CIRON bears the controller's reasonable costs.

10.5 The limit

An audit cannot give access to other customers' data, and cannot require CIRON to break the isolation between organisations. This is not an evasion: it is the same isolation that protects the controller from the others.

10.6 Supervisory authorities

The results of an audit are made available to the supervisory authority on request. CIRON cooperates with the supervisory authority under Article 31.

11 Instructions, deviations and termination

11.1

CIRON processes personal data only on the controller's documented instructions. This agreement with its annexes is the complete set of instructions. Changes to the instructions are agreed in writing.

11.2

Where Union or Norwegian law requires processing beyond the instructions, CIRON informs the controller of that requirement before processing, unless prohibited.

11.3 CIRON says so if an instruction breaches the rules.

If CIRON considers an instruction to infringe the GDPR or other data protection law, CIRON immediately informs the controller. The duty follows from the second subparagraph of Article 28(3), and it is not a courtesy: it is the reason a processor cannot hide behind "we did as we were told".

11.4 Confidentiality

Everyone at CIRON with access is bound by confidentiality, agreed in writing, and it continues after the access ends.

11.5 Liability

Liability between the parties is governed by the terms of use. The standard clauses in Decision (EU) 2021/915 deliberately do not regulate liability between the parties, and this agreement does not change that.

11.6 Termination

The agreement ends when the service agreement ends and the obligations in Annex VII are fulfilled. The provisions on confidentiality, the audit trail and deletion survive.