14 Million Reasons to Update Data Classification Policy

I recently served as an expert witness in a lawsuit where a flawed Data Classification policy was a central element in the case—and ended up costing the plaintiff nearly $14 million. Needless to say, I can’t get into details, but I walked away from the case with a revised appreciation for the importance of Data Classification, and a few key observations worth sharing:

• A Data Classification policy is critical to your organization achieving its information security objectives, as it communicates the types of data your information security program is protecting and the importance of each type. These classifications should ideally cascade through virtually every other policy and differentiate the way data needs to be controlled/treated at different points in its lifecycle.
• Does this data class need to be encrypted in transit? At rest? In a database? How long does this data need to be retained? What attestations are required from a vendor if they have access to this data class? In a security incident, who do we need to notify if this data class is breached? Literally every decision someone in your company needs to make regarding data is influenced by its classification.
• Data Classifications should be well defined, ideally with all data elements of note being defined and classified. A good definition helps to explain the “why” behind the “what,” which we find catalyzes action. Putting specific data elements into the classifications provides the clear and non-ambiguous guidance that your IT, information security and end user teams need to treat the data in accordance with your policies and standards (e.g., source code for Application X is classified as “High Business Impact”).
• Data Classifications should not be generic in nature. For example, using “Sensitive” and/or “Confidential” as classifications is a recipe for disaster because those terms already have a definition that may or may not align with your definition. They also have a connotation and/or denotation that adds ambiguity. Worse, when someone is referring to data as “confidential,” it is often unclear if they are referring to your Data Classification or are just communicating their opinion the data should be kept “private or secret.”
• Data Classifications need to be normalized throughout all artifacts in your company (Acceptable Use Policies, employment contracts, vendor agreements, non-disclosure agreements, Incident Response Plans, etc.). Employment agreements almost always use generic terms like “confidential” and “sensitive,” which if used improperly undermine the intended outcome.
• Data Classification is integral to Data Privacy. Compliance with the General Data Protection Regulation (GDPR) or the California Consumer Privacy Act (CCPA) requires a deep understanding of all data elements, the processes that act on them, and the assets that support those processes (e.g., a Data Map).
• Make your Data Classification scheme “as simple as possible, but not simpler” (thank you, Albert Einstein). That is, have as few data classifications as possible to ensure you can define/differentiate the required treatments.

Data Classification is often the Rodney Dangerfield of policies, “…I tell you, no respect, no respect…”. But, If you have an immature Data Classification policy that generically defines data classifications (e.g., “sensitive” and “confidential”), if you have failed to explicitly define your most critical information assets into your “highest” data classifications. If your AUP, SCA, NDA and/or employment contracts don’t use your data classifications explicitly, and/or if different data classifications are used ambiguously through your policies, you have 14 million reasons to fix it.
That’s a lot of respect!