In many organizations, security policies and standards are unapproachably long and complex, or are so high-level that the reader must be a security expert to fill in missing details. Security policies, standards, processes, and procedures must be written for the people who need to follow, implement, and interpret them, not for the people that write them. These documents need to clearly define expectations and outcomes in a way that can be understood and implemented.
For example, a policy might state “You may not copy files containing company confidential information to USB drives.”
But, what about copying those files to other types of devices, like a home NAS drive that is exposed to the Internet? Or someone’s clever home-brew cloud backup system using an unsecured S3 bucket? Or a cell phone via Bluetooth? And how should employees legitimately back up their data? What happens when they need to copy confidential files to a USB drive? Do they get to figure out the proper controls to apply?
This extends to policies that apply to IT and infosec teams, too. Define the set of outcomes desired and the proper guard rails that need to be applied, at the appropriate level of specificity based on the type of documentation (policy, process, procedure, and so on), ensure employees are familiar with those documents, and provide help to interpret the requirements for edge cases and fold any lessons learned back into policy enhancements and FAQs.