Data processing agreement

Draft 1.0 · 27 October 2026 · not yet in force - the effective date is published here when it is set

One data processing agreement for every MSET product - MSET Sign, MSET Trust and MSET Transcribe. A common body applies to all of them; an annex per product says exactly what that product processes, how long it keeps it and who helps us run it.

This is the Article 28 agreement for every customer of an MSET product: the organisation that uses MSET Sign, MSET Trust or MSET Transcribe to handle other people's personal data. It is one agreement for all of them, shaped like MSET's privacy notice: a common body that applies to every product, and one annex per product that says exactly what that product processes, how long it keeps it and who helps us run it.

• Annex S — MSET Sign
• Annex T — MSET Trust
• Annex R — MSET Transcribe

Provider / Processor: Design & Animation i Vellinge AB, org. no. 556825-4295, Skåne, Sweden, trading as MSET ("we", "us", "MSET")

Customer / Controller: the organisation that has accepted the terms of service of an MSET product ("you", "the Customer")

Effective from: the effective date published on this page, or the date you first accepted an MSET product's terms of service, whichever is later.

1. What this agreement is, and how it is entered into

1.1 One agreement for every product

This Data Processing Agreement ("DPA") forms part of the terms of service of each MSET product (each the "Terms"). It is the written contract required by Article 28(3) of Regulation (EU) 2016/679 (GDPR).

The common body (clauses 1 to 16) applies to every product. Each product has its own annex. An annex applies while you use that product, and only then.

1.2 How it is entered into

You enter into this DPA by accepting the Terms of any MSET product. No separate signature is required, and you do not need to negotiate it before you can use the service. One acceptance covers every MSET product you use, now or later: when you start using another product, its annex applies from that day, without a new acceptance.

If your organisation needs a countersigned copy for its own records, ask at info@mset.se and we will provide one.

1.3 Order of precedence

• Where this DPA and the Terms of a product conflict on the processing of personal data, this DPA prevails.
• Where the common body and a product's annex conflict for that product, the annex prevails.
• Where this DPA conflicts with the Standard Contractual Clauses referred to in clause 9, the Standard Contractual Clauses prevail.

1.4 Terms used

Personal data, processing, controller, processor, sub-processor, data subject, personal data breach and supervisory authority have the meaning the GDPR gives them. "Product" means MSET Sign, MSET Trust or MSET Transcribe. "Annex" means the annex for a product, with its own Annexes I to III.

2. Roles

2.1 Where you are the controller and we are your processor

For the personal data your organisation puts into a product, or collects through it about other people — the people you send documents to sign, the visitors to your trust centre, the people in your meetings — you are the controller and we are your processor. This DPA governs that processing. The annex for each product says exactly what is processed, and where MSET is a controller instead.

2.2 Where we are the controller

For your account data — your organisation's details, the people at your organisation who use the products, how they sign in, your subscription and billing state, and our own security logs — we are the controller. That is outside this DPA; section 4 of MSET's privacy notice describes it. Your people sign in through MSET ID, MSET's identity service.

2.3 Where we are a controller in our own right for product data

In one case a product keeps something as our record, not yours: MSET Sign's evidence record of each signature (Annex S, clause S4). The annex says what it is, why it exists and why erasure stops at its edge.

2.4 Services of the same company

MSET ID, MSET Sign and MSET's commerce service are operated by the same company as every other MSET product. Where one product uses another, that is not a sub-processor: the processing is ours, under this DPA, as the annexes say.

3. What you are responsible for

You warrant that:

• you have a lawful basis for the processing you instruct us to carry out;
• you inform the people whose data you put into a product as Articles 13 and 14 GDPR require. Most of them have no relationship with us. MSET's privacy notice has a section for each product's data subjects to help you, but giving that information is your obligation as controller, not ours;
• you do not put special categories of personal data (Article 9) or criminal-offence data (Article 10) into a product unless you have satisfied yourself that the measures in the annex's Annex II are appropriate for it, and you have a valid Article 9 or 10 condition;
• the instructions you give us do not breach data protection law.

Each annex adds what is particular to its product.

4. Subject matter and duration

The subject matter, nature and purpose of the processing for each product are in its annex.

Processing under this DPA lasts for as long as you use a product, plus the period after your subscription ends that the product's annex states. Clause 12 says what happens at the end.

5. Our instructions and our limits

5.1 Documented instructions

We process personal data only on your documented instructions, including in relation to transfers to a third country, unless EU or Swedish law requires otherwise — in which case we will tell you before processing, unless that law prohibits it on important grounds of public interest.

Your documented instructions are: the Terms, this DPA, the configuration you set in each product, and what your administrators and users do in it. Anything else must be agreed in writing.

5.2 If we think an instruction is unlawful

We will tell you if, in our opinion, an instruction infringes the GDPR or other EU or Member State data protection law. We may suspend the affected processing until it is resolved.

5.3 What we will not do

We will not:

