Brazil's data protection law, the LGPD, does not treat a patient's history as ordinary information. According to an analysis published by the legal outlet Migalhas, the law classifies health data as sensitive personal data and demands a stricter duty of care from clinics — well above what applies to an ordinary customer record.
On top of that, Brazil's Federal Council of Medicine has already settled the retention question. Under Resolution CFM No. 1,821/2007, a paper medical record that is not securely digitized must be kept for a minimum of 20 years from the patient's last entry. A properly digitized record can be kept indefinitely — but only if the system itself survives that long.
Two rules, one practical consequence: at a clinic, patient data can never be lost, and the system holding that data can never simply go dark without a plan behind it. That is what changes the IT conversation once the client is a clinic: the problem stops being just "the system went down" and becomes "what the practice did while it was down, and what it can prove afterward."
Two things that change everything
The first change is the nature of the data itself. A name, phone number, and address already require care at any company. Visit history, exam results, diagnoses, and prescriptions are a different category: the law treats them as sensitive data, which raises the bar on who can access them, for what purpose, and with what record of that access. A security failure at a clinic is not just an IT problem — it is the exposure of information the law protects more strictly.
The second change is the timeline. An invoice or a contract has a retention period measured in a few years; a patient's record can follow that person for life. The medical council's rule on digitization and retention exists for exactly that reason: if a clinic keeps records only on paper, the minimum period is 20 years after the last entry; if it digitizes them, the system has to be built to last — "permanent retention" is not a marketing promise, it is an obligation that falls on whoever runs the practice.
The third change is the most visible one day to day: the outage happens with people in the room. An accounting office that loses its system for two hours delays a task; a clinic that loses its system at 8 a.m. on a Monday has a packed waiting room, a patient who traveled from another town, a scheduled procedure, and no way to confirm insurance coverage, pull up history, or print a lab order. There is no rescheduling the whole morning and asking everyone to come back later.
And healthcare is targeted more often than average. According to Check Point Research, published in September 2024, healthcare organizations in Latin America faced an average of 2,703 cyberattacks per week between January and September of that year — a 34% increase over the same period the year before, attributed in part to weaker regulation and tighter security budgets in the region.
Getting this wrong also has a price tag. According to IBM's 2025 Cost of a Data Breach Report, the average cost of a healthcare data breach was $7.42 million — the highest of any industry IBM measured, the 14th consecutive year in that position, even though it was down from $9.36 million the year before. Put the three together — more sensitive data, a more targeted sector, a costlier incident — and the picture changes: a small clinic is not a small target.
The common approach doesn't work
The common way of handling IT at a small clinic is reactive: call someone when the system freezes, with no inventory of what exists, no fixed point of responsibility, and no prior agreement on how to keep serving patients while the problem gets fixed. It works until the day it doesn't — and in this field, the day it doesn't work costs more than it would at an ordinary office.
Three common habits make the two issues above worse. The first is treating backup as something that exists because "someone set it up once" — without a recovery drill, no one knows whether that file actually returns the full record when it is needed. The second is giving the whole team the same access to the system: front desk, nursing, and billing all looking at the same screen, which does not survive a question about who saw which record. The third is having no agreed plan at all for when the system goes down — the front desk improvises, the patient waits, and no one decides whether the visit goes ahead without the history or should be rescheduled.
The common thread is the usual one: buying one more tool does not fix this. Antivirus, backup, and even a good electronic records system stay loose pieces if no one treats the clinic's operation as a routine that needs a plan, an owner, and a test — not just a set of products.
What has to be in place
A workable IT setup for a clinic is defined by verifiable mechanisms, not promises.
A paper-based plan for the first hours. Everyone at the front desk knows how to confirm arrivals, note the reason for the visit, and manage the queue without the system, until it comes back — with no improvising on the spot.
Record access split by role. The front desk sees the schedule and the patient's contact details; the full clinical record stays with the provider responsible for that visit; billing sees only what it needs for the insurance claim.
A copy of the day's schedule available outside the main system. Printed or kept in another application, so the front desk can keep calling patients even while the clinic's main system is down.
Front-desk equipment with its own power backup. A battery backup on the front-desk computer, router, and printer, so a power outage does not stack on top of a system outage.
A record of who accessed which patient file, and when. This is not paperwork for its own sake — it is the ready answer on the day a patient, an audit, or the law itself asks who saw that data.
This is how Skills IT works: it separates access by role, helps the clinic put together a paper-based plan for the first minutes without the system, and tests the record backup with an actual recovery drill — not just runs it.
Less downtime, more confidence in the data
Doing this right pays off in two places. The first is the waiting room: with an agreed plan in place, the front desk does not let the whole queue stall while waiting for the system to come back — staff know what to do in the first few minutes, and the patient feels the difference between "just a moment" and "no one here knows what to do."
The second payoff is legal, and it stays out of sight until the day it isn't. Splitting access by role and logging who saw which record is exactly the kind of control the data protection law expects when someone asks how the clinic handles sensitive information. Not having that answer ready costs more than keeping the control running.
Neither payoff depends on buying more equipment. It depends on the clinic's IT operation being designed for the bad day, not just the ordinary one — and that is an organizational decision before it is a budget one.
Four questions for your next meeting
- If the system went down right now, with a full waiting room, what would the front desk do in the first 15 minutes? If the answer is "wait for it to come back," there is no plan yet — just hope.
- Who, today, can see the complete record of a patient who isn't theirs? If the answer includes more people than it should, access isn't split by role.
- When was the last time someone actually tested restoring a record from backup? A backup that has never been restored is an assumption, not a guarantee.
- If a patient asked who accessed their record in the last month, could the clinic answer? Without that log, the answer the law expects doesn't exist.
