Policies, Procedures & Standards

HomePolicies, Procedures & Standards

Policies, Procedures & Standards

It’s often been said that information security does not exist until it is documented. While that may not be true in the literal sense — it is most definitely true from a liability and/or from an auditor’s perspective. The move to more formal and provable Information Security Management Systems (ISMS) has become a challenge for most organizations as fully documented, metricized, and compliance-monitored Policies, Procedures & Standards are quite rare.

We do not recommend that you outsource the development of these building blocks of your ISMS. Organizations that roll up their sleeves and work their way through this process build stronger, more risk-aligned controls and the employees involved in the development become stakeholders in the controls and champion the value and importance of the ISMS throughout the organization — resulting in a stronger control environment.

That being said we recognize that many organizations lack the time and/or expertise to take on the role fully on their own. To that end we recommend that you consider working with a third party in a “facilitation” mode — leveraging their Subject Matter Expertise and templates/approach/methodology on demand to simplify the process and ensure the success of your resultant ISMS.

When we work to develop Information Security Policies/Standards/Procedures with our clients we strongly recommend that you align your policies with industry-recognized standards (most notably ISO 27001/2, NIST 800-53, and OWASP). The benefit of this approach is these widely regarded standards are essentially the definition of best practice and can be cross mapped to demonstrate compliance with any other regulatory standard (e.g., HIPAA, NERC, SOX) Further, aligning yourself with well accepted standards is the best way to demonstrate “due diligence” and minimize your liability in the event of a security incident.

Policy Development

A cautionary note about “Policy Development”: Many organizations will download a list of policies from the Internet, do a find/replace with their organization’s name and assume they are complete. While this is actually not a bad starting point it’s important to understand the interplay between Policies, Procedures & Standards:

  • Policies are Executive Management’s directives on the controls needed to manage key organizational information security risks. Policies reflect an organization’s business goals, objectives, culture and are intended for broad audiences. Policies should rarely need to be changed. Policies can be relatively simple (e.g. “All information assets should be protected by appropriately strong passwords”). Policies “drive” Standards.
  • Procedures are the Information Technology Department’s specific instructions (ordered tasks) for implementing Policies in accordance with the Standards. Procedures reflect an organization’s technology, personnel, and user communities and may be intended for broad or limited groups. Procedures will need to be changed more often than Policies and Standards but likely not more often than three times per year. A Procedure will be more specific than a Standard and will often be very specific to the organization.  For example, a Password Procedure may define the specific steps for configuring an Active Directory Server in alignment with the Standard. Another may define the specific steps required for a user to reset a password. Multiple Procedures often support a single Standard.
  • Standards are Technical Management’s directives on the process and rules used to support Policies. Standards reflect an organization’s information technology goals, objectives, and strategy and may be intended for broad or limited groups. Standards will need to be changed more often than policies but likely not more often than once per year. A Standard will be more complex than a policy. Multiple Standards often support a single Policy. For example, a Password Standard would define the length, complexity, rotation, and history requirements across different data classifications, operating systems, and/or key applications/systems. Standards “drive” Procedures.

As you can see PSPs are hierarchical and interdependent in nature. Because Policies are relatively common across organizations (~80%), “borrowing” someone else’s Policies actually works quite well. The challenge is that Policies without Standards are of little value. Because Standards are more specific to organizations’ specific risks/technologies/personnel, “borrowing” Standards is an exercise in frustration. They may be 50% common. Procedures are so unique to an organization that it is likely easier to start from scratch.

Another cautionary note – changes to Policies, Procedures & Standards should all go through a formal approval process. For that reason segregating Policies (which rarely need to be changed) from Standards, and Procedures (which often need to be changed) will reduce the administrative burden of updating PSP’s.