• use your content, or the personal data in it, for our own purposes, except as an annex states (MSET Sign's evidence record) and for aggregated, fully anonymised operational statistics that cannot identify you or any person;
• train machine-learning models on your content, for ourselves or anyone else, or permit a sub-processor to do so;
• send your content to an AI model except as an annex states, only where you have switched that function on, and only under terms that forbid the provider to train on it;
• sell, rent or share personal data processed under this DPA;
• read your content, except as the annex for that product allows and within its limits.

6. Confidentiality and personnel

Everyone we authorise to process personal data under this DPA is bound by an obligation of confidentiality, contractual or statutory, that survives the end of their engagement.

Access to systems holding your data is restricted to those who need it to provide or secure the service, and privileged access is logged. Each annex says what our operators can see in that product, and how you allow more.

7. Security

We implement the technical and organisational measures in each annex's Annex II, taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of the processing, as Article 32 requires.

Across the products: encryption in transit, and at rest for our databases and stored documents; separation between customers; access limited to what each person needs; logs of privileged access; and no analytics or advertising cookies — only strictly necessary session and preference cookies.

We may update the measures, provided the level of protection is not reduced. We are not certified to ISO/IEC 27001 and do not claim to be.

8. Sub-processors

8.1 General written authorisation

You give us general written authorisation to engage sub-processors, on the conditions in this clause. The sub-processors of each product are listed in its annex's Annex III.

8.2 Our obligations towards them

Each sub-processor is engaged under a written contract imposing data protection obligations no less protective than those in this DPA. We remain fully liable to you for a sub-processor's performance as if it were our own.

8.3 Notice of change, and your right to object

We give at least 30 days' written notice before adding or replacing a sub-processor, by email to your account administrators and by updating the annex.

If you have a reasonable, data-protection-related objection, tell us within 30 days of the notice. We will work with you in good faith — by describing the safeguards, by offering an alternative configuration where one exists, or by not proceeding. If we cannot resolve it and the change is one we must make to keep providing the product, you may terminate the affected subscription and we will refund the unused part of your current period.

Where a change must be made urgently to protect security or continuity, we may make it first and notify you immediately, with the same objection right running from the notice.

8.4 What is not a sub-processor

These are not our sub-processors, and each annex names its own:

• services of the same company (clause 2.4);
• services you connect yourself — your own Microsoft 365 or Google Workspace, your own Teams or Slack channel, your own systems receiving webhooks, your own AI provider, your own sign-in provider. They act for you, under your agreement with them;
• providers that act under their own terms as controllers in their own right, where an annex says so;
• Stripe, which processes your subscription's payment. That is MSET's account data (clause 2.2).

9. International transfers

Where your data is. The products store your data at rest in Azure Sweden Central, an EU region. We will not move that storage outside the EU/EEA without notice. Each annex says what is stored where; for MSET Transcribe, your meetings stay in your own Microsoft 365.

That is not a claim that no personal data ever leaves the EEA, and we do not make it. Some of our providers are US companies or have US parents, and limited transfers or remote access can occur — for platform operation, mail delivery and support, and where you choose a provider in the United States. A message we send reaches its recipient wherever their mailbox is. Where personal data is transferred to or accessed from outside the EEA:

• we rely on an adequacy decision where one covers the transfer, including the EU–US Data Privacy Framework where the recipient is certified under it; otherwise
• we rely on the EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914), Module Three (processor to sub-processor) or the applicable module, incorporated into this DPA by reference for those transfers; and
• we apply the supplementary measures Chapter V GDPR requires, including encryption in transit, access controls and the measures in each annex's Annex II.

Each annex's Annex III says which safeguard applies to which provider. If you need the Standard Contractual Clauses executed as a separate document, ask us and we will do it. On request we provide the information you reasonably need for your own transfer impact assessment.

10. Assistance: data-subject requests, security and impact assessments

10.1 Requests from data subjects

Taking into account the nature of the processing, we assist you by appropriate technical and organisational measures, insofar as possible, to respond to requests under Chapter III GDPR. In each product you can see, export and, where the annex says so, correct or delete the data yourself, without asking us — for most requests you will not need us at all. Each annex says how.

10.2 If a data subject contacts us instead

We will not answer the substance of a request about data we process for you. We will tell the person that you are the controller, identify you to them, and pass the request to you without undue delay.

10.3 People named inside your content

We do not inspect the content of your documents or meetings and cannot search it. If a request concerns someone named inside your content, you will need to identify the affected items; we will then act on your instruction about them.

10.4 Where erasure stops

Two records in the products are kept for a stated period because their value as evidence depends on the person they record not being able to remove them: MSET Sign's evidence record (Annex S, clause S4), which we keep as controller, and an MSET Trust centre's access log (Annex T, clause T7), which you keep as controller. Each annex says what they hold, how long and on what basis.

10.5 Security, breaches and impact assessments

We assist you in ensuring compliance with Articles 32 to 36 — security of processing, breach notification, data protection impact assessments and prior consultation — taking into account the nature of the processing and the information available to us. Our documentation for a data protection impact assessment is part of what clause 13 provides.

11. Personal data breaches

We notify you of a personal data breach affecting personal data we process for you without undue delay after becoming aware of it, and in any case within 48 hours, so that you have time to meet your own Article 33 obligation.

The notification describes, as far as known at the time and updated as we learn more: the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact point.

You notify your supervisory authority and, where required, the people affected, because you are the controller; we provide the information and cooperation you reasonably need. Where we are the controller, we notify the Swedish Authority for Privacy Protection (IMY) within 72 hours ourselves.

We will not identify you publicly in connection with a breach without consulting you first, unless the law requires it.

12. Return and deletion at the end

Return is yours, and self-service. Each product lets you export your data while your subscription runs and in the period after it ends that its annex states. That is the return mechanism; you do not need to ask us.

Deletion follows on schedule. At the end of that period we delete your data as the annex says, unless EU or Swedish law requires us to keep it, or the annex says otherwise for a record we keep as controller. On request we confirm deletion in writing.

Deletion is permanent. We do not restore deleted data from backup for you. Export before your data is deleted.

13. Audit and information rights

We make available the information necessary to demonstrate compliance with Article 28, and allow for and contribute to audits, including inspections, by you or an auditor you mandate. For a supplier of our size, this is how it works:

• First, documentation. Our security documentation, this DPA, the sub-processor lists with their safeguards, and our answers to a reasonable security questionnaire, within 30 days of your request and at no charge, once in any 12 months.
• Then, if that is not enough, an audit by agreement, on site or remote: on at least 30 days' written notice, during business hours, once in any 12 months, under confidentiality, and scoped so as not to compromise other customers' data or our security. You bear your own costs and our reasonable costs of supporting it.
• Without those limits where a supervisory authority requires it, or after a personal data breach affecting your data.

