LAW FIRM DATA SECURITY

A Server in the OfficeIs Not a Security Strategy

Physical possession of law-firm data is not the same as legal and technical control. Compare on-premises and external systems through identities, updates, keys, backups, recovery and evidence.

READING KEY

Professional secrecy
Law-firm security
Backups
Encryption
Cloud services
Email

Abstract. A server behind a locked door may be part of a sound security architecture, but it is not evidence of one. A law firm is only as secure as its control over identities, updates, keys, backups, recovery and incidents, whether those capabilities are maintained internally or supplied by a properly assessed provider. Nor is a managed external service secure merely because it is professional, European or certified. On-premises and external systems allocate responsibility differently. The proper choice is therefore not an ideological contest between the office and the cloud, but a documented comparison of risks, capabilities and evidence under the applicable duties of professional secrecy and data protection.

Two decisions by the same lawyer

The conversation begins with a backup. A lawyer says that he does not want to put case files in the cloud. He does not know who might gain access to them, where they would be stored or whether a provider would keep its promises. Professional secrecy and data-protection obligations make it seem safest to keep everything on a server in the office.

A few minutes later, the conversation turns to ordinary work. The lawyer sends draft contracts, annexes and letters to clients by email. When a client needs to review a larger file, he sends a link or several attachments. This does not feel like a decision to use the cloud. It feels like routine office communication.

Both actions are, in fact, technology decisions. Remote infrastructure is visible in an external backup and therefore attracts scrutiny. In email, the same kind of infrastructure disappears into habit. A message may travel from the sender’s device and mail server through filters and other intermediaries to the recipient’s provider, phone, laptop, archive and backups. An attachment may then exist in more places than the document the lawyer refused to store in one controlled external service.

This is not a story about an inconsistent lawyer. It is a story about how difficult risks are to compare when one infrastructure is new and named, while the other is old, familiar and largely invisible. Caution towards an external provider is reasonable. It does not follow that everything kept in the office is secure, or that everything leaving it is impermissible.

Consider a fictional case file concerning a dispute between company members. It contains employees’ personal data, bank statements, emails, a draft settlement and the company’s business strategy. The file might remain on an on-premises server without a usable external backup. It might have a separate encrypted copy held by an external storage provider. It might reside in a managed document service, travel by email, or have an extract sent to an external artificial-intelligence model. The starting case file is the same, although the model receives only an extract. What changes are the recipients, keys, copies, administrators, recovery options and evidence.

The Slovenian and European sources reviewed for this article do not impose a general rule requiring either “on-premises” or “cloud”. They require appropriate measures, professional care and demonstrable accountability. Technology adds an uncomfortable fact: physical proximity alone does not reveal who can read the data, whether the file can be recovered tomorrow, or who will notice an attack at three in the morning.

The opening scene is a composite professional observation. It does not describe any identified firm or client and is not a representative study of Slovenian lawyers’ practices.

What are we actually protecting?

Three distinct questions are often collapsed into one when lawyers discuss a case file.

The first is professional secrecy. Article 6 of Slovenia’s Zakon o odvetništvu, the statute governing the legal profession, requires a lawyer to protect as secret what a client has entrusted to them; the duty also applies to other people working in the firm. The Kodeks odvetniške poklicne etike — described here, unofficially, as the Slovenian Code of Professional Conduct for Lawyers — treats professional secrecy broadly. It covers confidential knowledge about a client and the case file as a whole, continues after the representation ends and applies to the handling of archives. Its provisions on office organisation and file retention do not prescribe a server brand or architecture, but they do require orderly and conscientious practice.

The second is data protection. The General Data Protection Regulation (GDPR) governs the processing of information relating to an identified or identifiable natural person. An employee’s name, email address, salary or health condition is therefore a different legal category from a company’s business plan as such. A legal case file may nevertheless contain both, sometimes in the same sentence. Slovenia’s Zakon o varstvu osebnih podatkov — the Slovenian Personal Data Protection Act, or ZVOP-2, in descriptive and unofficial English — supplements the Slovenian framework. It contains no general exemption for encrypted or locally stored content.

