The Workshop Diary is an ongoing series about how tools really come to be, in my own and clients’ projects, from idea through error to iteration. This is part 4, the conclusion of the series. Earlier: part 1, part 2 and part 3.
The first three parts of the series assumed that someone had made decisions: bought computation, bought a managed cloud, managed the identities. A large share of small companies have done none of these, not because they are careless, but because organised security costs money and the company has grown organically, one tool at a time. This part is for them.
An SME’s real security situation
The honest picture often looks like this: a jumble of consumer and business accounts, no device management, no single sign-on, shared passwords, and data scattered across three providers’ clouds. Gmail for marketing, because it was set up first. Outlook for invoicing, because the bookkeeper wanted it. Proton for what had to stay private. Nobody owns the overall picture of where the company’s knowledge actually is.
This is not a moral failing. It is a by-product of growth, and exactly the same phenomenon recurs in larger houses too. But it means that two basic questions, “where is our data” and “who reaches it”, go unanswered. And it is the unansweredness that is the risk, not any single service. You cannot protect what you don’t know you own.
Python as glue: APIs, not new systems
The solution need not be a big platform whose rollout takes half a year. Often the sensible move is to write small Python scripts against the providers’ interfaces and do precisely the things that matter. Gmail has its interface, Microsoft has Graph (the same as in part 3), Proton has Bridge and IMAP. Three clouds, one thin layer of code over them.
Why Python in particular? Because there are ready-made libraries for almost every one of these interfaces, the code is readable even while the person who wrote it is on holiday, and a small script can be run, say, once a night without heavy infrastructure. The interfaces mostly use OAuth authentication nowadays, meaning the script gets limited, revocable access, not anyone’s password. That is an important security feature, not a technical aside.
The idea is the same as in part 1: gather scattered knowledge into one managed, local place. Only now the sources are emails and cloud storage across several services instead of one document folder.
For a small company, a hundred lines of its own Python code can do more than an expensive platform nobody has time to adopt.
What that code actually does
Five concrete examples, all general patterns, not client-specific implementations.
Inventory. A script that goes through three mailboxes and the cloud folders and lists what data is where: attachments, share links, old files, who owns what. Often it is the first time anyone sees the overall picture at a glance, and it almost always reveals surprises.
Risky shares surfaced. A script that finds externally shared files and links that are too open. The most common leak route in an SME is not a hacker but a forgotten “anyone with the link” share from a year ago that is still open to the whole internet.
A local backup. A script that pulls the data from three services into an encrypted local backup at night. If one account is lost, frozen or locked by ransomware, the knowledge does not vanish with it. The cloud is not a backup. It is someone else’s computer.
Cleanup and retention. A script that identifies stale or duplicate data and proposes deletion. Less data means a smaller attack surface and easier GDPR management: data that doesn’t exist can’t leak.
A searchable knowledge store. And finally: feed that gathered and cleaned data into part 1’s local RAG, and the SME gets the same “ask your data” capability without handing its data to a single large supplier. The circle closes.
Limits and honesty
Here you have to be blunt: this is glue, not a security programme. Python scripts do not replace multi-factor authentication, proper backups, or someone being named as responsible. They narrow the gap and make visible what wasn’t seen before, but the basics still have to be done. A script that tells you where the data is does not protect the data; it tells you what to protect.
The scripts also need maintenance: interfaces change, credentials expire, something always breaks at the worst time. Small code is cheap to build but not free to maintain, and if the person who wrote it leaves, someone else has to understand it. That is an honest price, and it is worth saying out loud before you start, not after.
How to get started
Not everything at once. Start with the inventory, just knowing where the data is and what is open is already a big step and often an eye-opener. After that the order of priority is almost always the same: close the risky shares, make sure of the backups, turn on MFA everywhere you can. Only once the foundation is in order is it worth building a searchable knowledge store. The order is not a matter of taste. There is no point building a fine search for data that leaks out of an open link.
Where this series ended up
We started local, the data stays home (part 1). When the power isn’t enough, it can be bought, but the responsibility stays and moves to the contract (part 2). When the data is already in the cloud, the boundary moves to identity and access management (part 3). And when none of this has been bought, small code closes the gap (part 4).
One thought runs through the whole series: data sovereignty is not a matter of money nor a privilege of size. It is a decision, and it is within reach on every budget. The most important thing is to know where your own knowledge is and who reaches it. Everything else builds on that.
The Workshop Diary continues, next, on to client projects.