Plenty of Brazilian companies already handled the legal side of the data protection law: hired a lawyer, wrote a privacy policy, added the cookie banner to the site. And stopped there. The network stays exactly as it was, with the same shared folder everyone can open and the same backup nobody has ever tested.
The problem is that Brazil's data protection law (LGPD) covers something broader than a contract. According to the national data protection authority, personal data is any information related to an identified or identifiable person — name, email, tax ID, photo, address, and also the record of an employee or an old customer nobody uses anymore. There's an even more sensitive category: health, biometric, political or religious data, which needs extra care because the potential harm is greater.
That changes the question worth asking. It isn't "is my contract solid?" — it usually is. It's "can I say, right now, where each of those pieces of data is stored, who can reach it, and what happened to it last week?" For most small and midsize companies, the honest answer is no — and that's exactly where the law charges the price in infrastructure, not paperwork.
Where personal data actually lives
Personal data doesn't live in one system. It's scattered: in the HR spreadsheet, the sales system, the website form, the entrance camera, the laptop of someone working from home, the inbox of someone who left the company two years ago and still has an active login. Each of those spots is a place where the law applies.
The first infrastructure problem, almost always invisible until something goes wrong, is not having an inventory of where that information sits. Without that list, a company doesn't know how much personal data it holds, how many places it's copied to, or who has a real reason to reach it. It's the same logic behind the first internationally recommended security control for any company: keep a record of the devices and systems in use, because you can't protect what isn't listed.
That inventory isn't a document written once and filed away. It needs to track what changes: a new system, a supplier that started receiving customer data, an employee who left and kept an active account. Any company that answers "I don't know" to "where is the customer list" already has the first problem the data protection law creates — and no contract clause fixes it.
The second problem, tied to the first, is who can reach that data. In a small company it's common for access to be broad out of habit: everyone opens the same folder, nobody removes access after someone changes roles, the finance intern sees the same spreadsheet as the director. Every extra access with no work reason is an extra risk the company carries for nothing.
Why having a policy isn't the same as having control
The common reaction to the law was legal: revised contract, published policy, banner in the footer. That solves the paperwork — and it's necessary — but it doesn't change a single line of what happens on the company's network day to day. The folder stays open, the backup stays untested, the former employee keeps an active password.
The risk of treating that as solved shows up when an actual security problem happens. A 2026 study on ransomware in Brazil, based on companies hit in the previous twelve months, found that in 38% of attacks where files were encrypted there was also data theft beforehand — an increase from the year before. In other words: the same incident that's already serious on its own is, more and more often, also a personal data leak the company needs to be able to explain.
That's the moment the difference between "having a policy" and "having control" carries its full weight. A company with only the legal document can't answer basic questions when the problem lands: which personal data was in that system, who had access to it, when it was last accessed. Without that record, every question turns into a manual review, done under pressure, in the middle of a crisis.
Another common move, just as frequent as the first, is buying a new security tool and assuming the access problem is solved because a product is now watching it. A tool with nobody reviewing what it flags, and no process saying who can access what, works only a little better than having nothing at all.
What Has to Be in Place
Meeting the infrastructure side of the data protection law depends on mechanisms that run every day, not a document signed once.
An inventory of where personal data is stored. Systems, spreadsheets, shared folders, email, backups — anything holding customer or employee information needs to be on a living list, updated whenever something changes.
Access by necessity, not blanket access. Each person sees only what the job requires. When someone changes roles or leaves, access changes or is cut the same day — not months later.
A record of who accessed what. A sales system, a file server, or an inbox that doesn't keep that history leaves the company without an answer to the first question that comes up after a problem.
A backup that's tested, not just running. In the same study on ransomware in Brazil, 85% of the companies hit used backups to recover encrypted files — a sizable jump from the year before. A backup that exists but was never tested is an assumption, not a protection.
One person accountable for all of it. Inventory, access, and backup need someone looking at the whole picture — not three different vendors each covering one piece and none of the whole.
This is how Skills IT works: with an inventory of what the client stores, access corrected by necessity, and backups tested on a regular basis, instead of a document sitting in a folder.
The payoff for whoever decides
The payoff for fixing this isn't legal, it's operational. A company that knows where personal data sits and who can reach each system solves a security problem in hours, not weeks — because it doesn't need to rebuild what happened from scratch before acting.
It also changes what the company can show when it's asked. Reporting a security incident to the authority requires stating what was affected, the risk involved, and what's already been done to reduce the damage. A company with inventory and access records answers that with real data; a company with neither answers with a guess — and a guess, in a formal review, counts against whoever only has that to show.
There's also a direct financial payoff: less staff time spent manually reconstructing what happened, less risk of improper access to sensitive customer or employee data, and less downtime before the company is back to normal. Data governance, in practice, is avoided IT cost, not a separate obligation on top of it.
Finally, there's a decision-making payoff: when the inventory already exists, whoever decides knows the exact size of the problem the moment it appears, instead of finding out little by little, week after week, how much was actually exposed.
A Starting Checklist
Before revisiting the contract again, it's worth checking what the company's infrastructure can actually answer today.
- Can the company list, without digging around, where customer and employee data is stored? If the answer requires opening several systems to check, the inventory doesn't really exist.
- Does anyone who changed roles or left the company still have access to a system? If the answer is "probably, but nobody checks," access is wider than it should be.
- Has the backup ever been tested with a real recovery, or does it just run every day with no one checking the result? A backup never tested is a copy, not a guarantee.
- Is there a record of who accessed a system holding personal data in the last week? Without that record, any question about an incident turns into a guess.
- If a security problem happened today, who at the company could say exactly the size of what was affected? If the answer takes too long, the infrastructure still hasn't caught up with the law — only the contract has.