We are not ISO/IEC 27001 certified and do not claim to be. Where a certification or third-party audit report exists in future, providing it will satisfy this clause in the first instance.

14. Liability

Liability under this DPA is subject to the limitations in the Terms of the product concerned, except where the law does not permit them. In particular, nothing in the Terms or this DPA limits a data subject's rights under Article 82 GDPR, or either party's liability to a supervisory authority.

15. Governing law and disputes

Swedish law governs this DPA. Disputes go to the Swedish courts, with Malmö District Court (Malmö tingsrätt) as the court of first instance. Where a separately negotiated agreement provides for another law, another court or arbitration, that agreement prevails for the parties to it.

If any provision is invalid, the rest stands.

16. Changes to this DPA

We may update this DPA where a change in law, in a product or in our sub-processors requires it, on 30 days' notice by email to your account administrators, provided the change does not reduce your protection. Where it would, we will seek your agreement. Adding an annex for a product you do not use changes nothing for you until you use it.

The version and date at the top of this page show the latest change.

Annex S — MSET Sign

This annex applies while you use MSET Sign, the electronic signature service: you send a document for signature, the service collects the signatures and produces a sealed PDF with a signing certificate and a tamper-evident audit trail.

S1. Roles in MSET Sign

S1.1 You are the controller, we are your processor

For the documents you send, their metadata, the people you send them to, everything signers enter or attach, the signing events, and all personal data contained in or attached to them, you are the controller and we are your processor. So are your contacts, your templates, and the key terms and tags you keep on a document.

S1.2 We are an independent controller of the evidence record

For the evidence record of clause S4 we act as an independent controller in our own right. This is the one place where our role changes after your instruction ends, and clause S4 explains why.

S1.3 Identity providers act under their own terms

Where you require it, a signer verifies their identity with an eID through a contracted eID broker, or with an ID document check at an identity verification provider (clause S7). Each provider handles the signer's verification on its own pages, under its own terms and privacy notice, and is responsible for it. They are named in Annex S-III for transparency. We receive only what Annex S-I lists.

S1.4 What you are responsible for in MSET Sign

In addition to clause 3:

• Signers typically have no prior relationship with you or with us. Section 5 of MSET's privacy notice is written for them, but informing them is yours.
• The ID document check processes the signer's images, including their face, at the provider. You decide whether that check is appropriate for your signers, and you need an Article 9 condition for it; the provider asks the signer for their consent before the check starts.
• Whether a signature is enough for a given document, in a given country, is your decision.

S2. Subject matter, nature and purpose

Subject matter and nature: receiving your documents; distributing them for signature and approval; authenticating signers by control of the email address the link was sent to, an optional one-time PIN to the same mailbox, a sign-in through MSET ID, or, where you require it, an eID or an ID document check; recording the signing events; applying an electronic seal and, where a trusted timestamp authority can be reached, an RFC 3161 timestamp; producing the sealed PDF with its signing certificate and audit trail; storing and returning the result; and deleting it on schedule.

The signature levels, stated plainly. By default the signatures are simple electronic signatures under Article 3(10) of eIDAS. An eID or ID document check strengthens the evidence of who signed. It does not, on its own, make a signature an advanced or a qualified electronic signature, and we do not describe it as one. Qualified signatures (QES) are coming; this annex will be updated, with notice under clause 8.3, before they are offered.

Purpose: electronic signature, sealing, and the production and preservation of evidence that a document was signed.

Duration. For as long as you use MSET Sign, plus the retention tail. The tail is two different clocks, and they are not the same:

S3. Data subjects and personal data

S3.1 Data subjects

• Your users — the people in your organisation who send documents, as they appear in your documents and their audit trails.
• Signers, approvers and copy recipients — the people you ask to sign, approve or receive a copy. Most of them have no relationship with us and did not choose the service.
• Your contacts — the people you send to, kept for suggestions as you type.
• People named inside a document — anyone whose personal data appears in a file you upload. We never inspect document content, so we do not know who they are and cannot search for them.

S3.2 Personal data

• Identifiers: names and email addresses, and any company or title you or a signer supply.
• Signing events: when the link was sent and opened, when a person signed, approved or declined, any reason given, and the IP address at those moments.
• Authentication: that a one-time PIN was issued and correctly entered — the PIN itself is not kept after use — or that the signer signed in through MSET ID.
• The signature as drawn or typed, and everything a signer fills in or attaches.
• Document content and attachments, of whatever kind you upload — unknown to us in nature and never inspected.
• eID evidence, where you require an eID: the eID broker's signed answer, kept verbatim — the signer's name, birth date and, where the eID carries one, a national identity number — with the key that verified it and the IP address. The name the eID verified is sealed into the certificate.
• ID document check, where you require it: the outcome, the verified first and last name, the type and issuing country of the document, and a fingerprint of the document number that cannot be turned back into the number. We do not receive the images, and the date of birth, national ID number and address the provider reads are not stored.
• 21 CFR Part 11, where you use it: the meaning of each signature, and the register of people enrolled to sign.
• Key terms and tags you keep on a document, including key terms read by AI (clause S6).
• AI assistance, where you switch it on: what is sent is in clause S6; the content sent is not stored by us.

S4. The evidence record, and why erasure stops at its edge

S4.1 What the evidence record is

When a document's files are deleted — by your retention setting, by your instruction, or because your account closed — the content is destroyed and we keep a minimal record that the document existed and was signed:

• the document's reference;
• who signed it, when, and how each signer was identified — with the eID evidence where an eID was used;
• the signing events of its audit trail;
• a cryptographic fingerprint (hash) of the signed file.

