Cybersecurity
Security is not a product installed at the end of a project: it is a sequence of decisions taken while designing it, each of which closes a door that would otherwise have to be watched. At Digital-V Partners, we start from what is already exposed, close what can be closed, and leave the organisation able to check for itself that it holds.
Free AI visibility audit
Is your business cited by AI?
Start with what is already visible
An organisation does not choose what an attacker looks at first: they look at what is public, and they do it before any attempt.
- An inventory of the exposure — We list what your organisation shows from the outside: domain names, reachable services, forgotten administration interfaces, and accounts tied to your addresses.
- Traces already in circulation — We check whether credentials linked to your addresses appear in published data breaches, and whether domain names close to yours have been registered by someone else.
- A hierarchy of risk — Not everything weighs the same. We rank what is found by what an attacker would actually do with it, so that effort goes first where it changes something.
The defences that matter before the tools
The incidents that take longest to contain rarely come from a novel technique: they come from an access that was too broad, a backup never tested, or a message no one knew how to answer.
- Access control — An account receives only the rights its task needs, and loses them when the task ends. Multi-factor authentication applies first to the accounts that administer, because those are the ones that open everything else.
- Impersonation of your name — A misconfigured domain lets anyone send messages that appear to come from you. The settings that prevent this exist, can be checked from the outside, and cost nothing beyond being set correctly.
- Backups you have already restored — A backup is worth only the restore you have actually performed from it. We check that it lives out of reach of the system it protects, and that someone knows how to use it.
- Conduct during an incident — Who decides, who is told, what gets disconnected and what is kept as evidence: written calmly beforehand, it fits on one page; improvised during the incident, it costs the day.
Mistakes to avoid at all costs
- Treating security as a final layer — Which data is collected, where it lives, who sees it and how long it is kept: those choices determine the surface to defend. What comes afterwards only protects what has already been decided.
- Believing that being small protects you — Common attacks are targeted automatically: they do not pick their victims, they sweep whatever answers. Being small does not make you invisible, only less prepared.
- Buying a tool instead of making a decision — A security product replaces neither an up-to-date inventory, nor the revocation of an unnecessary access, nor a tested backup. Installed on an organisation that has done none of those three things, it mostly provides a feeling of coverage.
- Trusting an unverifiable claim — A provider who promises an impregnable system is promising what no one can hold to. What can reasonably be committed to concerns the work: what will be fixed, what will be checked, and how you will be able to see it for yourself.
Frequently asked questions
What is an exposure surface, concretely?
It is everything a third party can reach or learn without holding any rights with you. It covers more than people expect: active domain names and subdomains, services answering on the public network, administration interfaces reachable from anywhere, documents left openly accessible, accounts opened on third-party services with the organisation’s addresses, and information staff publish without thinking about it. Its awkward property is that it grows on its own: every tool added, every provider, every abandoned but still-online project widens it without anyone having decided so. Keeping it under control is less about reducing it to nothing, which is impossible for an organisation that works, than about knowing what it contains and why each item is still in it.
Do I need antivirus, a firewall, or something else?
Both remain useful, but they answer threats that are no longer the most frequent. The dominant way in today is not software forcing a door, it is a valid credential obtained by phishing or recovered from a breach, then replayed on a service that accepts it. No antivirus distinguishes a legitimate connection from an illegitimate one made with the right password. What answers that scenario lies elsewhere: a second authentication factor, rights limited to what each account actually does, and the ability to revoke an access quickly. So the useful order is that one — access first, then the ability to restore, and only afterwards detection tools, which assume someone is there to read what they report.
How do I know whether company credentials have leaked?
Public services index data breaches that have been made public and let you check whether an address appears in them. That is a useful starting point, with two limits worth knowing: they see only what has been published and reported, so an empty result proves nothing. The practical consequence matters more than the result itself: a password that has appeared in a breach must be treated as known, even if it looks complex, and above all everywhere it has been reused. Reuse is what turns an old leak on an unimportant service into access to your mailbox. A password manager, which makes every password unique per service, is what breaks that chain.
Why can my domain be used to send messages in my name?
Because electronic mail was designed without any verification of the sender: any server can claim to write from your domain, exactly as anyone can write what they like on the back of an envelope. Mechanisms have since been added to publish, in the domain’s public settings, which servers are allowed to write in its name, how messages are signed, and what a recipient should do with a message that fails those checks. As long as those settings are absent or left in observation mode, a fraudulent message bearing your name arrives normally at your customers. The important point is that this configuration can be checked from the outside, by anyone: it is not a statement of intent, it is an observable state.
Is multi-factor authentication enough?
It is the measure with the best ratio of effort to effect, and it does not close the subject. It makes phishing markedly less profitable, since a stolen password is no longer sufficient. It remains bypassable in three cases worth knowing: a code received by text message can be intercepted or obtained by having the line transferred; an already-open session token can be stolen and replayed without going through authentication again; and a repeated prompt is sometimes accepted out of weariness. The answers exist and are known — prefer a dedicated application or a physical key over text messages, limit how long sessions live and be able to revoke them, and require a displayed match rather than a plain approval.
Is a small organisation really a target?
It is, but not in the way people imagine: it is rarely chosen, it is encountered. Most common attacks are automated and sweep indiscriminately for whatever answers on the network, then exploit whatever lets them. A small organisation therefore faces the same first wave as a large one, with fewer means to absorb it. There is also a particular position at play: a modest organisation is often the shortest path to a larger customer, through the trust granted to it and the accesses opened for it. So the reasoning «nobody is interested in us» asks the wrong question. The right one is: what can be done with our accesses, our data and our name once someone holds them?
What should be done at the very start of an incident?
Three reflexes beat haste. Isolate before erasing: cutting network access to what is affected limits spread, whereas immediate cleaning destroys what would have made the entry point understandable. Preserve the traces: logs, the messages received and screenshots become the only material available for a complaint, a declaration or a claim, and many of them expire on their own. Take back control of access: change passwords from a clean device, revoke open sessions and application tokens, because a changed password does not close a session that is already active. Then comes the question often forgotten in the rush: who must be informed, and under what deadline an obligation applies.
Do backups protect against ransomware?
They are the only defence that makes the blackmail pointless, on three conditions, none of them automatic. They must live out of reach of the system they protect: a backup permanently connected is encrypted along with everything else, which is precisely what these attacks aim at. They must keep several states over time, because a corruption that went unnoticed is copied into the latest version. And they must have been restored for real, at least once, onto something other than the original system — a backup never restored is a hypothesis, not a guarantee. One limit remains and should be stated: they make data recoverable, they do not prevent its publication if it was also copied.
What is a security certification from a provider worth?
It says that an organisation was able to describe its procedures and have them verified at a given moment, which is not nothing and is also not what people often make it say. A certification covers a declared scope, which may be far narrower than the whole activity; it attests to documented operation, not to the absence of flaws; and it ages between two checks. So it reads as an indication, never as a conclusion, and two questions make it useful: what exact scope is covered, and when the last verification took place. This site claims none, and its Security page says so explicitly: what it describes are the mechanisms, so that they can be verified rather than believed.
How do I check that a provider does what it announces?
By asking for what can be observed from the outside rather than what is declared. Several elements can be seen without privileged access: the domain’s public configuration, the headers returned by the server, the presence of a reporting address, the way a form validates what it receives. Others must be asked and must get a precise answer: who holds administrator access and how it is revoked, where backups live and when the last restore was performed, what is logged and for how long. One last point deserves to be raised before signing rather than after: who owns the code, the accounts and the data created for the project, and in what form they are handed back to you if the collaboration ends.