Encrypted in transit and at rest: how your clinic data travels
When a platform says it uses “encryption”, the word sounds reassuring. On its own it says very little.
Encrypted when? While it travels across the internet? While it sits in storage? The whole database, or only certain fields? Are the backups protected too?
To really understand how a clinic’s information is protected, it helps to separate two things: encryption in transit, and protecting data at rest. They solve different problems.
At Wazzy both are part of a security architecture that protects conversations and other data while they move between systems, and when certain sensitive information has to be stored.
The journey of one message
Picture something ordinary. A patient opens WhatsApp and writes to her clinic: “Hi, I need to move my Thursday appointment”.
On the face of it there is one message. Technically, that information passes through several systems.
It leaves the patient’s phone, goes through the WhatsApp Business infrastructure, reaches the clinic’s authorised services, is handled by Wazzy, can be read from the reception panel, and can end up attached to the patient’s conversation history.
The information changes state several times. Sometimes it is moving. Sometimes it is stored. Each situation calls for different protection.
What encryption in transit is
Encryption in transit protects information while it moves between two points. The aim is to stop anyone sitting in between from reading the contents comfortably, or changing them without being noticed.
One of the best known protocols for that is TLS, which HTTPS uses. It is the same principle that lets a browser connect securely to a bank, an online shop or a business platform.
When you reach Wazzy over a public connection, the traffic goes over HTTPS/TLS. So the information travelling between the user and the Wazzy public services is protected on the way.
The WhatsApp layer
Before anything reaches Wazzy’s own infrastructure there is the WhatsApp layer.
WhatsApp uses cryptography to protect messages while they travel. In a business setting there are particulars, depending on how the company handles and stores conversations, and which technology providers are involved.
That helps make one thing clear: there is no single “WhatsApp encryption” that removes the need to protect everything that happens afterwards.
When a message reaches the system the business uses to handle it, that infrastructure has responsibilities too.
What it means for data to be at rest
Data is at rest when it is not being sent anywhere and is sitting in storage. It could be in a database, in a backup, in a file, or in any other kind of store.
TLS is not the right tool here, because TLS protects traffic. For stored data you use other techniques, among them cryptographic algorithms such as AES.
The difference in one line: encryption in transit protects the journey; encryption at rest protects certain data once it has arrived and is being kept.
AES-256-GCM in Wazzy
Wazzy uses AES-256-GCM to encrypt certain particularly sensitive fields.
Those include the stored contents of conversation messages, certain sensitive internal records, and certain credentials or secrets used for integrations, such as WhatsApp and Google Calendar tokens.
AES is a widely used encryption standard. The “256” is the size of the key. GCM is a mode of operation that puts confidentiality together with authentication, which helps spot tampering.
In practice, that means the protected values are not simply sitting in the database as readable text.
Is absolutely everything encrypted field by field?
Here it pays to be precise.
No. Wazzy applies AES-256-GCM selectively, to certain sensitive fields, and that is not the same as saying every single piece of data in the whole database is individually encrypted with AES-256-GCM.
Nor should it be confused with encrypting the whole disk or the whole database at the storage layer.
The real security of a system usually combines several mechanisms. Certain fields need specific cryptography. Other resources are protected by network isolation, access controls, separating services, and other infrastructure measures.
Explaining that difference is more useful than writing “all your data is encrypted”, a phrase that sells well and means little.
Keeping the internal systems apart
Wazzy runs internal services such as PostgreSQL and Redis inside a private network. They are not built to sit directly on the internet.
That adds another layer.
A database does not have to be publicly reachable for the application to use it. The architecture can keep internal services apart and let only the components that really need to talk to each other do so.
Layered security works exactly like that: not depending on a single barrier.
What about the backups
Backups deserve the same attention as the main database.
There would be little point in carefully protecting a production system if a copy of it were sitting somewhere without proper protection.
Wazzy takes automated backups and protects them with AES-256 encryption. Those copies are stored in the European Union.
The point is twofold: keeping them confidential, and being able to bring the service back when something goes wrong.
That ability to restore is one of the things article 32 of the GDPR names explicitly, when it mentions being able to restore the availability of, and access to, personal data in good time after an incident.
Encryption is not much use if anyone can get in
There is a common mistake: thinking encryption stands in for permissions.
It does not.
An application has to decrypt certain information to show it to an authorised user. If every user has full access to the system, encrypting the storage will not stop those people seeing the data through the application itself.
So Wazzy puts encryption together with access controls. The clinic can set tiered permissions and keep certain information to authorised users.
In a clinic that distinction matters most when the reception panel and the medical CRM live in the same place.
The keys have to be protected too
Every cryptographic system depends on keys. A perfectly encrypted database with its keys lying around loses most of the point.
So managing secrets is another critical part of a secure architecture.
Wazzy encrypts certain sensitive tokens and credentials used by integrations, such as those for WhatsApp or Google Calendar. Those credentials can let an application talk to outside services on the clinic’s behalf, so they need a high level of protection.
Encryption, integrity and availability
Information security is usually explained through three ideas: confidentiality, integrity and availability.
Confidentiality means only the right people can reach the data. Integrity means it does not get changed when it should not. Availability means it is still there when you actually need it.
Encryption mostly helps with confidentiality and, depending on the method, can also help spot tampering. It does not, on its own, solve availability.
For that you need backups, redundancy, monitoring and a way back. Article 32 of the GDPR names exactly those ideas when it requires appropriate measures to ensure the confidentiality, integrity, availability and resilience of systems.
What if somebody steals a copy of the database?
This example shows what encryption at rest is worth.
Suppose, hypothetically, that an attacker gets hold of a copy of certain data. If the contents of the conversations are stored as plain text, having that copy could be enough to read them.
When a sensitive field is properly encrypted, having the stored value is not enough to read it. The attacker would also need what it takes to decrypt it.
That does not make the system invulnerable. But it raises the barrier considerably in certain scenarios.
And if the attack happens while somebody is logged in?
Then other layers come into play.
Someone who manages to take over an account with enough permissions could reach information the application has to show decrypted. Encryption at rest does not stop that.
So password policies, access controls, user management, traceability, and removing permissions when somebody leaves all matter.
Again, security depends on the whole, not on one piece.
Why Wazzy avoids reducing security to one word
Saying “we use AES-256” can be true and still not tell you much. The question that matters is where it is used, what it protects, and what goes with it.
At Wazzy, public connections use HTTPS/TLS. Stored messages and certain sensitive secrets use AES-256-GCM. The database services stay inside an internal network. The backups are encrypted and stored in the European Union. There are access controls, traceability and monitoring.
Each piece solves a different part of the problem.
Security in layers
The best way to picture the security of a digital clinic is not one heavy door. It is a series of doors.
One protects the journey. One protects particularly sensitive fields in storage. One limits which services can talk to each other. One decides which user can see what. One records what was done. And one lets you bring the system back when something breaks.
The more separate layers there are, the less everything rests on a single measure. Which is why talking only about “encryption” flattens the problem too far.
The question a clinic should ask
When a provider says it protects your data, go one step further and ask:
Which data is encrypted? At what point? What happens to the backups? Where are the servers? Who can reach them? Is what people do recorded? Are the internal systems exposed to the internet?
The answers tell a sales line apart from a real security architecture.
Because protecting a patient’s data is not a matter of putting the word “encrypted” on a web page. It is understanding the whole journey that information makes, and protecting it at every step.