It contains none of your document files.

S4.2 How long

Three years from the deletion of the document's files. For a 21 CFR Part 11 signature, the record is also kept until five years from completion, and goes only when both periods have passed; the certificate prints that date. Then the whole record is deleted together, the eID evidence with it.

S4.3 Why it exists

A counterparty holding a sealed PDF years later must be able to check it against something and be told whether it is genuine. If the record could be erased on request, anyone who later regretted a signature could destroy the only proof it happened — and a signing service whose evidence can be quietly unmade is not evidence of anything.

S4.4 The legal position we take

For the evidence record we act as an independent controller, not as your processor:

• Legal basis: Article 6(1)(f) — our legitimate interest, and that of every party relying on a sealed document, in the integrity and verifiability of the evidence we have produced, and in the establishment, exercise and defence of legal claims.
• Exemption from erasure: Article 17(3)(e) — the processing is necessary for the establishment, exercise or defence of legal claims.
• Objection: an Article 21 objection will be considered, but we expect the compelling legitimate grounds above ordinarily to override it, for the reason given.

S4.5 What this means in practice

We cannot honour an instruction — from you or from a data subject — to erase the evidence record, and your instruction to delete a document does not extend to it. We can and will erase everything else. Where a data subject asks us to erase it, we tell them plainly that we decline, on what basis, what the record contains, and that they may complain to IMY.

Because you cannot instruct us to remove it, treat it as a feature of the service you are buying, and tell your own data subjects about it. Section 5 of MSET's privacy notice explains it in plain language. If this is not acceptable for a particular use, do not use MSET Sign for it.

S5. Support access — yours to give, and it ends by itself

Our support staff cannot open your documents unless you grant access. A grant is:

• yours — made by you; there is no way for us to make one ourselves;
• scoped — one document by default, or, as a deliberate choice, your whole organisation;
• read-only;
• time-limited — 72 hours unless you set another period, and never more than 30 days;
• revocable at any time;
• logged — every look is written to your Activity, naming the operator by reference, and to our own operator log;
• notified — we email you the first time a document is opened under it.

S6. AI assistance — off until you switch it on

• Off by default. Your administrator chooses Off, MSET AI or your own AI provider. Nothing is sent to an AI while it is off.
• MSET AI is operated by us, through Azure OpenAI (Microsoft) or the Claude API (Anthropic), as your administrator chooses (Annex S-III). Your own provider is under your own agreement with it, and is not our sub-processor.
• What is sent, and only what the function needs: for placing fields, reading key terms and checking a document against your playbook, the text of the document's lines — never the file itself, and never signers' addresses; for the message to signers, the title, the file names, the number of signers, the language and your notes.
• When: when a person presses an AI button — and, only if your administrator switches on automatic key terms, once for each signed document.
• Recorded, not stored: each request writes a line in your Activity naming who asked, what kind of content went and to which provider. We do not store the content sent. Key terms read by AI are kept as your notes (Annex S-I), marked as read by AI.
• No training. We do not use your documents to train any model, and the providers we use are bound not to.
• AI output can be wrong. Nothing is sent to signers until a person presses Send.

S7. Identity checks

• eID: Swedish BankID, MitID (including MitID Erhverv) and Norwegian BankID, through the eID broker named in Annex S-III, where your plan includes it and you require it. The verified name is what the signature carries; if it differs from the name you gave, the signer confirms it and you are told. The broker's answer is verified against its published keys before it is kept.
• ID document check: for signers without one of those eIDs, the signer photographs an identity document and themselves at the provider named in Annex S-III. A check in progress is held for at most two days; what is kept of a completed one is in clause S3.2.
• Both are part of the evidence record (clause S4) and are deleted with it.

S8. Services you connect

Microsoft Outlook, Teams and SharePoint; Google Gmail and Drive; Zapier and Make; your own systems through the API and webhooks; an AI agent through MCP; your own sign-in provider; and your own AI provider. A connection is yours to make and to remove, and what you send through it is governed by your agreement with that service. They are not our sub-processors. The add-ons act as the signed-in person, on the message or file they open; an API key does only what its scope allows; a webhook can be set to send only the reference, with no names, addresses or title. Webhooks and API keys are off until we switch them on for your organisation.

S9. Where your data is

Your documents, their metadata and the service database are stored at rest in Azure Sweden Central. Invitations reach signers wherever their mailbox is. Transfers are as clause 9 and Annex S-III say.

S10. Data-subject requests in MSET Sign

You can view, export and delete documents and their data yourself. Settings → Data → Export your data gives one ZIP: the people, documents, signers and their data, every original upload and every sealed PDF, the full hash chain of every document, templates and the activity feed. One signed document can be downloaded with its Evidence pack. The evidence record is outside erasure as clause S4 says.

S11. When your subscription ends, and when your account closes

When your subscription ends, sending stops and your documents become read-only: you can still read, download and export them. They are deleted at whichever comes first — your own retention period, or 90 days after the subscription ended. We write to you before that date and name it.

When your account closes, all document files and signed PDFs are permanently deleted, and so are your key terms and tags. The evidence record stays for the period in clause S4, on our own controller basis, not as your data. Export before you close.

Annex S-I — Details of the processing

Data exporter: the Customer, as controller. Data importer: Design & Animation i Vellinge AB, trading as MSET, as processor.

Data subjects and personal data: as clause S3. Special categories: not requested and not knowingly processed; you control what enters a document (clause 3). The ID document check's images are processed at the provider, not by us (clause S1.4).

Frequency: continuous, for the duration of the subscription.

Nature and purpose: as clause S2.

Retention, as built (release 2026.10.050):

Annex S-II — Technical and organisational measures (as built)

Encryption

