Data security management is the ongoing work of knowing what data you hold, deciding how sensitive it is, protecting it while stored and in transit, controlling who can reach it, and disposing of it when it is no longer needed. It starts with an inventory, not with a tool.
What does the work consist of?
The pieces are the same in most frameworks. NIST SP 800-53 Revision 5 expresses them as controls that you can use as a checklist even if you are not a federal system:
Know your data and systems. Control PM-5 asks for an inventory of organizational systems. Control RA-2, Security Categorization, says to categorize the system and the information it processes, stores and transmits. You cannot protect what you have not found and ranked.
Protect data in transit. Control SC-8 covers the confidentiality and integrity of transmitted information, which in practice means modern TLS and encrypted internal links.
Protect data at rest. Control SC-28 covers protection of information at rest, which means encryption of disks, databases and backups, plus key management. SC-13 covers the use of appropriate cryptography.
Limit access. Control AC-6 states the principle of least privilege: allow only authorized accesses that are necessary to accomplish assigned tasks.
Manage retention and disposal. Control SI-12 covers managing and retaining information in line with laws, policies and operational needs. Control MP-6 covers sanitizing media before disposal, release or reuse.
Monitor. Control CA-7 covers continuous monitoring of control effectiveness, and SI-4 covers system monitoring for attacks and indicators.
The NIST Cybersecurity Framework 2.0 groups much of this under Protect, in a category for data security, with Identify and Govern around it for inventory and ownership.
What does a classification scheme look like?
Keep it small. Three or four levels are enough: public, internal, confidential and restricted. Each level has rules: who may access it, whether it must be encrypted, where it may be stored, how long it is kept and how it is destroyed. A scheme that nobody can remember is not used.
Where does it go wrong?
Teams copy production data into test environments, where controls are weaker. Backups are encrypted but the keys sit next to them. Exports to spreadsheets spread data beyond the system that controlled it. Access is granted for a project and never removed. Logs capture secrets or personal data and are retained forever. Each of these is a management failure more than a technology gap.
Constructed example: the test copy
A company restores a copy of its customer database into a test environment so developers can reproduce a bug. The test environment has shared logins and no encryption. Six months later the copy is still there. A review under the retention and categorization steps finds it, ranks it as restricted data in an unrestricted place, and the team replaces it with masked sample data and adds a rule that production data cannot enter test systems.
What about data inside software?
Source code, build artifacts and tokens are data too. Secrets committed to repositories, tokens in build logs and customer data in debug output all leak through the development process. Scanning commits for secrets and reviewing logs for sensitive fields catch some of this early.
How to check or apply this
- List the main systems holding data and name an owner for each.
- Define three or four classification levels with specific handling rules.
- Classify the top ten datasets by risk and verify encryption in transit and at rest for each.
- Review access to the restricted data quarterly and remove what is unneeded.
- Set a retention period and a disposal method for each class, and test one disposal.
- Search test, analytics and backup systems for stray copies of restricted data.
- Keep logs of access to restricted data and review them.
Quick check
What is the first step in data security management?
An inventory of what data you hold and where it lives, followed by classification. Controls depend on knowing both.
Is encryption enough?
No. Encryption protects against some risks. You also need access limits, key management, retention rules, disposal and monitoring.
Sources
- NIST SP 800-53 Rev. 5 control catalog, PM-5, RA-2, SC-8, SC-13, SC-28, AC-6, SI-12, MP-6, CA-7 (OSCAL, NIST GitHub)
- NIST Cybersecurity Framework
Last reviewed: 18 October 2026.