The third consists of other forms of confidentiality: trade secrets, contractual duties, litigation strategy and information whose disclosure would harm the client even though it describes no identifiable natural person. The highest settlement amount a company is prepared to accept may fall outside the material scope of the GDPR and still be acutely sensitive.

“Is this personal data?” is therefore not enough. The firm must know what it is protecting, from whom, under which duty and throughout the file’s lifecycle. In Decision U-I-115/14, Up-218/14, the Constitutional Court of the Republic of Slovenia emphasised the constitutional significance of a lawyer’s privacy and confidential lawyer–client communications. The decision does not tell a firm which server to buy. It explains why infrastructure is more than an ordinary purchase of office equipment.

The server behind a locked door

An on-premises server has an obvious advantage: the firm can see it. It can point to the room, the cabinet, the key and the person permitted to enter. The machines used by an external service are remote, the people are unfamiliar and the architecture is described in documents. The feeling of direct control is therefore not imaginary.

But the key to the room answers only one question: who can physically enter. It does not reveal who has the administrator password, whether a former IT maintainer can still connect remotely, when the operating system was last patched, where logs are written, or whether a backup exists outside the same building. Nor does it show whether the disk is encrypted, where the recovery key is held, or how many hours or days the firm would need to resume work.

An on-premises deployment may be an excellent choice. It can give the firm direct control over access, network connections, copies and retention periods. For some highly sensitive tasks, it may remove an external recipient who cannot be controlled with sufficient confidence. Those advantages arise only through maintenance. A server that no one regularly patches, monitors and tests is not a sovereign system. It is concentrated responsibility.

The same qualification applies to an external route. A data centre with controlled entry, redundancy and a permanent operations team may provide capabilities that would be expensive or organisationally unattainable for a small firm. Its existence does not protect a misconfigured user account, a publicly shared link or an application that creates unnecessary copies. An external service can professionalise part of the infrastructure. It does not automatically professionalise every decision made by its customer.

The first important distinction is therefore simple: location is a property of a system; security is a set of capabilities that someone must perform continuously.

Nine invisible capabilities

Replacing the word “secure” with operational questions makes the comparison far less ideological. Every firm needs at least nine capabilities, whether its machines are in the next room or in a data centre.

Inventory. Someone must know which devices, applications, accounts, remote-access routes, data stores and copies exist. An unknown server under a desk and a forgotten former employee’s account are as real as an unknown sub-processor used by an external provider.
Identities and privileges. An everyday account should not carry full administrative rights. Multi-factor authentication should protect important accounts, access should be attributable to a named person, and privileges should be revoked when that person leaves. A shared “administrator” password does not become safer because it is used only in the office.
Updates. Operating systems, firewalls, storage devices, applications and remote-access tools receive security patches. Someone must monitor notices, assess urgency, test the change and install it within an agreed timescale. A patch that exists only on a manufacturer’s website protects nothing.
System separation. A trainee’s infected laptop should not automatically open a path to every case file, administration tool and backup. Separation of networks, roles and privileges limits the extent of a failure. The same principle applies in the cloud: one compromised account should not permit both the reading and permanent deletion of everything.
Backups and restoration. A backup must survive the failure that affected the original and must be restorable. The UK National Cyber Security Centre (NCSC) advises small organisations to copy the data they need and to know how to restore it; an external storage device should not remain permanently connected after the copy is made. For an online backup, the critical controls include separate access, protection against mass deletion and tested restorability.
Encryption and keys. “The data is encrypted” is not enough. The firm must know where encryption occurs, who holds the key, who can request a reset, whether a protected backup of the key exists and what happens when its only administrator leaves. Poor key management can cause disclosure or the permanent loss of an otherwise intact archive.
Monitoring. Logs and alerts should expose unusual access, mass export, deletion, failed logins or failed backups. Someone must receive and understand them. A log that an attacker can erase with the primary system is weak evidence of an incident.
Incident response. The firm should know in advance who disables a compromised account, who calls the IT maintainer, who preserves evidence, who assesses risks to clients and who fulfils any obligations under data-protection law. A telephone number answered only during a sales presentation is not an incident-response plan.
Exit and continuity. The firm must know how to retrieve the case file, metadata, keys and necessary settings if a provider or maintainer ceases operating. An on-premises system has exit risk too: physical ownership of the hardware does not ensure continuity if only one external person knows how to restore it.

