An introduction in Monaco often arrives by word of mouth. The next step rarely does. Before replying, the prospective client, or their lawyer, opens the firm’s website and looks at the email address the introduction came from. Both are tests. Neither is passed by design polish. They are passed by details that can be checked and by the absence of details that cannot.
This note reflects texts and standards available on 17 February 2026.
Say who you are, in the form the law asks
Article 33 of Law No. 1.383 for a Digital Principality, shown on LégiMonaco in a single version since 2011, requires those whose activity is publishing an online public communication service to make certain facts available to the public. For a company, these are its name, registered office and telephone number; its registration number, share capital and head office address where it is subject to registration; the name of the director of publication; and the name, address and telephone number of the host.
Many sites stop at a logo and an email address. The host is easy to forget, yet it tells a careful reader where the public pages live. A reader who finds these facts, stated plainly on a legal page, has one fewer reason to doubt the rest.
Say what you do, and where it stops
Trust depends on limits as much as claims. A useful institutional site states the services offered, the clients served and the work declined. It avoids what cannot be verified: client logos without permission, certifications not held, figures without a source. For firms that handle regulated matters, it states what the firm is not, such as a law firm, an auditor or a licensed financial intermediary, when a reader might assume otherwise.
The same restraint applies to contact. A single monitored address, answered by a person, sets expectations better than a form that promises a reply “within minutes”.
Collect less than the tools allow
Most brochure sites need no analytics, no chat widget and no tracking pixels. Article 87 of Law No. 1.565 requires that any access to or storage of data on a visitor’s device be preceded by clear and complete information on its purpose and on the means to object. The same article forbids making access to the service conditional on accepting that processing, unless the storage or access is needed only to transmit a communication or is strictly necessary for a service the visitor asked for. A site that also targets visitors in the EU should check EU rules with counsel as well.
The simplest design keeps device storage to what is strictly necessary, such as a security cookie that a delivery network may set against automated traffic, and names it in the privacy notice. No site is free of visitor data: the network that delivers it still processes IP addresses and request details. But every script left out removes one party who could see who reads the firm’s pages.
Prove the domain is yours
Two standards make the website hard to impersonate in transit. HTTPS encrypts the connection. HTTP Strict Transport Security, specified in November 2012, lets a site tell browsers to reach it only over secure connections. After the first visit, a browser that has seen the policy will refuse to fall back to an unencrypted connection.
Email matters more, because payment fraud often begins with a message that appears to come from the firm. SPF lists the servers allowed to send mail for a domain. The specification states that a domain must not publish multiple records that would cause more than one to be selected, and a check that finds more than one returns a permanent error. DMARC, specified in March 2015, lets the domain owner ask receivers to reject mail that fails authentication. A firm that reaches a reject policy, after reading the reports DMARC produces, makes its own name harder to use against its clients.
A small file adds a channel for problems. RFC 9116 defines security.txt, published under /.well-known/, with a required contact and expiry date. A researcher who finds a flaw then knows where to report it.
Keep the public site and the private portal apart
A public website and a client portal answer different questions. The website says who the firm is to anyone who asks. The portal gives named people access to their own documents. They should not share a login page, a server or an operator by default.
Monaco’s Law No. 1.483 on digital identity frames the second question. It defines three levels of assurance for electronic identification, low, substantial and high, and allows private-sector bodies to create and assign digital identities as well as the State. A portal login is a decision about which level of assurance each person needs. A brochure page requires none.
A page kept out of search engines with a noindex tag is still open to anyone who has its address. Search settings are not access control.
The separation also settles hosting. A static public site with no forms and no client files can run on a global delivery network. At publication, Desgarde’s own public site runs that way, on Cloudflare’s network. It has no contact form and holds no confidential client archive. Cloudflare still processes visitors’ IP addresses and request data to deliver and protect it, and its security services may set a strictly necessary cookie. The portal belongs where the client data lives, under the firm’s control and on the infrastructure its transfer analysis allows. Putting a login box on the brochure site’s hosting merges two risk profiles for the sake of one menu link.
A short working list
- A legal page that meets article 33 of Law No. 1.383, including the host.
- Services, limits and a single monitored contact address.
- No scripts, cookies or third-party resources the firm cannot justify under article 87, and a privacy notice that names the ones that remain.
- HTTPS everywhere, with HSTS once every subdomain supports it.
- One SPF record, DKIM signing and a DMARC policy moving towards reject.
- A security.txt file with a real contact and a current expiry date.
- Client access on a separate host, with authentication matched to the data.
Limits of this note
This is not legal advice. It reflects Monegasque texts and IETF standards available on 17 February 2026; later revisions are outside its scope. Firms subject to sector rules should check what those rules add. To review a site or a domain, write to contact@desgarde.com.
Sources & further reading.
Original materials behind this perspective. Source pages may have changed since the period covered.
- Loi n° 1.383 du 2 août 2011 pour une Principauté numérique (article 33) ↗LégiMonaco · Accessed 22 September 2026
- Loi n° 1.565 du 3 décembre 2024 relative à la protection des données personnelles (Journal de Monaco n° 8725) ↗Journal de Monaco · Accessed 22 September 2026
- Loi n° 1.483 du 17 décembre 2019 relative à l’identité numérique ↗LégiMonaco · Accessed 22 September 2026
- RFC 6797: HTTP Strict Transport Security (HSTS), November 2012 ↗IETF / RFC Editor · Accessed 22 September 2026
- RFC 7208: Sender Policy Framework (SPF), April 2014 ↗IETF / RFC Editor · Accessed 22 September 2026
- RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC), March 2015 ↗IETF / RFC Editor · Accessed 22 September 2026
- RFC 9116: A File Format to Aid in Security Vulnerability Disclosure, April 2022 ↗IETF / RFC Editor · Accessed 22 September 2026
Bring it into your own context.
Your firm’s information, obligations and operating constraints shape the right approach.
contact@desgarde.com