• TLS in transit across all interfaces; encryption at rest for the database and stored documents.
• Two-factor secrets, AI provider keys and your own sign-in provider's secret encrypted at rest (AES-256-GCM), under keys held outside the database.
• Passwords held by MSET ID only as one-way hashes.
• Production secrets held as Azure Key Vault references; the service refuses to start in production with a development secret or an unresolved reference.

Access control

• Role-based access within your organisation; separation of customer data between organisations.
• Sign-in through MSET ID, with two-factor authentication; your own sign-in provider on Enterprise agreements.
• Support access to document content only under your grant (clause S5), read-only, expiring, every look recorded in your Activity and in an operator log.
• Webhooks and API keys off until switched on for your organisation; every key scoped.

Integrity of the evidence

• Every completed document sealed with an electronic seal; any change after sealing is detectable.
• RFC 3161 timestamps from an independent timestamp authority where one can be reached.
• The seal provider and the timestamp authority receive only a fingerprint of the file — never the document and no personal data.
• A hash-chained, tamper-evident audit trail for every document; a public verify page that checks a document by its ID.
• Part 11 documents sealed for long-term validation (PAdES B-LTA), so they can be checked without MSET until the date on their certificate.

Identity checks

• The eID broker's answer verified before it is kept: its signature against the broker's published keys, its issuer, audience and expiry; PKCE on every round-trip; the verifying key kept with the evidence so it stays checkable after the broker rotates its keys.
• ID-check decisions accepted only with a valid signature from the provider, and minimised before they are stored: the document number only as a fingerprint.

Mail

• Email sent through Microsoft Graph, the service signing in with a certificate.

Resilience and recovery

• Document storage backed up daily, with 30 daily recovery points; a managed database with provider-level backup.
• Availability target 99.5% a month. No contractual SLA applies unless separately purchased.

Organisational

• Confidentiality obligations on everyone with access.
• Minimisation: we do not inspect document content and do not process it for our own purposes.
• No use of customer content for machine-learning training.
• Deletion on schedule, with deletion dates shown in advance.
• No analytics or advertising cookies; only strictly necessary session and preference cookies.
• Every release passes the automated test suites before it ships.
• Alignment with ISO/IEC 27001 principles. Not certified, and not claimed.

Annex S-III — Sub-processors

Identity providers — not our sub-processors (clause S1.3), named for transparency, used only where you require them:

Not sub-processors, and why:

• Timestamp authorities and the seal provider receive only a fingerprint of the file, no personal data.
• MSET ID and MSET's commerce service are services of the same company (clause 2.4).
• Stripe processes your subscription's payment: that is MSET's account data (clause 2.2).
• The services you connect (clause S8), and your own AI provider, act for you.

Annex T — MSET Trust

This annex applies while you use MSET Trust: you buy a trust centre at <name>.trust.mset.app and use it to release your own confidential material to your own visitors. On your centre, you are the controller and MSET is your processor — the reverse of MSET's own trust centre, where MSET is the controller and section 6 of MSET's privacy notice applies.

T1. Roles in MSET Trust

T1.1 You are the controller, we are your processor

For everything your trust centre processes about the people who ask for, sign for and receive your material — their requests, their access, the log of what they opened, the watermarks on your documents, and their change-notice subscriptions — you are the controller and we are your processor. The documents you place in your centre are yours, and so is any personal data inside them.

T1.2 Your administrators and members

Your administrators sign in through MSET ID; the console keeps only a session (who MSET ID said they are, for at most eight hours) and records their actions in your centre's log (clause T3.2). Members of your organisation whom your administrators let in — to see, or also to approve — sign in the same way and are recorded the same way.

T1.3 Where MSET Sign is involved

The NDA your visitors sign is sent from MSET's MSET Sign account, from your own template. MSET Sign is operated by the same company and is part of how this service is provided, so that processing is ours as your processor under this DPA. One part of it is not: MSET Sign keeps a minimal evidence record of every signature (that a document existed and was signed, by whom and when, and a fingerprint — no content) for three years, as an independent controller, under clause S4 of Annex S. The reason is the same here as there: a signature whose proof can be erased on request proves nothing.

If you connect your own MSET Sign account, your NDAs are sent from it instead and the executed copies stay in your account, under Annex S.

Otherwise the executed NDA is kept in MSET's Sign account. Once your visitor has signed it, we fetch a copy of the sealed PDF into your trust centre and keep it for you. You download it from your console. It is deleted with the rest of your data under clause T8.

T1.4 What you are responsible for in MSET Trust

In addition to clause 3, you warrant that:

• you have a lawful basis for releasing your material under an NDA and for keeping the access log described in clause T3;
• you inform the people who use your trust centre as Articles 13 and 14 require. They come to your centre, not ours, and the information owed to them is yours to give. You give us a link to your privacy notice. We show it where visitors enter their details and on every page of your centre, and your centre does not open without it;
• the NDA your template contains is yours, and you are responsible for its terms;
• what you publish on your public page is yours, including any personal data in it (for example a named contact).

T2. Subject matter, nature and purpose

Subject matter and nature: the provision of an NDA-gated trust centre — a public page, receiving access requests, sending your NDA for signature, granting time-limited access once it is signed, authenticating each visit with a single-use link and a one-time code sent to the signed address, watermarking each document at the moment it is opened, logging each access, sending change notices to those who ask for them, and deleting on schedule.

Purpose: controlling and evidencing the release of your confidential material to the people you choose to release it to.

Duration: for as long as your subscription runs, plus 90 days after it ends (clause T8).

T3. Data subjects and personal data

T3.1 Data subjects

• Your visitors — the people who ask for your material: typically security reviewers, auditors and procurement staff at your own customers and prospects.
• Your subscribers — anyone who opts in to your change notices.
• Your administrators and the members you let in, as they appear in your centre's log.
• People named inside your documents or on your public page — we never inspect document content, beyond stamping a watermark onto it, and cannot search it.