Article 32 of the GDPR does not prescribe this nine-part list. It does, however, expressly require measures appropriate to risk and refers to confidentiality, integrity, availability, resilience, timely restoration and regular testing of effectiveness. Its logic is closer to a list of capabilities than to a map of locations.

Threats do not care where data is stored

The case for an on-premises server is sometimes built around physical burglary: an attacker would have to enter the office and carry the machine away. That is a real danger, but it is not the only one, and without evidence it cannot sensibly be declared greater or smaller than the alternatives.

A convincing fraudulent message may let an attacker take over a mail or administrator account. Ransomware may reach workstations, the server and a permanently connected backup. An unpatched remote-access service may open the door without a physical visit. An employee may send a document to the wrong address or grant access through a public link. Fire, water, electrical failure or a failed disk may affect both the primary device and a copy kept in the same room. Excessive privileges held by an IT maintainer may create an internal or supplier route to every matter.

Provider infrastructure has its own threats: a customer misconfiguration, an incident at the provider, a supply-chain vulnerability, unauthorised support access, difficulty leaving the service or failed recovery. The word “cloud” removes none of them.

SI-CERT reported 4,587 incidents in 2024, seven per cent more than in the previous year, and discussed vulnerabilities, data theft, ransomware and advanced impersonation targeting businesses. These are not statistics about law firms and they do not establish which threat is most common for them. They do show that a firm operates in an environment where remote attack and human error are not theoretical scenarios.

The common point is even clearer for backups. The NCSC explains that neither on-premises nor cloud backups are resistant to ransomware by default. Attackers try to discover and destroy backups before encrypting primary data. A sound backup must therefore separate at least some identities, privileges and deletion paths, while retaining recoverable versions.

A useful rule is stricter than “keep a backup”:

The primary system and its only usable backup should not share the same failure, account, administrator, location and mass-deletion path.

On-premises and external systems allocate responsibility differently

When a firm buys a server, the work does not become ownerless. The firm performs the tasks itself or assigns them by contract to an IT maintainer. That maintainer may install patches, manage administrator accounts, read logs, create backups and connect remotely. The server is on the premises, while privileged control over it may be external.

The boundary moves in an external service. If the firm rents only a virtual server, the provider will ordinarily manage the building, power supply, underlying network and physical hardware, while the firm or its maintainer still manages the operating system, application, firewall, users and data. In a fully managed document application, the provider may also assume responsibility for application patches, part of the backup process, monitoring and availability. The precise allocation depends on the service and the contract.

The NCSC’s cloud shared-responsibility model does not describe the cloud as a transfer of all security. Provider and customer have different tasks, and a managed service provider may become a third participant. The firm will almost always remain responsible for choosing an appropriate service, deciding which data may be placed in it, controlling user permissions and multi-factor authentication, configuring sharing, establishing a legal basis and contractual relationship, acting on alerts and planning its exit.

The parties’ actual roles matter in law. If a provider processes personal data on the firm’s behalf, it must offer sufficient guarantees and the relationship must be governed by a contract or other legal act under Article 28 of the GDPR. The final EDPB Guidelines 07/2020 stress that controller and processor roles are determined functionally and that a contract should not merely restate the Regulation: it should specify how the obligations will be fulfilled.

A data processing agreement is a necessary part of the route, not a licence for arbitrary disclosure. It does not decide for the lawyer whether the entire case file had to be sent, whether the selected function is suitable for the sensitivity of the data, or whether support access and transfers are acceptable. A certificate does not repair a publicly shared folder; a contract does not enable multi-factor authentication.

