What types of data security solutions exist and how do you choose?

Data security solutions are tools and practices that protect data from unauthorised access, change or loss. They group into five jobs: discovering and classifying data, controlling who can reach it, encrypting it, monitoring how it is used, and recovering it. Choose by the risk you need to reduce, not by product category.

What problem is each solution for?

NIST's practice guide on data confidentiality (SP 1800-28) addresses the threat of data breaches and shows standards and technologies useful against a data confidentiality attack. Its starting point is the one to copy: identify and protect assets, including data, then detect and respond.

Think of the solutions as answers to five questions.

Where is our data? Discovery and classification tools scan stores and label what they find. Without them, every other control is guesswork. They produce false positives and need a person to confirm sensitive categories.

Who can reach it? Access control: identity systems, role and attribute based permissions, privileged access management, and periodic access reviews. This is usually the highest value control because most data loss starts with someone or something that had access it should not have had.

Is it unreadable if stolen? Encryption at rest and in transit, with key management. Encryption protects against theft of disks, backups and network paths. It does not protect data from a user or application that is allowed to decrypt it. The keys are the real asset, so where they live matters more than the algorithm.

What is happening to it? Activity monitoring and alerting on unusual reads, bulk exports and permission changes. Data loss prevention tools sit here and trade coverage for noise.

Can we get it back? Backups that are tested, isolated and protected from deletion by normal admin accounts. CISA's ransomware guidance and the DarkSide advisory both stress testing backups and storing them separately.

Which one first?

Start with the cheapest question that leaves you blind. Most small teams do not know where their sensitive data is, so discovery comes first. Teams that know but over-share should fix access first. Teams with sound access but untested backups should do a restore drill this week.

What does a constructed example look like?

A software company stores customer exports in a shared drive, a data warehouse and several developer laptops.

• Discovery finds exports in a personal folder and in an old test database.
• Access review finds forty people with warehouse read access and nine who need it.
• Encryption is already on by default in the warehouse, so they check key ownership rather than buy anything.
• Monitoring is set to alert on any export above a size threshold.
• A restore test reveals the backup account shares a login with day-to-day admins, which they separate.

None of those steps required a new platform. Each one required a decision and an owner.

How do you evaluate a vendor?

Ask five plain questions. What data stores and formats does it cover? How does it reduce risk beyond reporting it? What does it need access to in order to work, and how is that access protected? How are its findings tested for accuracy? How does it export data and logs if you leave?

Beware of products that count findings as outcomes. Ten thousand alerts do not reduce risk. Closed risks do.

How does it relate to code and dependencies?

Data leaks often start in software: a library with a known flaw, a secret committed to a repository, an endpoint that returns too much. Scanning dependencies and secrets in your own code covers that source. Safeguard's dependency scanning and secret detection address that layer, and are a complement to data-store controls, not a replacement.

How to check or apply this

1. List your five most sensitive data types and every place each lives.
2. For each place, record who has access and when it was last reviewed.
3. Confirm encryption at rest and in transit, and name the key owner.
4. Pick two monitoring alerts that would catch a bulk export.
5. Run one restore test and record how long it took.
6. Only then write requirements for a tool, based on the gap you found.

Quick check

Sources

• NIST SP 1800-28, Data Confidentiality: Identifying and Protecting Assets Against Data Breaches
• CISA, AA21-131A
• CISA StopRansomware Guide
• NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments

Last reviewed: 18 October 2026.