The policy bootstrapping problem.
Here’s a question for you all playing along at home: do you ever delay rolling out a new official security policy?
There are plenty of policies that cost money to implement: systems have to be reconfigured, applications have to be rewritten (and in some cases massively redesigned), business processes have to change—these all cost time and money that your organization may not have in sufficient amounts. You want to do the right thing, but you know you can’t do the right thing all at once.
So do you put the policy on the books, knowing there’s a risk that auditors will come along and use the policy against you because you’re not actually quite following it just yet?
If you don’t publish the policy, how will people know about it so that they can start following it as soon as they can?
I tend to cheat. I roll them out as guidelines first. I start talking them up, especially to the groups that are best positioned to start following it early (such as those writing a new application), and warn them that at Some Point in the Future, they’re going to become official, so I’d like to help them work on aligning with them now. This creates the impression that I’m trying to help them get a leg up—why, it’s almost like helping them cheat on a test that hasn’t come up yet. The news is often received better that way, as long as nobody panics when they first hear of it.
More what you’d call “guidelines” than actual rules.
(Only a few days late posting, me hearties ...)
on 09/29 at 02:31 PM:
I’ve used a similar cheat in the past. I’ve released “draft” policies or standards (more the latter) with an expected go-live date well in the future (one that’s fully amendable). All the communication focuses, then, on “this is the expected performance going forward.” fwiw.