Although it may seem like a painfully obvious omission, the truth isthat many companies have no real security policy. And of the policiesthat do make it onto paper, many go the way of screenplays written bystruggling writers--passed around a lot, occasionally asked after butnever really read. "The omission of a formal security training schemeis the norm," says Michael Casper, information security officer atWachovia Bank. "So simply having formal training materials andimplementing them is paramount to the beginning of security educationsuccess."

An effective security policy must first of all be put in writing. Andin doing so, it should clearly spell out every last detail of companypractices, such as how information technology employees shouldidentify themselves when contacting a remote user about a technologyproblem, what types of e-mail are appropriate and how often usersshould reset their passwords. In addition to emphasizing securityinside the building, a security policy should also address the dangersthat lurk outside--including the risks of using laptops on businesstrips or carrying data on PDAs.

"It all boils down to a company having a solid yet understandable datasecurity policy and procedure program," says Data Security Auditors'Hughes. "You know, making sure everybody knows what's OK and what'snot OK."

Just as important as creating a policy, says Razorpoint's Morse, ismaking sure that the policy is uniform across all company locations.An organization that lacks consistency in its policy is vulnerable tosocial engineering attacks, for example, where a hacker can gainaccess to data or passwords by calling an employee and pretending tobe from another location within the company. "In a word, people haveto verify," Morse says. "They have to be able to say, Who is thatperson, and how do I know?"

The tricky part lies in massaging a policy so that it protectsvaluable data while allowing users the flexibility they need to dotheir job. Providence Health Plans' Apgar tells of an incident at hiscompany when, upon discovering that Providence shared some systemswith another health-care company, Providence had to put controls inplace. The problem was the systems had little capability to limitaccess, so Apgar needed to do it without cutting off his own usersfrom information they needed. "Data security got in the way ofitself," he says. "Instead of the security people saying, Maybe weshould look at this and see if we can live with it, they said, Oh, theattorney said to do it, so we'll have to turn it off." After carefulconsideration and some heated discussions, Apgar's group made thedecision to build new controls into the system at minimal cost, whichended up working to everyone's satisfaction. CSOs must first take thetime to understand the business and users' needs before settinglimits.