Cost is equally meaningless without a comparable scenario. The on-premises route includes the purchase and replacement of hardware, electricity, space, licences, maintenance, monitoring, backups, recovery exercises and downtime. The external route includes subscriptions, implementation, identity management, support, migration, contractual review, export and exit. A specialised provider may combine some capabilities more efficiently, but that does not make every external offer cheaper or more suitable. Without the size of the firm, the volume of data, the required recovery time and a comparable level of protection, a numerical table would be rhetoric rather than analysis.

Five routes for the same case file

The same file may use several routes. Their locations alone do not rank their safety; compare the actual controls and evidence for each use.

A comparison becomes useful only when the same questions are applied to the same case file and the same target level of protection. The following table is not a ranking. It shows how recipients, responsibilities and required evidence change across five common routes.

Route	Who may be involved	Principal advantage	Typical failure	Evidence the firm should see
On-premises server without an independent backup	employees, local administrator, external IT maintainer	direct physical and configuration control	one location, account or attack affects both work and recovery	inventory, supported versions, patching timescales, administrators, logs and a successful restoration test
On-premises system with a separate encrypted external backup	firm, maintainer, holder of the ciphertext	primary data remains on the premises and the copy does not share the same physical point of failure	one compromised account deletes both routes, the key is lost, or restoration is untested	client-side encryption, recovery-key management, versioning, deletion protection, locations and evidence of restoration
Managed European service	provider, possible managed service provider, sub-processors and users	specialised operation of infrastructure and, depending on the service, the application	misconfiguration, compromised account, unclear allocation of tasks or difficult exit	contract, technical schedule, certified scope, access, sub-processors, locations, backups, export and erasure
Email or secure portal	mail or portal providers, filters, recipients, devices and archives	everyday convenience, with the possibility of recipient-specific content encryption or more controlled access	transport security is mistaken for content confidentiality, the wrong recipient is selected, an account is compromised or a link is public	transfer method, content protection, identities, recipients, keys, access period and revocation, logs, copies and retention
External artificial-intelligence model	model service, platform, hosts, tools and sub-processors	powerful processing without maintaining model infrastructure	transport encryption is mistaken for the absence of access to readable content	approved service and function, purposes, retention, locations, sub-processors and local data minimisation

An on-premises server can be appropriate if the firm genuinely performs all nine capabilities and has an independent means of recovery. The first route, as described here, lacks that independent recovery. It may combine the primary system with its failure: the device is nearby, but continuity is not assured.

The second route can be a strong combination. It gives the firm direct control over the working environment while separating a copy from a fire, theft or failure in the same building. Its quality depends on whether the provider really receives only ciphertext, whether one account can delete every version, whether the firm holds a recovery key and whether it has successfully restored the whole case file into a test environment.

The third route may transfer physical security, redundancy, some patching and some monitoring to a specialised provider. “European” still tells only part of the story. The firm must examine the contractual entity, primary and backup locations, support access, sub-processors and transfers to third countries. Chapter V of the GDPR is not disabled by the address of one data centre.

The fourth route shows how quickly the standard of review can change. Email is often judged by habit and a portal by its marketing label. The better questions are who verifies identity, whether only the connection or also the content is protected for a named recipient, where copies arise and how long they remain. A well-protected email route may be appropriate for some content. A poorly configured “secure portal” is not appropriate merely because it carries that name.

The fifth route is not simply storage. An ordinary external model needs the document in a form on which its execution environment can compute. The claim that a provider holds only an unreadable archive therefore cannot simply be carried over to that route. Data minimisation, local pseudonymisation and a properly assessed business service can materially reduce risk, but the complete model data path is a separate question, examined in more detail in Confidentiality Does Not End at the Chat Window.

These routes need not be selected as five mutually exclusive packages. During active work, the same file may remain on a properly maintained on-premises system, have a separate encrypted backup held externally and be exchanged with the client through a time-limited portal. The firm might use an approved external model service for a public legal question while closing that route to confidential factual material. A hybrid arrangement is not inherently superior. It does allow each task to be assigned to a route that can be justified for that task.

