Creating a Good Policy
A security policy contains pre-approved organizational procedures that tell you exactly what you need to do in order to prevent security problems and next steps if you are ever faced with a data breach. Security problems can include:
Confidentiality – people obtaining or disclosing information inappropriately
Data Integrity – information being altered or erroneously validated, whether deliberate or accidental
Availability – information not being available when it is required or being available to more users than is appropriate
Here’s what all good policies have:
Purpose: Clear goals and expectations of the policy.
Policy Compliance: Federal and State regulations might drive some requirements of a security policy, so it’s critical to list them.
Last Tested Date: Policies need to be a living document and frequently tested and challenged.
Policy Last Updated Date: Security policy documents need to be updated to adapt to changes in the organization, outside threats, and technology.
Contact: Information security policies are supposed to be read, understood and followed by all individuals within an organization and so if there are questions, there needs to be an owner.
Questions to Ask When Creating Your Security Policy
When you’re creating a security policy, it helps to ask questions because in answering them, you’ll learn what’s important to your organization and the resources you’ll need to create and maintain your security policy. Here’s are a few questions to get you started:
Who will you need buy-in from?
Who will be the owner of this security policy?
Who is my audience for this policy?
What regulations apply to your industry (for instance GLBA, HIPAA, Sarbanes-Oxley etc)?
Who needs access to your organization’s data?
Who owns the data you manage? Your organization? Your customers?
How many requests are received per week to provide access to data?
How are these requests fulfilled?
How and when is access reviewed?
How can you ensure that no container will be open to a global access group (Everyone, Domain Users, Authenticated Users, etc) without explicit authorizations from the data owner(s) and appropriate management?
How will all access provisioning activity be recorded and available to audit?
If data has not been accessed for 18 months, how will it be identified and restricted so that only the data owner(s) have access until an access request by another individual is made?
How will you align your security policy to the business objectives of the organization?
Last updated