In over thirteen years with mountain rescue and five years as a ski patroller I participated in countless search and avalanche drills, and a fair number of real incidents. Search in the real world, as in the computing world, is difficult due to the need to balance performance with thoroughness. In a rescue situation you need to find the victim as quickly as possible; a thorough search has a higher Probability of Detection (POD), but takes longer. Assuming you’re looking for a live victim this time can mean the difference between a rescue and a recovery.

Since detailed searches also take time to gather resources (searchers), most searches/rescues start with what’s called a hasty. A hasty search is light and fast- you send out a smaller, faster team to scour the area for obvious clues. The probability of detection is low, but you don’t need a 50 person team with full gear to find a half-burried skier in an obvious tree well in the middle of a deposition zone (where all the snow ends up after an avalanche). I’ve been on a bunch of hasty teams in real-world searches (no avalanches) and would guess that we found the victim before the big search was launched somewhere around 20-30% of the time.

A hasty is effective because it’s designed to maximize speed while finding anything obvious in critical situations.

We can adapt the principle of the hasty for data classification. Many classification programs fail because they attempt to solve the entire problem while taking too long to protect the critical assets. In a hasty classification program you focus on a single critical data type and roll out classification enterprise wide. Rather than overwhelming users with a massive program, focus on one kind of data that’s clearly critical in a very focused program to protect it. It’s a baby step to protect a critical asset while slowly changing user habits.

Data Classification Type 1: Hasty Classification

The short version:

  1. Pick one critical type of data. I suggest credit card numbers, Social Security Numbers, or something similar.
  2. Have business units tell you where they use it and store it.
  3. Issue security policies for how that data needs to be secured.
  4. Work with units to secure the systems
  5. Security helps the business units secure the data, while audit plays the enforcement role. This makes security the good guys.
  6. Keep it updated with ongoing audits and regular “compliance” reporting of where and how data is used and stored.

Same process, with more details:

  1. Design your basic classifications. I suggest no more than 3-4, and use plain English. For example, “Sensitive/Internal/Public”. If you deal with personally identifiable information (PII) that can be a separate classification, and call it PII, NPI, HIPAA, or whatever term your industry uses.
  2. Pick one type of critical data that is easy to recognize. I highly recommend PII- credit card numbers, Social Security Numbers, or something similar.
  3. Get executive approval/support- this has to come from as high as possible. If you can’t get it, and you care about security, update your resume. Beating your head against a wall is painful and only annoys the wall and anyone within earshot.
  4. Issue a memo requiring everyone to identify any business process or IT system that contains this data within 30/60/90 days.
  5. Collect results.
  6. While collecting the results, finalize security standards for how this data is to be used, stored, and secured. This includes who is allowed to access it (based on business unit/role), approved business processes (billing only, or billing/CRM, etc.), approved applications/systems (be specific), where it can be stored (specific systems and paper repositories), and any security requirements.
  7. Security requirements should be templates and standards with specific, approved configurations. Which software, which patch level, which configuration settings, how systems communicate, and so on. If you can’t do this yourself, just point to open standards like those at
  8. Issue the security standards. Require business units to bring systems into compliance within a specific time frame, or get an approved exception.
  9. IT Security works with business units to bring systems/processes into compliance. They work with the business and do not play an enforcement role. If exceptions are requested, they must figure out how to secure the data for that business need, and the business will be required to adopt needed alternative security controls for that business process.
  10. After the time period to bring systems into compliance expires, the audit group begins random audits of business units to ensure reporting accuracy and that systems are in compliance with corporate standards.
  11. Business units periodically report (rolling schedule) on any changes on use or storage of the now-classified data.
  12. Security continuously evaluates security standards, issues changes where needed, and helps business units keep the data secure.
  13. Audit plays the enforcement role of looking for exceptions.

I know some of you are sitting there going, “This is the easy way? I’d hate to see the hard way!”

The hasty classification is really an entire data classification program, but focused on one single kind of easily identified data. When you think about it, you’re just picking that critical data, figuring out where it is, helping secure it, and using audit to make sure you’re doing what you think you’re doing.

When I discuss this with people I prefer to lay out all the steps in detail, but most of you will adapt it to suit your own environment. The key is to keep it simple, pick one data type to start, and separate between those securing the data, and those verifying that the data is secure.

In our next post on this topic we’ll talk about how to grow this into a complete program. I’m even working on pretty pictures!