This also requires a clear answer to which copy is the authoritative working file. If an employee downloads a document from a portal, edits it on a laptop, sends it by email and then saves it back to the server, versions may arise with different permissions and retention periods. Security architecture therefore governs not only devices but the document lifecycle: where a document is created, who changes it, which version is authoritative, where it is archived and which surplus copies are removed.

No row has a permanent status of “secure”. What may be appropriate is a specific system, in a specific configuration, for a defined file and task, operated by people who actually perform the documented procedures.

What a certificate proves

A lawyer is right to demand evidence from an external provider. The problem begins when one item of evidence is made to answer every question.

ISO/IEC 27001:2022 specifies requirements for an information security management system. Its official description emphasises risk management and the integration of people, policies and technology. A certificate within a defined scope may therefore show that an organisation has established such a management system and had it independently assessed.

It does not, by itself, show whether the customer enabled multi-factor authentication, configured public links correctly, selected the appropriate service type or tested restoration. It creates no legal basis for processing, does not automatically disclose every sub-processor and does not mean that an incident cannot occur.

Hetzner is useful only as an illustration of that boundary. At the research cut-off date of 10 September 2026, its official certification page stated that its information security management system was certified to ISO/IEC 27001:2022, within a defined scope covering its hosting services and listed data centres in Germany and Finland. That is relevant provider evidence. It is not a product recommendation, an assessment of an individual customer deployment, or proof that every use satisfies a lawyer’s duty of professional secrecy.

Article 42 of the GDPR likewise states that certification mechanisms under the Regulation do not reduce the responsibility of controllers and processors. Evidence must therefore be read with its scope, date, issuer, exceptions and the tasks that remain with the customer.

Encryption: an archive is not a model

The claim that an encrypted document is no longer the original document and therefore falls outside the GDPR or ZVOP-2 is too broad. Encryption can materially reduce risk and may change the position of a particular recipient, but the legal result is not identical for every participant.

Four things should first be separated. Encryption in transit protects data moving between systems. Disk encryption protects stored data in defined circumstances, but the provider may still hold the key. With client-side encryption, the firm converts the document into unreadable ciphertext before sending it to the storage provider and retains the key in its own environment. External model processing is different: the execution environment ordinarily needs the content in a readable form in order to generate a result.

For the law firm that holds the key and knows the client to whom the document belongs, the encrypted file remains identifiable. It is still personal data if it contains information about an identifiable natural person, and it remains protected by professional secrecy. The fact that it appears as unreadable characters on the provider’s disk does not remove the firm’s ability to recover the original content.

The position of the external storage provider may be more complex. Recital 26 of the GDPR requires an assessment of the means reasonably likely to be used for identification. In Case C-582/14, Breyer, the Court of Justice of the European Union underlined the contextual nature of that assessment. In its judgment of 4 September 2025 in Case C-413/23 P, EDPS v SRB, the Court further explained that pseudonymised data are not necessarily personal data for every person in every circumstance; the actual means reasonably likely to be used by the particular recipient to attribute the data to an individual are material.

Encryption and pseudonymisation are not the same technical operation. Nor did either judgment decide the ordinary case of a law firm’s cloud backup. They are relevant to that scenario as interpretative starting points on relative identifiability, not as direct authority that every item of ciphertext falls outside the GDPR.

The latter judgment concerns Regulation (EU) 2018/1725, which applies to Union institutions and bodies. The Court interpreted the materially related concepts consistently with the GDPR. It does not follow that a provider lacking a declared key can never receive personal data. The assessment must consider whether the provider can obtain or reset the key, whether the application offers previews, which metadata is visible, which other datasets are available, who provides support, and which legal or technical routes to attribution actually exist.

The timing of the sources also matters. At the research cut-off date, the EDPB Guidelines 01/2025 on Pseudonymisation were still marked as a version for public consultation and pre-dated the judgment. Their cautious approach remains important, but should not be presented as the final answer to every situation involving an encrypted storage provider.

