Technical and Organisational Measures
The security measures SSStudio takes for LeraLink under article 32 GDPR, with the status of each; Annex 2 to the Data Processing Agreement.
AuthorLeraLink Team
Last updated: 12 November 2026
About this document
This document describes the technical and organisational measures that SSStudio, trading as LeraLink, takes to protect the data it processes in providing the LeraLink service. It is Annex 2 to the Data Processing Agreement and is referred to in the Customer Agreement. It also covers the data for which SSStudio is itself controller, such as the platform-wide account.
LeraLink is in a controlled pilot stage, and one person operates the service. Each measure below has a status, so that a reader can see what is in place today and what is not.
| Status | Meaning |
|---|---|
| In place | Built, switched on and in use in production. |
| Built, not yet required | Built and available in production, but not yet mandatory for everyone it is meant for. |
| In preparation | Being introduced or documented; not yet confirmed as in place. |
| Planned | Decided, but not yet built or carried out. |
| Not in place | Not done, and no date has been set. |
SSStudio may change these measures, provided that the overall level of protection does not decrease. A material change leads to a new version of this document.
1. Measures under article 32(1) GDPR
1.1 Pseudonymisation and encryption (article 32(1)(a))
- Data is encrypted in transit with TLS, and Cloudflare encrypts stored data at rest (section 6).
- Sign-in tokens are stored only as hashes; IP addresses and browser descriptions are stored only as keyed hashes (sections 3 and 13).
- Reading statistics are anonymous counts (section 13).
1.2 Ongoing confidentiality, integrity, availability and resilience (article 32(1)(b))
- Confidentiality: phishing-resistant sign-in for administrators, an additional access layer for administration, server-side authorisation for every request, separation of installations, and restricted content that no other person and no AI model can read (sections 2 to 5 and 18).
- Integrity: an append-only audit record, controlled changes through a separate staging environment and owner approval, and automated tests on every change (sections 8 and 9).
- Availability and resilience: Cloudflare's distributed network, read-only and maintenance modes for incidents, external and internal monitoring, nightly backups and point-in-time restore (sections 11 and 12).
1.3 Restoring availability and access in a timely manner (article 32(1)(c))
- A tested restore procedure, with measured figures, and point-in-time restore for destructive changes (section 11).
- Recovery objectives are stated in the Service Level Agreement.
1.4 Regularly testing, assessing and evaluating effectiveness (article 32(1)(d))
- Automated tests on every change, including a check of the authorisation matrix and of public artifacts (section 9).
- Restore rehearsals on a separate copy (section 11).
- Monitoring about every 15 minutes and an external status page (section 12).
- A review of this document at least once a year (section 19).
- An independent penetration test has not yet been carried out (section 19).
2. Access control to systems and data
| Measure | Description | Status |
|---|---|---|
| Single operator with least privilege | Only SSStudio's owner has access to the production systems. Any future staff member or contractor receives only the access their work requires, after a written confidentiality commitment. | In place |
| Access to customer data only when needed | SSStudio accesses data in an installation only to provide the service, to give support the customer asked for, to handle an incident, or to comply with the law. | In place |
| Multi-factor sign-in on provider accounts | Every account with a provider used to run LeraLink (infrastructure, code hosting, email delivery, domain management) is protected by multi-factor authentication or a passkey. | In place |
| Additional access layer for administration | The administration of each installation and of the platform is placed behind Cloudflare Access (Zero Trust), in addition to the application's own sign-in. | In place |
| Separate staging environment | Changes are tested in a separate environment with its own databases, behind Cloudflare Access. It holds no customer installation's data. It may hold a masked copy of SSStudio's own Hub, and restore rehearsals use a separate, temporary copy that is deleted afterwards. | In place |
| No shared accounts | Each person has their own account; accounts are not shared. | In place |
3. Identity and authentication
| Measure | Description | Status |
|---|---|---|
| No passwords | Readers, members and authors sign in with a one-time code sent by email. LeraLink holds no passwords. | In place |
| One-time codes | A code works once and expires within minutes. | In place |
| Rate limiting | Sign-in attempts and other sensitive requests are rate-limited. Counters use a keyed hash of the IP address and are deleted 7 days after their counting window ends. | In place |
| Passkeys for administrators | Administrators of an installation and of the platform can sign in with a passkey (WebAuthn). A passkey is phishing-resistant and bound to the exact administration address. | In place |
| First passkey only through an enrollment link | A person's first passkey can be added only through a single-use enrollment link issued by another authorised person, never from an email-code session alone. | In place |
| Passkeys required for administration | An installation, and the platform, can require passkeys. Email codes are then refused for administration, and sensitive actions (changes to access, ownership, domains, exports, maintenance and incident modes, key management) ask for the passkey again if it was last used more than 5 minutes earlier. | In place for platform administration and the first installations since 3 November 2026; being switched on for the others |
| Hardware security keys | Use of a hardware security key as a passkey has not yet been tested. | Not in place |
| Single sign-on for organisations | Sign-in through an organisation's own identity provider (SAML or OpenID Connect). | Not in place |
| Session limits | Readers and authors: at most 90 days, ending after 30 days without use. Installation administrators with an email code: 30 days without use, at most 90 days. Platform administrators with an email code: 7 days without use, at most 30 days. With a passkey: installation administrators 1 hour without use, at most 12 hours; platform administrators 15 minutes without use, at most 8 hours. | In place |
| Session cookies | Session cookies are host-bound (__Host- prefix), HttpOnly, Secure and SameSite=Lax. The server stores only a hash of the session token. | In place |
| Accepted documents | New accounts accept the Terms of Service and the Privacy Statement after entering a valid code, so only the holder of the inbox sees the question. Which document and version, when and where, is recorded. | In place |
4. Installation isolation and authorisation
| Measure | Description | Status |
|---|---|---|
| Installation resolved from the address | Every request is resolved to one installation from the address it was made to. | In place |
| One server-side decision point | Access is decided on the server by one evaluator that considers the person, their membership, roles and grants, and expiry. An explicit denial wins. | In place |
| Disabled functions are absent | A function that an installation does not have is absent on the server, not only hidden in the interface. | In place |
| Cross-installation requests fail closed | A request that would reach another installation's data is refused. | In place |
| Separation of memberships | One account can belong to several installations; an installation never sees another installation's memberships. | In place |
| Logical separation in shared resources | Installations share the platform's databases and file storage; every record belongs to one installation and is accessed only within it. Dedicated databases per customer are not currently offered. | In place (dedicated resources: not in place) |
| Restricted content | A Piece restricted to named people or roles is readable by nobody else, by any path: not shown, not indexed, not sent, not cached, and never read by an AI model. | In place |
| Continuity of ownership | The last Owner of an installation cannot be removed. | In place |
| Authorisation matrix check | An automated check of who may do what runs on every change (section 9). | In place |
5. Protection of web surfaces
| Measure | Description | Status |
|---|---|---|
| Security headers | Strict Transport Security (HSTS), content-type protection (nosniff), a Content Security Policy and related headers are sent. | In place |
| Public artifact check | Every build is checked so that no source maps, internal dictionaries, internal details in error messages or comments in built pages are published. | In place |
| Security contact file | /.well-known/security.txt is served on every address. | In place |
| Content from other services | Embedded content from other services (such as video platforms and social media) loads only after the reader allows it. | In place |
6. Encryption in transit and at rest
| Measure | Description | Status |
|---|---|---|
| Encryption in transit | All traffic to LeraLink addresses uses TLS. HSTS tells browsers to connect only over encrypted connections. | In place |
| Encryption at rest | Cloudflare encrypts the stored data of the databases, file storage and other storage services used by LeraLink, including backups. | In place |
| Hashing of credentials | Sign-in tokens are stored only as hashes. One-click answer links are stored only as hashes. | In place |
7. Secrets handling
| Measure | Description | Status |
|---|---|---|
| Keys held as encrypted secrets | Keys for providers and services are held as encrypted secrets of the platform's runtime environment at Cloudflare and of the deployment environments at GitHub. They are never stored in the database or in the source code. Production deployment credentials can be used only by a deployment the owner has approved. | In place |
| Secrets referred to by name | The platform administration refers to a key only by its name; it cannot display it. A platform key cannot be attached to a custom AI provider. | In place |
| Restricted outbound use | A custom AI provider can be reached only at a public HTTPS address without credentials in it; requests to it follow no redirect, and headers cannot carry keys or cookies. | In place |
| Rotation | A key is replaced without delay if exposure is suspected. | In place |
| Scheduled rotation | Rotation of keys on a fixed schedule. | Not in place |
8. Logging and audit
| Measure | Description | Status |
|---|---|---|
| Audit record | Every change to people and permissions, every export and other security-relevant actions are recorded in an append-only audit record. | In place |
| Legal hold | The audit record is kept under legal hold, also after an account is deleted, as evidence. It does not contain the content of Pieces. | In place |
| Exports recorded | Every export of an installation and every personal data package is recorded. | In place |
| No content in operational logs | Operational logs are used for troubleshooting and are designed not to contain the content of Pieces or secrets. | In place |
9. Change management and testing
| Measure | Description | Status |
|---|---|---|
| Private source code | Source code is held in a private repository on GitHub. The main branch is protected. | In place |
| Staging first | Every change goes first to a separate staging environment, with its own databases in the European Union. | In place |
| Owner approval | A change reaches production only after the owner approves it in GitHub. | In place |
| Automated tests | On every change: behaviour tests, a check of the authorisation matrix, the public artifact check and a check of translation coverage. | In place |
| Locked dependencies | Builds install software dependencies only from a locked list. | In place |
| Rollback | A release can be rolled back to the previous version. | In place |
10. Vulnerability management and disclosure
| Measure | Description | Status |
|---|---|---|
| Coordinated disclosure | Security researchers can report vulnerabilities to security@lera.link under the Coordinated Vulnerability Disclosure policy. | In place |
| Security contact file | /.well-known/security.txt on every address names the contact and the policy. | In place |
| Fixing reported vulnerabilities | A reported vulnerability is assessed and fixed with a priority that matches its severity, through the same change process as any other change. | In place |
| Automated dependency alerts | Automatic alerts for known vulnerabilities in software dependencies. | In preparation |
| Independent penetration test | An independent penetration test has not yet been carried out. | Planned: second quarter of 2027 |
11. Backup and restore
| Measure | Description | Status |
|---|---|---|
| Nightly backup | A logical backup of the whole database is made every night. Every part of it is checksummed. | In place |
| Backup retention and location | Backups are kept for 30 days in Cloudflare's European Union storage. | In place |
| Point-in-time restore | Cloudflare's point-in-time restore for the databases makes it possible to return to the moment before a destructive change. | In place |
| Tested restore | Restoring is a tested tool. Measured on a copy of production on 31 October 2026, a restore of the database took 24 minutes. Restores are rehearsed on a separate copy, started by hand; there is no fixed schedule yet. | In place |
| Tested platform move | The move of the platform to the European Union storage was rehearsed three times; every row and file was checked. The move itself, on 3 November 2026, took about two hours of read-only maintenance, half an hour of it a first run that stopped before writing anything; without it, about 90 minutes, as rehearsed. | In place |
| Recovery points | For a total loss: the last nightly backup, so up to 24 hours of changes may be lost. For a destructive change: point-in-time restore. | In place |
| Files | Files (images, audio, documents) are stored redundantly by Cloudflare's file storage, but are not separately backed up. A file that a person deletes is removed and cannot be restored by SSStudio. | In place (separate file backup: not in place) |
| Copy with a second provider | Backups are kept with the same provider as the live data (Cloudflare). A copy with a second provider is not yet kept. | Not in place |
| Maintenance runs | Restore rehearsals, the platform move and the masked staging copy of SSStudio's own Hub run on GitHub Actions runners, which process backup data in memory only for the duration of the run; only the masked Hub copy is kept, for one day. GitHub is listed as a subprocessor for these runs. | In place |
12. Monitoring and incident management
| Measure | Description | Status |
|---|---|---|
| External status page | status.lera.link is run on GitHub, independently of LeraLink, and shows whether the platform is up. It shows the platform only, not individual installations. | In place |
| Internal monitoring | An internal monitor checks the platform about every 15 minutes, from outside it, including that administration addresses are protected by the additional access layer, and alerts the operator. It checks the addresses of the installations added to it, not yet of every installation. | In place |
| Read-only and maintenance modes | The whole platform, or one installation, can be placed in read-only mode or maintenance mode to contain an incident or carry out maintenance safely. | In place |
| Written incident procedure | A written procedure describes how incidents are detected, contained, resolved, communicated and documented. | In place |
| Breach notification | A personal data breach affecting customer personal data is notified to the customer without undue delay and in any case within 48 hours of SSStudio becoming aware of it, as the Data Processing Agreement sets out. | In place |
| Breach register | Every personal data breach is documented (article 33(5) GDPR). | In preparation |
| Incident reports | Significant incidents are reported publicly in Updates → Incident Reports on the Hub. | In place |
| 24/7 on-call | One person operates the service; there is no 24/7 on-call. Response targets are set out in the Service Level Agreement. | Not in place |
13. Data minimisation and retention
| Measure | Description | Status |
|---|---|---|
| No passwords held | Sign-in uses one-time codes and passkeys. | In place |
| Hashed identifiers | IP addresses and browser descriptions are stored only as keyed hashes. | In place |
| No analytics cookies | LeraLink sets only sign-in session cookies and two language cookies. There are no analytics cookies and no Google Analytics. | In place |
| Anonymous reading statistics | Reading is counted anonymously; counts are kept up to 3 months, then only totals. | In place |
| Account separate from membership | The platform-wide account and each installation membership are separate; an installation receives only what it needs. | In place |
| Personal data packages hold only what is a person's own | A package someone downloads about themselves contains only what is theirs alone: works with other people on them are not included (their own credit is); under blind review, a reviewer receives their own words and an author receives decisions, but never who reviewed; editors' internal notes are excluded and can be asked for separately. | In place |
| Retention register | The platform applies retention periods from a central register. Sign-in codes and passkey challenges 1 day; used or expired enrollment links 30 days; revoked passkeys 90 days; ended sessions 30 days; rate-limit counters 7 days after expiry; backups 30 days; data packages 7 days; invoices 7 years (by law). Published knowledge is never removed by a general retention process. | In place |
14. Deletion
| Measure | Description | Status |
|---|---|---|
| Account deletion | A person can delete their account. Deletion takes effect after 7 days, can be cancelled in that time, and is checked again on the day. It is blocked, with the reason stated, while the person is the sole Owner of an installation or has an open submission. Published works and credits remain under the published name; what connects that name to a living person is removed. | In place |
| Leaving an installation | Leaving removes the installation's profile, preferences, contact relationship, sessions, roles and grants for that person. | In place |
| Removal of AI-written descriptions | A removal takes the description out in every language and leaves a mark that every automatic process honours. | In place |
| End of a customer agreement | After the data retrieval period, customer data is deleted from live systems, with a target of 7 days and no later than 30 days; backups expire within 30 days after that. SSStudio carries this out as a documented operation; there is no self-service function for it. | In place as a manual procedure |
| Deleted files | A deleted file is removed from file storage at once. | In place |
| Earlier copies outside the European Union | Copies held outside the European Union before 3 November 2026 are kept unwritten until 3 December 2026 and then deleted. | Planned: 3 December 2026 |
15. Subprocessor management
| Measure | Description | Status |
|---|---|---|
| Register | Every subprocessor and every other recipient is listed in Subprocessors and Recipients, with its service, data and location. | In place |
| Assessment before use | A provider is assessed for security, data protection terms, location and transfer basis before it processes personal data. | In place |
| Written terms | Each subprocessor is bound by data protection terms that meet article 28(4) GDPR. | In preparation |
| Notice of changes | Customers receive at least 30 days' notice of a new subprocessor, by email to installation Owners and by an Announcement on the Hub, and may object, as the Data Processing Agreement sets out. | In place |
| Periodic review | Subprocessors are reviewed at least once a year. | In preparation |
16. Personnel
| Measure | Description | Status |
|---|---|---|
| Single operator | One person, SSStudio's owner, operates the service. There are no employees. | In place |
| Confidentiality | The owner is bound by the confidentiality obligations in the customer agreements. Anyone given access in future signs a written confidentiality commitment first. | In place |
| Multi-factor authentication on all provider accounts | All accounts with providers used to run LeraLink use multi-factor authentication or passkeys. | In place |
| Device security | The devices used to operate the service use full-disk encryption, an automatic screen lock and current security updates. | In preparation |
| No customer data on personal devices | Customer data is not kept on the operator's devices, except an export or a restore copy handled temporarily for a specific task and deleted afterwards. | In preparation |
| Continuity | Arrangements for continuity if the operator is unavailable are described in Business Continuity. | In place |
17. Physical security
| Measure | Description | Status |
|---|---|---|
| Data centres | LeraLink runs entirely on Cloudflare. Physical security of the data centres, including access control, power, cooling and fire protection, is provided by Cloudflare, whose certifications and reports cover these controls. | In place (inherited) |
| No servers of SSStudio | SSStudio operates no servers or storage of its own. | In place |
| No paper records | SSStudio keeps no paper records of customer personal data. | In place |
18. AI-specific safeguards
| Measure | Description | Status |
|---|---|---|
| Restricted content never sent | Restricted Pieces are never sent to any AI model. | In place |
| Fixed set of AI tasks | AI is used only for translation, suggested search-engine fields, a generated feature image, the search index, the knowledge layer (naming and describing what published text is about) and a composition assistant that makes proposals only, where it is enabled for an installation. | In place |
| Proposals, not changes | AI output is a proposal, marked as machine-made, until a person accepts it. AI never changes published text, approves translations, decides rights or gives roles. The exceptions (unreviewed search-engine fields marked "needs review"; machine-made concept descriptions and the index) are described in How LeraLink Uses AI. A person's correction always wins. | In place |
| Unreviewed machine translations labelled | Machine translations can be shown to readers before a person has reviewed them; they are then labelled 'AI translation · Not yet human-reviewed'. | In place |
| No training | SSStudio does not train AI models on customer content. It uses providers only on terms under which they do not train on the data sent for the services used. | In place |
| AI policy per installation | Each installation has an AI policy (Standard, EU only, Open models only, No external AI) that is enforced where models are selected, with no fallback around it. A model counts as meeting a rule only when the fact the rule requires has been recorded for it. | In place |
| Recorded facts about models | The facts needed for the policies (country, hosting region, training and retention) are being recorded for each model. Until they are, an installation under the EU only policy has no AI tasks available. | In preparation |
| Transparency to administrators | Installation administrators see a read-only page, 'AI in this installation', listing each AI task, whether it is on, and the models that would run, with their facts. Each task tries its models in a fixed order set by the platform; an installation's administrators can see that order, with each provider, on that page. | In place |
| No prompts or models set by installations | An installation writes editorial instructions only; it never sets a prompt or a model. | In place |
| Visible labelling | AI-generated images and text proposals are labelled in the product. | In place |
| Machine-readable marking of generated images | Machine-readable marking of generated images is being introduced, for example with IPTC metadata or C2PA, in LeraLink's own processing. | In preparation |
19. Assurance and review
| Measure | Description | Status |
|---|---|---|
| Independent penetration test | Not yet carried out. | Planned: second quarter of 2027 |
| ISO 27001 or SOC 2 certification | Not held. SSStudio relies on Cloudflare's certifications for the infrastructure layer. | Not in place |
| Accessibility audit | No independent accessibility audit yet; see the Accessibility Statement. | Not in place |
| Review of this document | SSStudio reviews these measures at least once a year and after any significant incident or change to the service. | In place |
More about the assurance available, and how to ask for it, is in Security Documentation and Assurance.