by Tim Marley
Over the course of my career, and particularly in the last five to ten years, the topic of data management comes up frequently. In my experience, it usually shows up from one of two directions.
The first is security. Organizations want to know where their most important data lives so they can focus their controls around protecting it.
The second is regulatory pressure. Whether it is credit card data, healthcare information, employee records, or proprietary intellectual property, organizations are increasingly expected to understand not just what data they have, but how they manage it.
Different industries feel this pressure in different ways. Healthcare organizations worry about patient information. Companies that process payments focus on cardholder data. Manufacturing organizations may not handle large volumes of personal data, but they are often deeply concerned about protecting intellectual property or customer designs. The specifics change, but the underlying question is always the same.
Do you actually understand the data you are responsible for?
What “Data Management” Really Means
Data management tends to sound bigger and more complex than it actually is. At its core, it is a practical concept with a straightforward goal. You need to know what data you have so you can begin to understand which parts of it matter most.
That starts with basic awareness. What types of data exist in your environment? Which of those are sensitive, whether because of regulatory obligations, privacy expectations, or business impact? From there, the focus shifts to how that data moves. How does it enter the organization? Where is it stored? Who can access it? Does it leave the organization, and if so, under what circumstances?
Many organizations capture this thinking visually through data flow diagrams, but the format matters less than the understanding behind it. The real objective is knowing the paths data takes through your systems and processes, not producing a perfect diagram.
Why Regulations and Privacy Change the Conversation
Regulatory requirements tend to force data management discussions to the surface.
Payment data and healthcare data are obvious examples, but they are no longer the only drivers. Privacy requirements have expanded the scope of what organizations must consider, often in ways that catch teams off guard.
The data you are responsible for may not belong to the business itself. It may belong to employees. It may belong to customers. In business-to-business relationships, it may belong to your clients. In all of these cases, responsibility follows access, not ownership.
Privacy laws make this especially clear. Depending on where you operate, you may be required to support rights like data access, correction, or deletion. These obligations are most visible in places like the European Union or states such as California, but the trend is broader than that.
An increasing number of U.S. states now have privacy laws that affect what data can be collected, how it can be used, and how long it can be retained. The definitions used in these laws are often broader than organizations expect, which is why data management surprises are so common during audits or legal reviews.
For instance, here’s a quick list of privacy and data protection laws that I’ve come across in my career, many of these I’ve assisted with in the last 12 months:
- GDPR (EU General Data Protection Regulation)
- UK GDPR
- EU Data Act
- EU Data Governance Act
- CCPA / CPRA (California)
- VCDPA (Virginia)
- CPA (Colorado)
- CTDPA (Connecticut)
- UCPA (Utah)
- NY SHIELD Act
- LGPD (Brazil)
- PIPEDA (Canada)
- POPIA (South Africa)
- PDPA (Singapore)
- PDPA (Thailand)
- PDPL (Saudi Arabia)
- DIFC Data Protection Law (UAE)
- APPI (Japan)
- China PIPL
- Australia Privacy Act
- India Digital Personal Data Protection Act
These laws vary in scope and enforcement, but they share a common theme: organizations must demonstrate they understand what personal data they hold and how they manage it. Privacy compliance isn’t just a legal checkbox. It’s proof you’ve thought through your data lifecycle. Beyond privacy laws, industry-specific regulations create their own data management requirements. If you operate in healthcare, finance, education, or critical infrastructure, you’re likely already familiar with at least one of these:
- HIPAA (US healthcare)/ HITECH Act
- GLBA (financial institutions)
- SOX (financial reporting data)
- FERPA (education records)
- CJIS Security Policy (law enforcement)
- NERC CIP (energy sector)
- SEC Regulation S-P
- FINRA Rules 4511, 3110
Industry regulations tend to be more prescriptive than privacy laws, often specifying not just what data to protect but how to protect it. They also tend to have mature audit frameworks, which means expectations are clearer, but enforcement is more consistent.
The third pressure point comes from contracts and industry standards. These aren’t laws, but they carry real consequences. Fail an audit, lose a contract. Miss a certification, lose access to markets:
- PCI DSS (cardholder data)
- CMMC (all levels)
- DFARS 252.204-7012
- NIST SP 800-171 (via contract)
- ITAR (export-controlled technical data)
- CMS MARS-E (healthcare, specifically states that manage Medicaid)
- NAIC Insurance Data Security Model Law
These contractual requirements are often how small and mid-sized organizations first encounter data management expectations. A client asks if you’re PCI compliant, or a contract requires NIST 800-171, and suddenly what seemed like a theoretical exercise becomes very practical.
Where Organizations Usually Get Stuck
Most organizations do not fail at data management because they lack policies.
They struggle because data management gets treated as a documentation exercise. Policies exist, but nobody can answer basic questions: Where does customer data actually live? Who approved access to the finance systems? What happens to employee records after someone leaves?
When that shared understanding is missing, everything else becomes harder. Security controls are applied inconsistently. Regulatory requirements feel overwhelming. Privacy obligations become reactive instead of planned.
What is missing is not effort. It is alignment.
Why CIS Control 3.1 Exists
This is the problem CIS Control 3.1 was designed to address.
The control does not ask organizations to invent something new. It asks them to recognize, align, and document the data decisions they are already making. Who owns what data, how access gets approved, how long information is retained, what happens when it is no longer needed.
That foundation makes everything that follows: inventory, access control, retention, and disposal, achievable instead of aspirational.
Over the next few weeks, we will walk through how to build on that foundation. But it starts here: understanding what data you have, how it moves through your organization, and what responsibilities come with it.
Once you know that, the rest of the conversation stops being theoretical and starts becoming practical.
Tim Marley is a cybersecurity and risk management executive with more than 20 years of experience in IT audit, compliance, and information security. Tim helps organizations strengthen their security posture, navigate regulatory requirements, and manage complex risk with clarity and confidence.