In July 2026, the EDPB also published draft Guidelines 02/2026 on Anonymisation. They take account of C-413/23 P and discuss identifiability in the context of the particular entity. They too remained under public consultation at this article’s research cut-off and do not decide the ordinary case of a law firm’s encrypted backup.

For the firm, the practical conclusion is less exotic than the legal dispute. Client-side encryption is a powerful safeguard only where the provider does not need the content and the key remains under the firm’s effective control. The firm must still protect metadata and the user account, maintain a recovery key, restrict deletion, test restoration and address the contract and professional secrecy. If the key is lost, excellent cryptography may destroy availability. If an attacker obtains it together with the account, the apparent separation may disappear.

Encryption also has a tangible legal effect. Under Article 34(3)(a) of the GDPR, notification to data subjects is not required for a particular breach where the affected personal data were rendered unintelligible to unauthorised persons by the measures applied. That does not mean there was no incident, that it need not be assessed and documented, or that every other obligation disappears. It does show that effective encryption is a serious safeguard rather than a sales label.

The decisive technical distinction remains purpose. A storage provider can perform its task using unreadable ciphertext. An ordinary external language model must compute over the content. Archiving and model processing are therefore different data paths even when both services advertise “encryption”.

Return to the lawyer who refuses to place documents in the cloud but sends them by email. That decision is not necessarily wrong. It is wrong only if email is not treated as an external route with its own recipients, copies and failure modes.

In ordinary delivery, a message does not necessarily travel directly from the lawyer’s device to the client’s. The route may involve the mailbox provider, outgoing and incoming servers, malicious-content filters, archives, mobile devices and backups. If the recipient forwards the message or saves its attachment elsewhere, the route expands again.

STARTTLS for SMTP allows encryption of a connection between mail servers. It is not, by itself, end-to-end content encryption between sender and final recipient. The classic mechanism also accommodates circumstances in which delivery may continue without TLS and is susceptible to downgrade attacks. MTA-STS uses an authenticated policy to reduce some attacks on transport security. It does not protect a compromised mailbox, an infected laptop, a mistaken recipient or a copy on the recipient’s device.

The content itself can also be protected. In recipient-specific encryption, software locks the document to the recipient’s public key; the corresponding private key, which remains with the recipient, can open it. A digital certificate is not a private key and is not encryption in itself. It is an electronic credential that binds information about its holder to a public key. Signing and encryption have different purposes. Under S/MIME, a digital signature protects message origin and integrity, while encryption protects confidentiality. The public/private key system is a technical design. The present legal framework for electronic identification, signatures and trust services is principally formed by the eIDAS Regulation and Slovenia’s Zakon o elektronski identifikaciji in storitvah zaupanja (ZEISZ), descriptively rendered here as the Slovenian Electronic Identification and Trust Services Act. Referring only to the earlier ZEPEP framework is therefore insufficient, and none of these legal instruments makes a signed message confidential merely because it was signed.

Estonia shows how that technical possibility can become an everyday procedure. The state-supported DigiDoc4 application lets a sender locate an individual by personal identification code, or an organisation by registry code or name, encrypt a .cdoc document container for that recipient, and send it even through ordinary email. The container is not opened with an email password, but with the appropriate Estonian ID card or digital identity and its private key. This need not encrypt the whole email: the provider may still see the sender, recipient, time and usually the subject line, while the document content remains unreadable. DigiDoc describes this encryption as a secure-transfer mechanism, not a long-term archive. Following a card replacement or certificate renewal, an old container may become inaccessible unless another designated recipient can open it.

Estonia’s advantage is not only cryptography. The eesti.ee State Portal issues every Estonian citizen and entrepreneur an official email address, activated on first login, and provides an official inbox for important state communications. Slovenia has the secure electronic mailbox in Moja eUprava and the central SI-CeV electronic-delivery system. A user must set up the mailbox, however, and its documented use is principally tied to service in proceedings by authorities participating in the system. It is not a general channel for everyday exchanges between lawyers and clients. Slovenia therefore has important components, including SIGEN-CA certificates, but not a comparably unified and widely used workflow in which a lawyer without specialist technical knowledge can find a client’s verified public key and encrypt a document for them.

