Click here to learn more about author David Schlesinger.

Very seldom do we wake up in the morning with excitement about spending the day defining data policies. Little do we know that this can become a worthwhile activity and can eliminate myriad problems in the future for data administration and protection.

While there appear to be more interesting ways to spend a day, often the lack of good policies forces you into long interminable meetings with unclear solutions (These are worse than writing policies). Along with the operational business definition of information, and its companion, the technical specifications regarding the type of data and string length, there must be the regulatory sensitivity of the information. Often this definition is not included in the enterprise model and thus, must be discussed again and again each time data is manipulated, re-platformed or moved. Lack of a central reference and a common language of policies is a gap that needs to be filled by people, an expert at working with information – this would be you.

While there are many, many laws, regulations, contractual agreements and standards to meet, they mostly demand a small number of actions for protection.

• Private data needs to be protected from accidental exposure, from being included promiscuously on report screens where it is not essential, and from being transmitted in a manner that can be intercepted and compromised.
• Some health-related data requires all this, plus the person viewing the data has the specific responsibility and role that HIPAA demands. This introduces “Allowed-to-Know” limitations.
• Customer and employee data require protection for different reasons but their protection policies can often be identical. These may include keeping their data out of the Data Warehouse, or severely limiting access and even encrypting it. PCI contracts demand that some passwords and other related transaction data be kept in an encrypted form. It also requires you to create false “Canary” accounts. Ask your security partners about that one.
• Trade secrets and plans for future products, mergers, divestitures and expansion may also be sensitive and require protection that would be best defined by Corporate Counsel. Lacking their input, access not only should be highly limited to those who need to know and also not kept in the same data stores that will be the future target of hackers. You are not always alone on your network these days, in case you have not noticed.

Finally, developing clearly defined and written policies on which types of data is sensitive and how it should be protected eliminates a lot of guessing, mistakes and unfortunate surprises. The written part is most important, since actually writing it down forces you to think out clearly what actions you want to occur. For example, “be careful” is not a policy; it is a plea for mercy.

All data security policies need to specify protective actions that must be taken to properly protect sensitive information. Only specific actions can be audited and the Iron Law of Compliance is:

“No protective compliance can be proven to have occurred without the audit trail of a completed action.”

Your data policies need to demand specific actions related to each type of sensitive information. Some types are covered by regulations, while other data types are left up to each company to protect.

• Does the data require that the users need to have their computers encrypted to authorize access?
• Are there limits on how much data may be downloaded at any one time?
• Does the data itself require that it be kept separate from the rest of the database tables?
• Does it mandate encryption at rest?
• Can it legally be shipped across national borders?
• Is there a regulation regarding backups and copies?
• Is there a problem with downloading the data daily to an application on a web server?
• Is it allowed to sit unprotected in transaction systems for performance reasons?

These are a few of the actions-required questions that a policy would address for each type of sensitive data.

Actions Speak Louder than Vague Platitudes – The Iron Law of Data Protection at work

Amazingly, when you boil away everything but the actions required by laws and corporate decisions, you discover that most of these regulations and protection decisions overlap significantly. Thus, one set of protective measures may serve to protect several different types of information.   By selecting the most stringent combination for an aggregation of data, you will have not only complied with all laws and contracts, but also made your data administration easier since you need not tailor each specification to each type of data. (Complexity is the enemy of data security – and the enemy of leaving work early.)

Having a central location for data sensitivity definitions and connected data policies will allow knowledge workers across a globally distributed enterprise to protect and manage the data uniformly, thus reducing those business areas where it lies unprotected for the malicious hackers to scoop up. (Consider how many hacked companies kept their password list unencrypted for “performance”!)

Your main purpose in attending policy meetings is to make data sensitivity definitions crisp and the protective actions clear. Given crisp and clear specifications, any methodology can design systems to include data protection as an integral part of its design and not an add-on that slows down business.

Policies are your friend, and become your go-to documents when contemplating how to arrange specific data architectures.  So wake up on policy day with a song in your heart, you are creating helpers.