There are generally two ways to mitigate risk associated with a specific event:

1. Reduce exposure to make it less likely the event will happen
2. Take steps to reduce the impact you'll sustain if it does happen

Risk purists will argue that you can also transfer the risk, but I'd argue that's really just an extension of #2... In the transferred risk model, we let another entity - like an insurance company - share some of the pain so we sustain less in terms of direct impact.

In the information security world, we can design controls to reduce both exposure and impact. In this post, I want to focus on designing controls that reduce exposure.

Classic preventative controls like access controls, encryption, and system hardening usually do most of the work in reducing exposure. These controls are designed to limit access to sensitive information, therefore reducing the exposure of that information to unauthorized disclosure.

But there are other, less obvious controls that can help reduce exposure. For example, I talked to an internal app dev shop once that populates their test environment with data from production backups. This gives developers, QA engineers, and a host of other people access to sensitive information. A simple process to sanitize sensitive information in the test environment would reduce the IT footprint of that sensitive information, thereby reducing it's overall exposure to compromise.

This control (sanitizing data in dev/test environments) happens to be one of my favorites, but there are lots more like it... It's part of a broader class of controls designed to reduce the logical and temporal footprint of sensitive information throughout the environment.

As we design controls around our sensitive information, we should continue to look for ways to reduce the number of systems that store that information and the amount of time for which they store it.