Content encryption is therefore no reason to declare email secure without further analysis. It does not prevent selection of the wrong recipient, theft of a private key, compromise of an endpoint, creation of an unprotected decrypted copy, or loss of access following certificate renewal. Where the firm or recipient can still attribute the document to a person and decrypt it, encryption does not stop it being personal data.

The most practical questions are consequently quite ordinary. Is the mail account protected by multi-factor authentication? Can staff recognise a fraudulent login page? Is automatic forwarding controlled? Does a sensitive attachment require encryption for a verified recipient, and has that recipient’s public key been authenticated? Is the decrypted copy protected afterwards, and does the mailbox retain the document longer than necessary?

The NCSC’s guidance for small organisations treats email as an important target because mailbox compromise exposes sensitive information and opens routes into other accounts. It recommends strong authentication, review of access and secure devices. This is not a rule that a confidential document must never be emailed. It is a reminder that an everyday channel deserves the same scrutiny as a new service.

Where no shared recipient-encryption workflow is available, a secure portal may reduce the spread of attachments, verify identity, record downloads, limit access in time and allow a link to be revoked. But a portal also has a provider, administrators, copies, user accounts, retention periods and possible misconfigurations. Its advantage must be visible in the actual architecture, not in the adjective “secure”.

What the firm must prove to itself and its provider

A small firm does not need its own security operations centre in order to ask the right questions. It does need a clear allocation of tasks, adequate evidence and regular review. Before selecting or renewing an on-premises or external route, it should be able to answer at least the following:

Which devices, applications, accounts, remote-access routes and copies contain case files?
Who has ordinary, privileged and recovery access, and how are those privileges granted and revoked?
Are important accounts protected by multi-factor authentication, and are protected recovery routes available?
Who monitors vulnerabilities, within what period are critical patches installed, and how is that work recorded?
Can a backup survive hardware failure, ransomware, mass deletion and loss of the primary premises?
When was the last successful restoration of a complete matter, rather than one randomly selected file?
Who creates, stores, uses, rotates and recovers encryption keys?
Which providers, maintainers and sub-processors participate, in which locations and with what access?
What precisely does the data processing agreement govern, and which tasks remain with the firm despite it?
Who receives an alert, who leads the response and who performs the legal assessment after an incident?
How does the firm export the file, metadata and logs, and how are its data erased by the previous provider?
Which document, record or test supports each answer, and when was it last verified?

The answers should not exist only in a proposal or one person’s memory. A minimum record can identify the responsible person, provider, deadline, system, evidence and date of the last test for each task. Evidence of recovery is a successful restoration test. Evidence of access control is a review of users and logs. Evidence of certification is the actual certified scope. Evidence of exit is a completed export or exercise, not merely a contractual promise.

This is where the OpenLegalCore principle evidence before promise becomes useful. In security, “the data stays with us”, “the servers are in the EU” and “everything is encrypted” are too broad. Each statement needs a narrower meaning: which data, held by which entity, in which configuration, under which key, supported by which test. This is not a proposal for a new OpenLegalCore product or a claim that an OpenLegalCore security service exists. It is an editorial standard for making decisions.

An institutional gap without an accusation

An individual lawyer may struggle to compare service models, certification scopes, copies, keys, sub-processors and incident-response times. The decision is simultaneously legal, technical, contractual and organisational. If every firm starts from zero, the more cautious may choose an entirely on-premises arrangement while the less cautious may select the first convenient service. Neither extreme guarantees a sound result.

The publicly accessible Kodeks odvetniške poklicne etike supplies a principled basis for office organisation, file retention and professional secrecy. The Slovenian Bar Association’s Rules on Online and Electronic Practice, Article 23, require secure access when a lawyer offers online services to clients and proportionate safeguards for protected data. For cloud storage, the Rules recommend a provider offering the service solely within the EU and require the provider to meet appropriate minimum technical and security standards. They also recommend two-factor authentication for remote access and webmail. These are concrete professional rules. They do not provide a complete comparative framework for the five routes in this article.

