1. Parties and scope
This Data Processing Agreement ("DPA") forms part of the Agreement between:
Avalus Oy, Business ID 2554583-2, VAT number FI25545832, Lumikatu 11, 15340 Lahti, Finland (the "Processor"); and
the Customer identified in the Order Form or tenant registration record (the "Controller").
It governs the Processor's processing of personal data on the Controller's behalf in providing the eSoppari electronic signing service (the "Service"), and is concluded pursuant to Article 28(3) of Regulation (EU) 2016/679 ("GDPR").
Where this DPA conflicts with the Terms of Service, this DPA prevails in respect of the processing of personal data.
The version of this DPA the Controller accepted, and the time of acceptance, are recorded against the Controller's tenant account.
2. Roles
The Controller is the controller and the Processor is the processor in respect of personal data contained in, or generated in the course of processing, the Controller's documents, signing requests, signers and users ("Controller Personal Data").
The Processor acts as an independent controller for the limited processing described in its Privacy Policy — account administration contacts, billing records, the platform audit register and security logging, including the ingress access log described in Annex II A.7. That processing is outside the scope of this DPA.
Where the Processor determines the purposes and means of processing in breach of this DPA, it is a controller for that processing under Article 28(10) GDPR.
3. Instructions
3.1 Documented instructions
The Processor processes Controller Personal Data only on the Controller's documented instructions, including as regards transfers to a third country, unless required by Union or Member State law to which the Processor is subject. In that case, the Processor informs the Controller of the requirement before processing, unless that law prohibits it on important grounds of public interest.
3.2 What constitutes an instruction
The following together constitute the Controller's complete documented instructions:
- this DPA and the Agreement;
- the configuration the Controller applies in the Service, including its retention schedule, its per-category retention windows, the Article 6(1) ground and purpose it states to signers, its user and permission assignments, and its selection of Long-Term Preservation for individual signing requests; and
- the Controller's use of the Service's functions in the ordinary course.
3.3 Unlawful instructions
The Processor informs the Controller if, in its opinion, an instruction infringes the GDPR or other applicable data protection law. The Processor may suspend the affected processing until the instruction is confirmed, amended or withdrawn.
3.4 Requests from authorities
Where a court, a public authority or a law-enforcement body requests Controller Personal Data, the Processor notifies the Controller before responding unless the law prohibits it, discloses only what the request lawfully requires, and keeps a record of the request and of what was disclosed.
4. Confidentiality
The Processor ensures that persons authorised to process Controller Personal Data are bound by an appropriate obligation of confidentiality, whether contractual or statutory, and that the obligation survives the end of their engagement.
Access is limited to personnel who need it to provide the Service or to comply with law.
5. Security
The Processor implements appropriate technical and organisational measures under Article 32 GDPR, as described in Annex II.
The Controller acknowledges that it has reviewed Annex II, including Part C, and considers the measures appropriate to the risk of its own processing, taking into account the state of the art, the cost of implementation, and the nature, scope, context and purposes of processing.
The Processor may update the measures provided the level of protection is not reduced.
6. Subprocessors
6.1 General authorisation
The Controller gives general written authorisation for the Processor to engage subprocessors, subject to this Section.
The subprocessors engaged at the date of this DPA are named in Annex III.
6.2 Notice and objection
The Processor gives the Controller at least 30 days' notice before adding or replacing a subprocessor. Notice is given by email to the Controller's administrative contact and by updating Annex III.
The Controller may object on reasonable data-protection grounds within 30 days of notice. The parties will discuss the objection in good faith. If it cannot be resolved, the Controller may terminate the affected part of the Service, or the Agreement, without penalty, with effect from the end of the current billing period.
Where the change is required urgently for security or continuity, the Processor may implement it immediately and notify as soon as practicable; the objection right then applies retrospectively.
6.3 Terms and responsibility
The Processor imposes on each subprocessor, by written contract, data protection obligations no less protective than those in this DPA. The Processor remains fully liable to the Controller for the performance of each subprocessor's obligations.
7. Data subject rights
The Processor assists the Controller, by appropriate technical and organisational measures and insofar as possible, in fulfilling its obligation to respond to data subject requests under Chapter III GDPR.
The Service provides functions the Controller can use directly, without needing to contact the Processor:
- Access and portability — signing requests, signers, audit records and signed documents are viewable and downloadable through the administration portal, one document at a time. There is no bulk export; see Section 15.2 of the Terms of Service.
- Erasure — the Controller can submit an erasure request for a signing request through the administration portal. Execution is described in Section 11.
- Rectification and restriction — the Controller can amend or cancel signing requests and apply a legal hold.
Where a data subject contacts the Processor directly in respect of Controller Personal Data, the Processor will not respond substantively, and will forward the request to the Controller without undue delay.
Assistance beyond the Service's own functions is chargeable at the Processor's then-current rates.
8. Assistance with Articles 32–36
Taking into account the nature of processing and the information available to it, the Processor assists the Controller in ensuring compliance with its obligations under:
- Article 32 — security of processing, through Annex II and the information in it;
- Articles 33 and 34 — personal data breach notification, through Section 9; and
- Articles 35 and 36 — data protection impact assessment and prior consultation, by providing information about the Service reasonably necessary for the Controller's assessment.
The Processor does not carry out the Controller's data protection impact assessment.
9. Personal data breach
The Processor notifies the Controller without undue delay, and in any event within 48 hours, after becoming aware of a personal data breach affecting Controller Personal Data.
The notification describes, to the extent known at the time:
- the nature of the breach, including the categories and approximate number of data subjects and records concerned;
- the likely consequences;
- the measures taken or proposed to address it and to mitigate its effects; and
- a contact point for further information.
Where the information is not all available at once, the Processor provides it in phases without undue further delay.
The Processor does not notify a supervisory authority or data subjects on the Controller's behalf unless separately instructed in writing. Notification to the Processor's own supervisory authority in respect of its own obligations is not affected.
The 48-hour clock runs from awareness. Annex II Part C describes what stands behind that commitment, including where detection is weakest. A Controller relying on this figure to meet its own 72-hour obligation under Article 33 GDPR should read it.
10. Audit
The Processor makes available to the Controller the information necessary to demonstrate compliance with Article 28 GDPR, and allows for and contributes to audits, including inspections, conducted by the Controller or an auditor it mandates.
In practice, and to keep audit proportionate to a multi-tenant service:
- Documentation. On request, the Processor provides its current Annex II, its subprocessor list, and a written response to a reasonable security questionnaire, no more than once in any 12-month period.
- On-site inspection. The Controller may conduct an on-site inspection where a personal data breach affecting its data has occurred, where a competent supervisory authority requires it, or, once in any 12-month period, where the documentation in item 1 has not resolved a reasonable and specific concern the Controller has put in writing. The Controller gives at least 30 days' notice, conducts the inspection during business hours, does not unreasonably disrupt the Service, and bears its own costs and the Processor's reasonable costs.
- Confidentiality and other tenants. Any auditor must be bound by confidentiality and must not be a competitor of the Processor. The Processor will not provide access to information relating to other customers, and may redact accordingly.
The Processor holds no third-party security certification at the date of this DPA. It does not hold ISO/IEC 27001 certification, and no SOC 2 report is available.
11. Erasure, retention and return of data
11.1 The Controller's retention schedule governs
Retention is configured by the Controller in the Service, per document category. The Service seeds a default schedule for the Controller's country at onboarding, which the Controller may change. A retention window may be set to indefinite; where a window is set, the minimum is one year and the maximum is 20 years. A signing request the Controller has saved but not sent is outside this schedule altogether; Section 11.6 explains why, and what happens to it instead.
The Processor imposes no retention period of its own on Controller Personal Data, other than as required by law and the deletion of incomplete drafts under Section 11.6. There is no platform-wide retention floor and no evidential hold of the Processor's own: eIDAS imposes no retention obligation on a signing party, and the Processor imposes none. The seeded defaults follow the national statutory retention period where one exists, and a policy default otherwise; they are — set out in Annex I Part G — and every one of them is the Controller's to change.
Two categories of the Processor's own records are outside this schedule and are described in the Privacy Policy, not here: the platform audit register (Section 3.6 of that policy) and finalised invoices retained under the Finnish VAT Act (Section 3.4).
11.2 Erasure on the Controller's instruction
Where the Controller submits an erasure request for a signing request, the Processor permanently erases the associated personal data. Erasure is a hard deletion, not pseudonymisation:
- on the signing request's signers, the name, email address, national identification number, IP address, eID assertion reference, the verified name returned by the eID scheme, and any signing capacity recorded for them — including the organisation a representative signed for — and their language preference are all set to null;
- the free text the Controller entered about the request — the source document's filename, title, description and external reference, and the purpose stated to signers — is cleared;
- in the signing-event log, the signer name and email fields are overwritten with the fixed
string
REDACTED; - every stored version of the signed document is deleted from object storage, including non-current versions held under object-lock retention;
- the source document copy held for the request is deleted; and
- the cryptographic hash of the signed document is cleared, together with the hashes of every superseded generation the request accumulated (Section 12.3). No fingerprint of the erased document survives.
No pseudonymisation token, key or mapping is retained that would allow re-identification. The erased data cannot be recovered by the Processor.
11.3 What survives erasure, and why
After erasure the signing request keeps a skeleton record that identifies no one:
| Retained | Why |
|---|---|
The signing request identifier and its status of erased |
Lets the public verification page tell a person holding a copy of a document that it was erased, rather than that it never existed |
The eID provider code (e.g. ftn) and the assurance level |
Non-identifying; records the class of authentication that occurred |
| The signing timestamp, the signing order position, and the required eID country | Non-identifying transaction facts |
| The source document's language and page count | Non-identifying |
The country of signature (geo_country) |
Country code only. The Service never collects or stores precise geolocation, so there is nothing finer than a country to erase |
| Audit records of the erasure itself | Required to demonstrate the erasure was carried out |
| Billing and accounting records for the transaction | Retained under the Finnish Accounting Act and the Finnish VAT Act |
None of these contains the document's contents or a hash of them, and personal data within them is minimised.
11.4 Retention as a safeguard against premature erasure
Where the Controller has applied a legal hold to a signing request, retention-driven erasure is suspended for that request until the hold is released. Erasure requested directly by the Controller under Section 11.2 is not affected by a hold. Closing the account releases every hold (Section 11.5).
11.5 On termination
On termination or expiry of the Agreement, the Controller may retrieve Controller Personal Data while its tenant account remains open. The Controller should read Section 15 of the Terms of Service, which explains that retrieval is per-document, that no bulk export exists, and that closing the account ends portal access irreversibly.
Closing the account submits an erasure request for every signing request in it. Each is then executed subject to the Controller's own retention windows: a request still inside a window the Controller configured is held and retried, not erased early. Closing the account releases every legal hold the Controller declared, drafts included, so a hold does not delay erasure after closure. The Controller's storage area is removed only once every signing request in it has reached the erased state.
The Processor therefore does not commit to a date by which Controller Personal Data is gone, and no such date should be read into this DPA. Where the Controller configured a ten-year window, erasure follows that window and may take years.
That is also how the Controller exercises the choice between return and deletion that Article 28(3)(g) GDPR gives it: downloading through the administration portal while the account is open is the return, and the retention windows in force at closure set when deletion follows. A Controller that needs a faster outcome shortens its windows (to no less than the one-year minimum in Section 11.1), or overrides a held erasure request with a recorded reason, before the account is closed. A Controller that needs a signing request kept under a legal hold retrieves what it needs of it before the account is closed.
Deletion from backups occurs as backups expire in the ordinary cycle. Retention required by Union or Member State law is unaffected.
At the Controller's written request, the Processor certifies deletion.
11.6 Signing requests saved but not sent
A signing request the Controller has saved without sending is a draft. It holds the signer names and email addresses the Controller entered, and the document it uploaded, for people who have not been invited and whom the Processor never contacts.
No retention window applies to a draft. Every window in Section 11.1 runs from the date a signing request ends — completed, declined or expired — and a draft has not started, so no window can be computed for it.
A draft is incomplete while the Service marks it so because, when it was last saved, it lacked something it needs before it can be sent, such as a signer with a valid email address. Every other draft is complete.
The Processor does not delete a complete draft. It imposes no time limit of its own on one, and does not delete one on its own initiative. A complete draft is kept for as long as the Controller leaves it saved.
The Processor may delete an incomplete draft that nobody has edited for at least 30 days. It does not delete one while the Controller has declared a legal hold on it.
A draft leaves the Service in exactly four ways:
- the Controller sends it, after which it is an ordinary signing request and Section 11.1 applies to it from the date it ends.
- the Controller discards it, which is a permanent deletion and not an erasure request: the signing request, its signers, its signing-event records and the uploaded document are destroyed outright, and no skeleton of the kind in Section 11.3 survives. What remains is the Processor's own audit register: the records of the actions taken on that draft — its creation, each revision the Controller saved by hand or that changed whether it could be sent, any opening of the document, and the deletion itself — each naming the signing request, and the user who acted where one did, by internal identifiers only, and carrying no signer name, no email address and none of the document. That register is the Processor's own processing, described in Section 3.6 of the Privacy Policy.
- the Processor deletes it as an incomplete draft, under the rule above. The deletion is the same permanent deletion as a discard and leaves the same audit records, except that the record of the deletion names no user, because none acted.
- the Controller's account is closed, which submits an erasure request for every signing request in the account, drafts included (Section 11.5). The erasure is carried out as Section 11.2 describes and leaves the skeleton in Section 11.3. A draft has no retention window to hold it, so it is erased without being held; a legal hold the Controller declared is released at closure like every other hold.
The Service offers no erasure request for a draft. Erasure is offered on a signing request that has ended — completed, declined or expired; for a draft the Service offers the discard above instead. An erasure therefore reaches a draft only through account closure.
Storage limitation under Article 5(1)(e) GDPR is the Controller's to apply to a draft: the Controller decides whom it names in one and how long it leaves a complete draft saved. The deletion of incomplete drafts above sets no date by which one is gone, and does not relieve the Controller of that decision.
A PDF uploaded in the Service but never attached to a signing request at all is different: it is not kept, and is reclaimed automatically once it is more than 24 hours old.
12. Long-Term Preservation and retention
12.1 Preservation does not extend retention
Where the Controller has selected Long-Term Preservation for a signing request, the Processor periodically adds a further qualified timestamp to the resulting signed document.
This does not extend, suspend, or otherwise affect the retention period applicable to that document. Retention continues to be governed solely by the Controller's retention schedule and by any legal hold the Controller has declared. A document selected for Long-Term Preservation is erased on exactly the same schedule as one that was not.
Long-Term Preservation determines how long a document remains verifiable from its own contents; the Controller's retention schedule determines how long the document is kept at all. Where the two differ, retention prevails.
12.2 Preservation is not applied where retention would end first
The Processor does not apply Long-Term Preservation to a document whose retention period, as configured by the Controller, ends before the document's validation data would expire. Extending such a document would process personal data for no purpose the Controller has identified.
12.3 Additional copies created by preservation
Each preservation event writes a new version of the signed document to storage. The immediately preceding version is retained as a non-current version subject to its own object-lock retention period.
The Processor also retains, for each preservation event, the cryptographic hash of the superseded version. This is necessary so that a copy of the document distributed before preservation continues to verify against the Service's public verification page rather than being reported as altered. No superseded document content is retained for this purpose — only the hash.
12.4 Erasure of preserved documents
On erasure of a signing request, the Processor deletes every stored version of the signed document, including all versions created by preservation and any non-current versions held under an object-lock retention period, and deletes both the hashes of superseded versions described in Section 12.3 and the hash of the current version.
No hash of the erased document is retained anywhere in the Service.
12.5 Timing of erasure
Preservation and erasure of the same document are serialised, so that neither can act on data the other is modifying. Where an erasure is requested while a preservation event for the same document is in progress, the erasure waits for that event to finish, and in any case for no more than 30 seconds, after which it fails and is retried automatically.
This does not affect the Processor's obligations as to the period within which erasure is carried out.
12.6 Data transmitted to the timestamp authority
Applying a timestamp transmits only a cryptographic hash of the document to the timestamp authority. The document itself, and the personal data it contains, are not transmitted. The timestamp authority is named in Annex III.
12.7 Instruction
The Controller's selection of Long-Term Preservation for a signing request, made while that request is a draft and fixed when it is sent, constitutes the Controller's documented instruction to the Processor to carry out the processing described in this Section for that document.
13. International transfers
The Processor does not transfer Controller Personal Data outside the European Economic Area.
All processing infrastructure is located within the EEA, at the regions named in Annex III, and all personnel with access to Controller Personal Data are located within the EEA. No standard contractual clauses are required between the Controller and the Processor, and none are annexed to this DPA.
The Processor will not transfer Controller Personal Data to a third country, or engage a subprocessor that does so, without first notifying the Controller under Section 6.2 and putting in place a valid transfer mechanism under Chapter V GDPR together with a transfer impact assessment.
On Google Cloud and Amazon Web Services. Google Cloud is the Processor's primary
infrastructure provider: it hosts the application compute, the managed PostgreSQL database
holding all structured personal data, and the hardware security module holding the
organisational seal key. It is contracted through Google Cloud EMEA Limited (Ireland) and the
resources are located in the europe-north1 region (Hamina, Finland). Object storage is
contracted through Amazon Web Services EMEA SARL (Luxembourg) in the eu-north-1 region
(Stockholm, Sweden). Both providers' ultimate parents are United States companies. The
Processor's position is that processing in an EEA region under an EU contracting entity, on
the provider's current data processing terms, is not a transfer within the meaning of
Chapter V.
Should any such processing nonetheless be found to constitute a transfer, the Processor relies on the standard contractual clauses incorporated in each provider's data processing terms, and on the EU-US Data Privacy Framework certification of the provider's parent company where it holds one. The Processor provides its assessment of that transfer on request. A Controller whose own assessment differs should raise it before contracting.
14. Liability
Each party's liability under this DPA is subject to the limitations and exclusions in Section 17 of the Terms of Service, to the extent permitted by applicable law.
Nothing in this DPA limits either party's liability to a data subject, or to a supervisory authority, under Articles 82 and 83 GDPR.
15. Term
This DPA takes effect on the effective date of the Agreement and continues for as long as the Processor processes Controller Personal Data. Sections that by their nature should survive — including confidentiality, erasure and liability — survive termination.
16. Amendment
The Processor may amend this DPA where necessary to comply with applicable law, a decision of a supervisory authority, or a change in the Service, on at least 30 days' notice. The notice states the date the amendment takes effect, which is at least 30 days after the Processor sends the notice to the Controller. Where an amendment materially and adversely affects the Controller, the Controller may terminate under Section 20 of the Terms of Service.
Annex I — Details of processing
A. Subject matter and duration
Subject matter. Provision of a hosted electronic signing service, comprising document storage, invitation and authentication of signers through national electronic identification schemes, application of an advanced electronic seal and a qualified timestamp, optional long-term preservation of validation data, and retention and erasure administration.
Duration. The term of the Agreement, plus the period in which Controller Personal Data is still held under the Controller's own retention schedule (Section 11.5), plus any period of retention required by law.
B. Nature and purpose of processing
Storage; retrieval; transmission; cryptographic hashing; application of electronic seals and timestamps; generation and retention of signing-event records; sending of transactional email to signers and administrators; suggesting previously invited signers to the Controller's own users when they create a new signing request; and erasure.
The purpose is to enable the Controller to obtain legally effective electronically signed documents and to evidence the circumstances of signing.
C. Categories of data subjects
- Signers — natural persons the Controller names in a signing request to sign a document, whether or not they have been invited. A person named in a signing request the Controller saves and does not send is in this category: the Processor holds their name and email address and never contacts them (Section 11.6).
- Users — the Controller's administrators and other authorised personnel.
- Any natural person whose personal data appears in a document the Controller uploads. The Controller determines this category and the Processor has no visibility of it.
D. Categories of personal data
Determined by the Processor's design:
| Category | Detail |
|---|---|
| Identity | Name as entered by the Controller; verified name as returned by the electronic identification scheme; the signing capacity recorded for a representative (title and the organisation represented) |
| Contact | Email address; language preference |
| National identifier | National identification number, where the eID scheme returns one |
| Authentication evidence | eID assertion reference, identification method, assurance level, timestamp of authentication |
| Technical | IP address, session and request identifiers |
| Location | Country of signature, derived from the eID scheme used. Country level only — no precise geolocation is collected or stored |
| Transactional | Signing request status, signature timestamps, signing order, decline reasons, reminder history |
Determined by the Controller, and unbounded:
The full contents of any document the Controller uploads. The Processor does not inspect, index or classify document contents, and cannot enumerate the personal data they contain. The Controller alone determines what it uploads.
E. Special categories of personal data
The Controller may process special categories of personal data (Article 9 GDPR) and personal data relating to criminal convictions and offences (Article 10 GDPR) within document contents, subject to the conditions in Section 6.1 of the Terms of Service.
The Processor applies the measures in Annex II uniformly to all Controller Personal Data and does not apply differentiated handling to special-category data, because it cannot identify it.
F. Frequency of processing
Continuous, for the duration of the Agreement.
G. Retention
As configured by the Controller per document category (Section 11.1). A draft is outside this schedule; Section 11.6 sets out what applies to it. The schedule seeded at onboarding depends on the Controller's country, and every figure is the Controller's to change:
| Category | Finland | Sweden | Norway | Denmark | Basis for the default |
|---|---|---|---|---|---|
| General | 10 years | 10 years | 10 years | 10 years | Policy default; no statutory basis of its own |
| Contract | 10 years | 10 years | 13 years | 10 years | National limitation acts for written contracts |
| Invoice | 7 years | 8 years | 6 years | 6 years | National bookkeeping acts, aligned to the financial year |
| Employment | 10 years | 10 years | 10 years | 10 years | Work-certificate duties and limitation on wage claims |
A Controller in a country not listed receives the highest figure in each row, so no default under-retains. Controllers may add categories of their own.
The Processor's own audit register is not part of this schedule and is not configurable by the Controller; it is described in Section 3.6 of the Privacy Policy.
Annex II — Technical and organisational measures
Measures in force at the date of this DPA. Part C lists measures that are not in place and is part of this Annex.
Part A — Measures implemented
A.1 Tenant isolation
- Every tenant-scoped database table enforces PostgreSQL row-level security with
FORCE ROW LEVEL SECURITY, so the policy applies to the table owner as well. - The application connects as a role that cannot bypass row-level security. Every transaction sets the tenant identifier before any query runs, and resets it first, so a connection returned to the pool cannot carry a previous tenant's scope.
- Cross-tenant access is confined to a small, enumerable set of platform repositories used by background jobs, which are separated at the type level: a tenant-scoped consumer cannot call a cross-tenant method.
- Object storage keys are namespaced per tenant and per signing request, and the tenant prefix is applied by one code path that fails rather than writing an unscoped key.
A.2 Encryption
- In transit — TLS for all external connections, with certificates issued and renewed automatically. Internal service-to-service calls are authenticated.
- At rest, object storage — server-side encryption with AWS KMS-managed keys, applied as a bucket default on both buckets, so an object cannot be written unencrypted.
- Signing keys — the organisational seal private key is generated in and never leaves a cloud hardware security module. The application holds only a reference to the key version and the matching public certificate, and verifies at startup that the two correspond.
- At rest, database — the managed PostgreSQL service encrypts all data at rest, including automated backups and replicas, using provider-managed keys. Customer-managed encryption keys (CMEK) are not configured.
- Database connection — the application connects through an authenticated proxy over a private network address, so database traffic does not traverse the public internet.
A.3 Backup and recovery
The managed database service takes automated daily backups and retains write-ahead logs for point-in-time recovery, so the database can be restored to a chosen moment rather than only to the last backup. Backups are encrypted at rest by the same mechanism as the live database. The service retains seven daily backups and seven days of write-ahead log for point-in-time recovery.
Backups are not a route around erasure. Where the Controller instructs erasure under Section 11.2, the data is removed from the live database immediately and from backups as those backups expire in the ordinary cycle. A backup is never restored selectively to recover erased personal data.
Object storage is separately durable by design and versioned for completed signed documents; see A.4.
A.4 Retention-locked storage of signed documents
Completed signed documents and finalised invoice PDFs are stored in a versioned bucket with object-lock retention in governance mode. The credential the application uses in normal operation cannot delete or overwrite a locked version.
Erasure is performed by a separate identity whose only additional privilege is the ability to bypass governance retention. It is wired into the two background services that erase, and nowhere else. This separation means that no ordinary application fault, and no compromise of the application's normal credential, can destroy a signed document.
Governance mode is chosen over compliance mode: compliance mode would make Article 17 erasure impossible for everyone, including the Processor.
A.5 Access control and authentication
- Identity and access management through Keycloak, with two separate realms — one for customer administrators, one for platform operators — and separate session scopes. A session cookie from one realm fails closed against the other.
- Role-based permissions enforced at two layers: on every route, and again when rendering each affordance in the interface.
- Multi-factor authentication is required for every administration-portal and operator account, and enrolment is enforced at sign-in. On the Controller's request the Processor's operators can reset a user's second factor so that the user enrols again: the reset ends the user's sessions, applies to every organisation the user belongs to, is recorded in the audit register, and is notified to the user by email.
- Access tokens are held server-side in a session store; the browser holds only an opaque session identifier. Tokens are refreshed server-side and are never exposed to page scripts.
- Password policy and brute-force protection are enforced by the identity provider, including a blocklist of common passwords.
A.6 Application security
- CSRF protection on state-changing requests; strict security headers including a content security policy; a hardened cookie configuration.
- Rate limiting on public endpoints by client address, and per tenant.
- Trusted-proxy handling so that client addresses cannot be spoofed through forwarded headers.
- Server-side rendering with contextual output escaping, which removes the common injection classes by construction.
- Parameterised database queries throughout; no dynamic SQL assembled from user input.
A.7 Logging, audit and data minimisation in telemetry
- An append-only audit register records security-relevant and processing-relevant actions, with actor, tenant, action and timestamp. It is partitioned by time and swept under a three-class retention policy; records classified as permanent are never deleted.
- Personal data is excluded from application telemetry by policy and by review: error messages, log messages, metric labels, health-probe output and outbound request logs carry opaque identifiers only, never email addresses, names, national identifiers or IP addresses. Sentinel error values are used instead of interpolating the offending value. The ingress access log is the one operational record that carries the client address and browser identification of each request; it is outside the audit register.
- Metric labels never carry identifiers.
A.8 Segregation of environments
Development and production are separate deployments with separate credentials. Development uses generated test certificates and a local timestamp service, and never holds production data. Production configuration is asserted at startup, and the deployment refuses to boot on a configuration that would weaken a security control.
A.9 Change management
All changes are version-controlled and code-reviewed. Database schema changes are applied by a single migration runner that must complete before any application service starts. Dependency vulnerability scanning and architectural boundary linting run as part of the pre-merge routine.
A.10 Personnel
Personnel with access to Controller Personal Data are bound by confidentiality obligations under Section 4, and access is limited to those who need it to provide the Service. Production access is held by named individual cloud identities rather than shared accounts.
The procedure for granting, reviewing and revoking that access is a written internal document: named identities with multi-factor authentication, approval by a person other than the requester or, where the team makes that impossible, acknowledgement of the grant by a second person, a quarterly review of every holder against the administering system, and same-day revocation with rotation of shared credentials when a person leaves.
A.11 Security alerting
Alert rules are evaluated continuously over the platform's metrics and delivered to the Processor's on-call address. Beyond availability, cost and certificate expiry, they cover:
- failed-authentication spikes — at the identity provider, across both realms, and at the portals' sign-in callback, where a forged or replayed callback would appear (as would a burst of expired or abandoned sign-ins; the threshold is what separates the two);
- document-access volume — downloads and previews of documents, signed documents and invoices by administrators and operators, when an hour's volume exceeds both an absolute floor and three times the trailing day's hourly average (a signer's own view of the document being signed is neither audited nor counted);
- use of the erasure credential — a governance-bypass deletion by the platform's erasure identity in an hour when no erasure flow of the platform ran on that service.
Boundaries. Volume alerting is platform-wide; attribution to an account is a query over the audit register, not an alert. The erasure-credential rule observes the platform's own processes and counts only deletions the object store accepted; a credential used from outside the platform is visible only in the cloud provider's access logs, which are not alerted on. Thresholds are initial values.
Part B — Measures inherent in the Service the Controller should note
- The Processor cannot read document contents in the ordinary course, but the contents are not end-to-end encrypted: they are decrypted server-side in order to be sealed. A Controller requiring that the Processor be technically incapable of reading contents should not treat this Service as meeting that requirement.
- Erasure is irreversible and is not preceded by a recovery window.
- The public verification page discloses that an erased signing request existed, by reporting it as erased rather than as unknown. See Section 11.3.
- A signature attests that a verified national electronic identity signed a slot, not that a named individual did. The signing link is a bearer credential for the life of the request, and the Controller is responsible for delivering it to the intended person. Section 4.3 of the Terms of Service sets this out in full.
- A signing request already sent survives suspension of the Controller's account. Signers holding a valid link can still complete it while the administration portal is closed to the Controller. Section 6.2 of the Terms of Service explains why.
Part C — Controls not currently implemented
Listed so the Controller can assess the risk accurately.
| Control | Status |
|---|---|
| ISO/IEC 27001 certification | Not held. |
| SOC 2 report | Not available. |
| Independent penetration test | Not carried out. An internal security audit exists; no third-party assessment has been performed. |
| Written information security policy | Exists as an internal document indexing the controls in Part A and the gaps in this Part. Not independently assessed. |
| Documented production access review | Exists as an internal procedure (A.10). No review has yet been recorded under it. |
| Security alerting | Implemented for the three signals in A.11. Not covered: cross-tenant queries, sign-ins from unusual locations, and use of any credential from outside the platform. |
| Written incident response plan | Exists, covering breach classification, the processor/controller notification split, the 48-hour commitment in Section 9, and per-scenario containment playbooks. Not yet exercised, so its timings are designed rather than demonstrated, and the escalation contact list is not yet complete. Detection relies on the alerting in A.11 and on external notification: a quiet intrusion using a valid credential is not alerted on, and the 48-hour clock in Section 9 runs from awareness. |
| Disaster recovery / business continuity plan | Exists as an internal document. Never exercised — every recovery time in it is a design target, and no restore drill has been run. |
| End-to-end encryption of document contents | Not implemented by design — see Part B. |
Annex III — Subprocessors
| Subprocessor | Purpose | Location of processing |
|---|---|---|
| Google Cloud EMEA Limited | Managed PostgreSQL database (Cloud SQL) holding all structured personal data: signing requests, signers, users, authentication evidence and audit records | europe-north1 (Hamina, Finland) |
| Google Cloud EMEA Limited | Hardware security module (Cloud HSM / Cloud KMS) holding the organisational seal private key. No document content is transmitted; the service receives only a hash to be signed | europe-north1 (Hamina, Finland) |
| Google Cloud EMEA Limited | Compute hosting for the application services, on the same private network as the database | europe-north1 (Hamina, Finland) |
| Amazon Web Services EMEA SARL | Object storage for uploaded documents, completed signed documents and invoice PDFs, encrypted with AWS KMS-managed keys | eu-north-1 (Stockholm, Sweden) |
| Idura ApS | Electronic identification broker connecting to the national eID schemes. The active broker | Copenhagen, Denmark |
| Signicat AS | Electronic identification broker, the alternate to Idura ApS. Processes no Controller Personal Data unless it replaces Idura, which is a change notified under Section 6.2 | Trondheim, Norway |
| SK ID Solutions AS | Qualified electronic timestamp authority, and issuer of the organisational seal certificate. The timestamp authority receives only a cryptographic hash, never document content | Estonia |
| Scaleway SAS | Transactional email to signers and administrators. Receives signer and administrator email addresses, names, the subject and body of service notifications, and the signed document or invoice PDF attached to completion and invoice emails | fr-par (Paris, France) |
Changes to this Annex are notified under Section 6.2.
Note on the two eID brokers. The Service supports both Idura and Signicat, and exactly one is active: Idura ApS. Signicat AS is named because the active broker can change, and such a change is a subprocessor change under Section 6.2.
Note on what is not a subprocessor. Several components of the Service are operated by the Processor on its own infrastructure and are not third parties: the document rendering service, the signature augmentation service, the cache, the event stream and the identity and access management platform. They run inside the Processor's own deployment, within the regions named above, and engage no one else.
Note on timestamp authorities. The Service uses separate timestamp configurations for the signing timestamp and the archive timestamp, which may in future be different providers. Any change to either is a subprocessor change under Section 6.2, even though a timestamp authority receives only a hash.