The Basics of Data Security

One Lock Is Not Enough

Part 9 of 12 in "Databases for Non-Developers". This installment covers the four layers of data security — encryption, access control, backups, and insider threats — with analogies and questions you can ask in meetings right away.

---

When you protect your home, is a strong padlock on the front door enough? Most people know it isn't. You lock the windows too, check the door frames as a precaution, and keep valuables in a safe. Some intruders skip the door entirely and come in through the roof or the plumbing, and some thieves simply pretend to be a family member with a key and walk in through the front door.

Data security works the same way. The sentence "we've encrypted the data" is not the end of the security story. Security is like several layers of doors — it only counts if one layer being breached gives the next layer time to hold. In this installment we open each of the four layers one by one: encryption, access control, backups, and insider threats. The goal is not to learn the technology, but to know what each layer does and does not protect. That way, when someone proposes a plan that's missing one of those layers, you can ask, "So who's guarding that door?"

Layer One. Encryption — Unreadable Even If It's Stolen

Encryption is the technology of turning data into a form that can't be read without a specific key (the "key" is literally a digital key). To use an analogy: even if someone steals my diary, all the words inside are scrambled into another language and they can't read it.

There are two things non-developers should know here.

First, "where" encryption protects data matters. Encrypting the database inside the server (encryption at rest) and encrypting data as it travels over the internet (encryption in transit) are different problems. If a website's address starts with https these days, encryption in transit is already in place. So if you ask "Is it encrypted?" in a meeting and the answer is "Yes, we use HTTPS," that's an answer about one of the two layers. You still need to ask separately how the database files themselves are protected.

Second, the strength of encryption depends on key management. No matter how expensive the lock is, it's useless if you hide the key under the doormat. Cloud services usually handle key management well, but "we manage the keys ourselves" also means "if we lose the keys, recovery is impossible." Who holds the keys, where they're kept, and what happens if they're lost are all questions worth asking.

Layer Two. Access Control — Who Can Come In, and What They Can Do

Once you've put a lock on the door, the next question is "who holds the keys." Access control breaks down into two steps.

Who gets in (authentication). A username and password is the classic approach, but it's no longer enough on its own. Passwords leak easily, so important systems need a second check — multi-factor authentication, like a code sent to your phone. "Is multi-factor authentication required on our admin accounts?" is a very good question to ask in a meeting.

What can someone who got in actually do (authorization). This is where real incidents tend to happen. An employee has left but their account is still active. An intern can download the entire customer list. One person can both approve payments and edit the books. Two good principles apply here: least privilege — granting only the minimum access needed to do the job, and leaving nothing extra open — and separation of duties — making sure no single person can perform more than one critical task alone.

Think of it like an apartment key fob. It goes without saying that a resident's fob only opens their own building and floor. The single question "Can all of our employees access the entire database?" reveals the state of this layer faster than anything else.

Layer Three. Backups — You Can Lose Data Without Being Breached

When we talk about security, it's easy to picture only attacks, but data can be lost without any attack at all. It can be deleted by an operational mistake, corrupted by a software bug, or held hostage by ransomware that makes it unusable and demands payment. A backup is the last line of defense against all of these.

There are three criteria for judging a backup.

How often does it run? If you back up once a day, an accident in the afternoon wipes out that entire day's work. Check whether the frequency matches the nature of the work.

Has anyone actually tried restoring from it? Having backup files doesn't mean restoration will work. Ask "when did you last test a restore?" in response to "we back up every day," and organizations split into those that are prepared and those that aren't. This is exactly the "a procedure that actually works, not a document on paper" point made by the governance discussion in Part 7.

Is the backup locked away from the original, too? Ransomware often encrypts the backups along with everything else. That's why the rule is to keep backups in a place separate from the original data, in a form that can't be modified.

Layer Four. Insider Threats — When the Person With the Key Is the Culprit

A significant share of security incidents don't start with an outside hacker — they start with someone on the inside. That's why the title of Part 10 says a breach doesn't only mean a hacker's attack. An employee with a key can see something they shouldn't by accident, a disgruntled employee can take data on purpose, and if a departed employee's account is still active, that account becomes a doorway.

Reducing insider threats is more a matter of procedure than technology. Closing accounts the moment someone leaves, logging important access and having someone review those logs regularly, setting off alarms on unusual mass downloads — all of these are rules that people define. That's why this layer falls especially heavily on executives and team leads.

Questions you can ask in meetings right away

• Is the database encrypted both at rest and in transit?
• Is multi-factor authentication required on admin accounts? Are employee permissions divided according to the principle of least privilege?
• How quickly are departed employees' accounts closed?
• How often do you back up, and when did you last run an actual restore test?
• Is there a log of who viewed which data and when — and who reviews that log?

A Checklist You Can Act on Today

• Check that the addresses of important services start with https.
• Turn on multi-factor authentication in the settings of the services you use.
• Check that you're not reusing the same password across multiple services.
• Ask your company: "How do you back up our data, and how often?"
• Review for yourself whether you can access only the data you actually need.

Closing Thoughts

Security is not about one lock — it's about multiple doors. Encryption makes stolen data unreadable. Access control limits who gets in and what they can do. Backups let you get back on your feet after a loss. Insider-threat measures manage even the people who hold the keys. Keep these four layers in mind, and the next time a report lands on your desk saying "we've strengthened security," you'll know exactly what to ask. In the next installment, we'll cover what happens when these doors do get breached — what actually unfolds during a data breach, and the order in which to respond.