Readers of your public page are not data subjects of this service. The page and its public documents are counted per day — one number per page or document — with no IP address, no user-agent string and no cookie.

T3.2 Personal data

• The request: name, work email, organisation, role, the stated reason for wanting access, the answers to the questions you add to the form (up to three, each kept with the question as it was asked), the language the visitor used, and — where you trust their domain under an agreement — that agreement's reference.
• The grant: the address the NDA was signed under, expiry, revocation. The access link is held only as a hash; the one-time code is held only as a slow one-way derivation and destroyed when it is used.
• The access log: time, event, grant, document, IP address in full, user-agent string, and — for an action taken in the console — the email address of the administrator or member who took it, or of the MSET operator. Each finished day is sealed: a SHA-256 over its entries, chained to the day before, with no personal data in the seal; the latest seal goes to you every Monday.
• Notifications to you: when you choose, an email to your notification address, the Monday summary, and — if you connect one — a post to your own Teams or Slack channel, naming a visitor and their organisation (never their stated reason or email address). The channel is yours: Microsoft or Slack receive the post as your processors, not ours. And — if you connect one — signed events to your own system (a webhook), naming the visitor, their organisation and email address, never their stated reason; the system is yours, and we send to the address you gave and nowhere else.
• The supplier-assessment record: a PDF the visitor downloads of what they were given — their name, email, organisation, role and answers, and their own access-log lines.
• AI assistants, only if you switch them on: the assistant's name and return address as it gave them, and its key or tokens only as hashes. An assistant has exactly the visitor's access and no longer; what it does is logged as the visitor's, and its downloads carry the visitor's watermark.
• The watermark: name, email, organisation, time, access reference and a per-download reference, stamped onto each copy.
• Email: queued messages encrypted at rest; bodies destroyed on delivery. Beyond the access itself, your visitors get a reminder a week before their access ends, a message when a document they opened has a new version, and your change notices while their access lasts.
• Subscriptions: email address and confirmation state (double opt-in).
• Answers written by AI, only if you switch them on: a visitor's question to your public page, sent with the passages of your page that match it to the provider you choose (Annex T-III), which writes the answer. We do not store the question or who asked; we count that a question was answered, per day. A visitor is told this beside the question box.
• Questionnaire answers drafted by AI, only if you switch answers on: when one of your administrators asks for drafts while reviewing a questionnaire, its questions (and an instructions column, if it has one) go to the same provider with the passages of your answer library and public page that match them; the provider drafts answers from those passages alone, and your administrator reviews every one before export. We do not store the questionnaire, the questions or the drafts; your Activity records that a questionnaire was drafted, by whom and when.
• Answers in the trust pack, only if you switch them on (with answers on your public page): a question from a visitor with access, sent with the passages of the documents released to that visitor that match it to the same provider, which writes the answer. The text of those documents is read from them when a question needs it and kept only in the service's memory. We do not store the question; the visitor's access log records that a question was answered. The same applies when the visitor's own AI assistant asks, under the visitor's access.
• A visitor's own questionnaire, in the trust pack, with pack answers on: a visitor with access uploads their security questionnaire; its questions go to the same provider with the matching passages of the documents released to that visitor, and the drafts come back for the visitor to review and download. We do not store the questionnaire, its questions or the drafts; the visitor's access log records that a questionnaire was drafted.
• The DORA register's facts you enter (your LEI or EUID, your services, countries and sub-processors' codes). They hold no personal data.

T4. Instructions and limits in MSET Trust

Your instructions include the configuration of your trust centre and what your administrators do in the console — among them the email domains you trust (granted without your NDA) or block.

What we will not do, in addition to clause 5.3: we give your documents and your visitors' data to no AI model — an AI assistant reads your pack only if you allow assistants and a visitor brings one, under that visitor's access, and a visitor's question — with, in the trust pack, the matching passages of the documents released to that visitor — or a questionnaire your administrator asks to have drafted goes to the AI provider you choose only if you switch answers on (clause T3.2), under terms that forbid it to train on them. We will not open your documents or see your visitors' details except to stamp the watermark the service applies, or when you allow it under clause T5.

T5. Support access — yours to allow, and it ends by itself

Our operators see how your centre is running — counts, states, dates, settings, document titles and whether each is released — so that they can support you. They do not see your documents, your visitors' identities or what your visitors wrote, unless you allow it in your console:

• for one request, which states who asks and why, for a stated number of hours, ending by itself; or
• as a standing permission of up to twelve months, which only you can switch on, which is shown on every page of your console while it is on, and which ends by itself.

Every look under either is recorded in your activity log with the operator's name, and in our own operator log, which no one can edit. Our operators never act as you, and never release a document on your behalf.

For your security, our operators may also sign a person out of your console from MSET's own console, for example when an account may be compromised. That opens nothing; it is recorded in your activity log and in our operator log.

T6. Where your data is

Your trust centre's database and documents are stored at rest in Azure Sweden Central. Our hosting and mail providers are US-parented, and limited transfers or remote access can occur for platform operation and mail delivery, as clause 9 and Annex T-III say.

T7. Data-subject requests, and the access log

T7.1 Our assistance

Your console shows each visitor's requests, access and log entries, and exports everything in one ZIP — documents and versions, requests with their answers, the log with its seals. Correction or erasure of a visitor's request, grant or subscription is done by us on your written instruction until the console offers it.

T7.2 The access log, and why erasure stops at its edge

The access log is the evidence that your material was released under a signed NDA and to whom. Its value depends on the person it records not being able to remove it. It is therefore kept for the period in Annex T-I and then deleted outright — not anonymised, nothing survives — and a request from a visitor to erase it before then will not be acted on by us. That decision is yours as controller, on Article 6(1)(f) and Article 17(3)(e); we will implement your instruction either way. You choose the period in your console (Annex T-I).