The Rules still list EU–US Privacy Shield certification among recommended provider standards. The Court of Justice invalidated the underlying adequacy decision in 2020, so that listing cannot be treated as a current legal basis for transferring personal data.

A review of the Bar Association’s public home page, news, events and publicly visible member-account description up to 10 September 2026 did not establish that it operated a general portal for routine secure lawyer–client exchange. The official Rules were checked separately on 24 September 2026.

That finding has an important limit. A review of public material cannot exclude resources for authenticated members, individual training events, future plans or solutions used by particular firms. The Moja eUprava secure mailbox, SI-CeV and the public entry page for e-Sodstvo, Slovenia’s e-Justice system demonstrate that Slovenian infrastructure exists for particular official routes, not that a general lawyer–client exchange channel exists. It would therefore be unfair to infer that professional or public institutions have “never dealt with technology”.

There is nevertheless room for shared knowledge infrastructure. The first step need not be one mandatory portal. A more useful beginning might include:

a minimum reference security profile for sole practitioners and multi-lawyer firms;
a comparative checklist for hosting providers, processors, external IT maintainers and portals;
a model contractual and technical schedule covering access, backups, keys, incidents and exit;
recommended scenarios for independent backups and recovery exercises;
a verified procedure for locating a public key, encrypting a document for its recipient, and managing lost or renewed keys;
shared training on email, identities, security events and artificial-intelligence data paths;
only then, an assessment of whether a jointly procured or assessed service would provide demonstrable benefits.

The Council of Bars and Law Societies of Europe (CCBE) has published practical materials on lawyers’ information security and their use of artificial-intelligence tools. Those materials do not dictate the right Slovenian solution. They show that professional principles can be translated into technically useful guidance without a Bar association assuming each lawyer’s individual professional responsibility.

Limits of this analysis

This article is not legal advice or a security audit of a particular firm, provider or data transfer. It does not claim that on-premises infrastructure is obsolete, that the cloud is always safer or cheaper, or that email is always inappropriate. It does not mandate ISO certification and does not treat a European location as sufficient evidence of compliance.

The examples describe capabilities and common failure modes. An actual decision depends on the type of matter, sensitivity of the data, purpose, architecture, contractual roles, jurisdictions, staff and provider capabilities. The provider certification scope and publicly visible institutional position were checked on 10 September 2026; the Bar Association’s Rules were checked separately on 24 September 2026. These positions may change.

Nor does the article assess the quality of on-premises and external language models. A confidential data path and the quality of Slovenian legal language are separate criteria. Whether a model capable of running locally understands Slovenian well enough requires separate testing and remains reserved for a future study.

Back to the key

The lawyer from the opening scene still keeps the key to the server room. That is as it should be. Physical access is part of security, and an on-premises deployment allows the firm to control it directly.

But the lawyer must also understand the other keys: the encryption key for the external backup, the recovery account, the maintainer’s administrative privileges, and the procedure that prevents one failure from deleting every version of a case file. The firm must know who installs an urgent patch, who notices an unusual export, who responds to an incident and how work continues if a person or service fails.

The comparison may lead the firm to a predominantly on-premises architecture. It may lead to a managed European service. More likely, different routes will serve different tasks: a local working environment, a separate encrypted backup, a more tightly controlled portal for sensitive exchanges, and external processing only where it is permitted and demonstrably controlled.

That is not a relaxation of confidentiality. It is the abandonment of a dangerous shortcut: that location by itself amounts to control.

The right question is not whether the data are in the office or in the cloud. It is who controls the keys, access, copies, updates and incidents — and whether that control can be proved.

Selected sources

Research cut-off for the legal, technical, institutional and limited provider source set: 10 September 2026. Additional Bar Association Rules check: 24 September 2026.