T8. Return and deletion at the end

When your subscription ends, your centre stops taking new requests and sending new NDAs at once. Access already granted runs to its own expiry — the period you chose, ninety days at most — so that nobody who signed in good faith is cut off mid-review. The deletion below ends any access still running.

Ninety days after your term ends, everything is deleted, unless you renew before then. That covers your documents, your public page, your visitors' requests, grants and subscriptions, queued mail, console sessions, and the copies of executed NDAs we hold for you. The access log follows within a week, because it is deleted by a separate job running under its own identity.

That 90-day window is the period in which you take your data back: the console exports everything in one ZIP, the access log, its seals and every executed NDA included.

A payment that is overdue does not, by itself, start this clock. Only the end of your term does.

The evidence record MSET Sign keeps (clause T1.3) is retained for three years on MSET Sign's own controller basis, not as your data.

Annex T-I — Details of the processing

Data exporter: the Customer, as controller. Data importer: Design & Animation i Vellinge AB, trading as MSET, as processor.

Data subjects: your visitors; your subscribers; your administrators and members as recorded in the log; people named in your documents or on your public page (unknown to us).

Personal data: as clause T3.2. Special categories: not requested and not knowingly processed.

Frequency: continuous, for the duration of the subscription.

Retention, as built:

Annex T-II — Technical and organisational measures (as built)

• Isolation between customers: every table holding a visitor's data is protected by PostgreSQL row-level security, enabled and forced; the application's database role holds neither superuser nor bypass rights, and each request runs inside exactly one customer's scope.
• Least privilege by identity: the visitor-facing service cannot delete the access log; a separate identity with that single right runs the scheduled deletion and nothing else.
• Credentials never stored: access links held only as SHA-256 hashes; one-time codes only as a slow derivation, destroyed on use; ten minutes and five attempts per code.
• Support access only as clause T5 allows, ending by itself, every look recorded in your log; an operator log with no update or delete right for anyone.
• Console sign-in through MSET ID with PKCE; the token's issuer, audience, nonce and expiry are checked; sessions are held server-side as hashes, last eight hours and end at sign-out. Only an administrator of the paying organisation gets in, or a member an administrator let in (to see, or also to approve); every action is logged under that person's address.
• Two-person release, if you switch it on: one person prepares a document, or a change to the public page, and a different person releases it.
• A sealed log: each finished day sealed with a chained SHA-256; the console checks the log against its seals and names any day that no longer matches.
• Encryption: TLS in transit; encryption at rest for the database and documents; queued mail bodies and headers additionally sealed with a rotating key, destroyed on delivery.
• Per-copy watermarking traceable to one log line.
• Release control: a document reaches nobody until an administrator releases it; the release is bound to the file's SHA-256 and lapses if the file changes. A document is public only if it is marked public and released.
• No third-party scripts, analytics or trackers; only session and preference cookies, none shared; a strict Content Security Policy with no script at all. Logos are rebuilt from their image data before they are stored.
• Verified inbound integrations: signed webhooks from MSET Sign, signed grants from MSET's commerce service, and MSET's console asking about or ending console sessions — each refused unless its own key's signature and the timestamp verify, and each request to end a session applied once.
• Change control: every release passes an automated test suite against PostgreSQL and a mutation register that deliberately breaks each security guard and requires a test to notice.
• Not certified to ISO/IEC 27001, and not claimed.

Annex T-III — Sub-processors

Not sub-processors, and why:

• MSET Sign and MSET ID are services of the same company (clause T1.3 for Sign's evidence record).
• Stripe processes your subscription's payment. That is MSET's account data (clause 2.2), not your visitors'.
• Your own Teams or Slack channel, your own system receiving webhooks, and your own MSET Sign account, if you connect them, are yours: they act for you, not for us.

Annex R — MSET Transcribe

This annex applies while you use MSET Transcribe: your people record, transcribe and summarise their meetings with the service. For the meetings, you are the controller and MSET is your processor. For your account data, MSET is the controller (clause 2.2), and section 7 of MSET's privacy notice describes the service for the people in your meetings.

R1. Roles in MSET Transcribe

R1.1 You are the controller, we are your processor

For everything the service processes about the people in your meetings and the meetings themselves (the recordings, the transcripts with their speakers, the briefs and action items, your clients' names and terms, delivery addresses, the consent records and the activity log) you are the controller and we are your processor.

R1.2 Sign-in

Your people sign in through MSET ID, MSET's identity service (clause 2.2).

R1.3 Where your meetings are kept

Your meetings are kept in your own Microsoft 365: in each person's OneDrive, in a folder of the service's own, or in one SharePoint site your administrators choose. Microsoft holds them under your agreement with Microsoft, and your retention settings decide how long they stay. The service reads and writes them through Microsoft Graph, as the person whose meeting it is. We keep no copy of a meeting on our own storage; a recording is held only while it is processed.

R1.4 What you are responsible for in MSET Transcribe

In addition to clause 3, you warrant that:

• you have a lawful basis for recording your meetings and having them transcribed and summarised, and you inform the people in them as Articles 13 and 14 require. The service lets your people record how participants were told (clause R3.2); it does not tell them for you;
• the meetings you process do not contain special categories of personal data (Article 9) or criminal-offence data (Article 10), unless you have satisfied yourself that the measures in Annex R-II are appropriate for it;
• what your people share or send from the service is theirs and yours to decide. Your administrators can limit sharing and delivery outside your organisation.

R2. Subject matter, nature and purpose

Subject matter and nature: turning recordings of your meetings into transcripts with the speakers apart; writing briefs and action items; keeping them in your Microsoft 365; letting the person whose meeting it is share it inside your organisation or send it on; recording your organisation's activity; and deleting on schedule.

Purpose: giving your people a written record of their meetings.

Duration: for as long as your subscription runs, plus 90 days after it ends (clause R8).

R3. Data subjects and personal data

R3.1 Data subjects

• The people in your meetings: your own people, and anyone else who takes part, such as your clients, suppliers and partners.
• Your people who use the service, as they appear in the activity log and the usage counts.
• People named in a meeting: we do not inspect what is said, and cannot search it.

R3.2 Personal data

• The recording: the audio, held only while it is transcribed, and then deleted from our servers.
• The transcript: what was said, by which speaker, with the speakers' names when your people give them, and when in the recording.
• The brief: key points, decisions and action items with owners, written by AI, marked so, and the name of the person who reviewed it.
• Per client: the client's name, the names and terms the transcription should get right, and saved delivery addresses.
• The consent record, if your people keep one: how the participants were told the meeting was recorded, whether people from outside took part and whether anyone objected. It stays with the meeting.
• The activity log: shares, exports, deliveries, deletions, restores, settings changes, handovers and emergency access, by person and never by meeting title.
• Usage: each person's number of transcriptions and minutes, with no titles.
• Connections: for each person who connects them, their Microsoft account's name and an encrypted token for it, and an encrypted token for their own Plaud account.

R4. Instructions and limits in MSET Transcribe

Your instructions include what your administrators and your people choose in the service, including the policy on the Organisation page.

What we will not do, in addition to clause 5.3: we will not use your meetings for our own purposes; we will not train machine-learning models on them or let a sub-processor do so; we will not sell, rent or share them; and no one at MSET reads your meetings. The service sends a recording to speech recognition, and a transcript to the AI provider your administrators chose for briefs, only to do what your person asked, under terms that forbid training on them (Annex R-III).

R5. Who can read a meeting

• The person whose meeting it is, and the people they share it with, read-only, until they stop sharing it.
• Your administrators see usage and the activity log, never the meetings.
• Emergency access. When there is a legal need to read a person's meetings, one administrator asks, a second decides, access is read-only for 72 hours, the person is told with the reason, and every step is in the activity log.
• MSET's operators see how your organisation's service is running (counts, states, dates and settings) and have no access to meetings in the service.

R6. Where your data is

Your meetings are in your own Microsoft 365 (clause R1.3). What we keep ourselves is stored at rest in Azure Sweden Central, an EU region, and speech recognition and briefs run in the EU, unless your administrators choose a provider in the United States (Annex R-III). Some of our providers are US-parented, and limited transfers or remote access can occur for their operation, as clause 9 says.

R7. Data-subject requests in MSET Transcribe

Your meetings are files in your own Microsoft 365, where you can find, export, correct or delete them. In the service, the person whose meeting it is can export, correct or delete it, and back up their whole library. The activity log and usage are deleted with your organisation's records (clause R8), or earlier on your written instruction.

R8. Return and deletion at the end

When your subscription ends, new transcription stops at once. What is already transcribed stays readable for 90 days, then downloadable only.

Ninety days after your term ends, we delete your organisation's records on our storage (the activity log, shares, the policy and your people's connections), unless you renew before then. We keep a record that each deleted file existed (its size, a fingerprint and dates, no content and no names) for three years.

Your meetings are not ours to delete: they are in your own Microsoft 365, and stay there as your retention settings decide. Usage counts are kept while your organisation's MSET account is open.

Annex R-I — Details of the processing

Data exporter: the Customer, as controller. Data importer: Design & Animation i Vellinge AB, trading as MSET, as processor.

Data subjects and personal data: as clause R3. Special categories: not requested and not knowingly processed; a meeting may contain them, and clause R1.4 applies.

Frequency: whenever your people transcribe, for the duration of the subscription.

Retention, as the service is built today:

Annex R-II — Technical and organisational measures (as built)

• One owner per meeting: every request runs in the library of the person its verified MSET sign-in names, never one named by the request; another person's meeting answers "not found". Tests check, for each feature, that one person's content never reaches another's library.
• No names in addresses: a client or a meeting is addressed by an opaque id made with a key of the owner's library; the service's own logs carry no titles, names or query strings.
• Microsoft with a certificate: the service signs in to Microsoft with a certificate, never a secret, and asks only for the folder of its own in a person's OneDrive (each further permission, for mail or Teams, only when that person switches it on).
• Sealed tokens: each person's Microsoft and Plaud tokens are stored encrypted with a key held in Azure Key Vault.
• Sign-in through MSET ID, with the token's issuer, audience, nonce and expiry checked, and the organisation admitted only while it has a plan.
• The activity log, append-only per organisation, by person; an action that must be recorded does not go ahead without its record.
• Emergency access only as clause R5 says: two people, read-only, 72 hours, the person told.
• A person's own backup: made from, and restored into, that person's own library only; a restore checks every file against the backup's list before anything is written, and never overwrites a meeting already there.
• Encryption: TLS in transit; encryption at rest on our storage and in your Microsoft 365.
• No third-party scripts, analytics or trackers in the app; a strict Content Security Policy.
• Change control: every release passes an automated test suite on the two web servers the service can run under, and a register that deliberately removes each guard and requires a test to notice.
• Not certified to ISO/IEC 27001, and not claimed.

Annex R-III — Sub-processors

Not sub-processors, and why:

• Your Microsoft 365 (OneDrive, SharePoint, Teams, mail): your meetings are kept, imported and sent there under your agreement with Microsoft.
• Plaud is a person's own account, under Plaud's terms; the service imports from it on that person's instruction. Your administrators can switch Plaud import off.
• MSET ID is a service of the same company. Stripe processes your subscription's payment: that is MSET's account data (clause 2.2).

Design & Animation i Vellinge AB, trading as MSET · Skåne, Sweden · info@mset.se