2

I had another question in mind, but thought that I should ask this one first.

Background:

Everywhere I have been in the past has used a tiered policy architecture. What I mean is there is one global Information Security Policy, with general statements on the company's stance on each of the applicable topics of InfoSec. Subsection on Access Controls: Logical access controls must be instituted and enforced on

Under that you would have many Tier 2, topic-specific policies, with more specific statements on the topic. Statement in the Password Policy: Strong passwords must be used to secure all company IT systems.

Finally under the Tier 2 policies were standards, processes, and procedures with specific implementation guidance. Statement in Password Standards document: Windows passwords must be at least 16 characters long.

This structure makes sense to me. It is easier to understand, easier to maintain, and easier to enforce.

I recently started at a new company as the Information Security Engineer. What I've walked into is, to put it delicately, not up to this standard. I've been tasked with picking up the pieces so to speak, and was given a document to start with that heads further down the wrong track. I spent some time looking at current policies, and basically re-architected the Information Security Policy into a tiered structure, rewrote a draft of the IS policy, and a few tier 2 policies as examples. I submitted the drafts for review, and the feedback I received is trying to push back down the path of one behemoth General Controls policy, trying to put standards statements and processes back into a policy document. Needless to say, it was a little frustrating.

Question

My question is what are the pros and cons to using a tiered information security policy architecture vs. one all encompassing policy?

I have my opinions about both methods, and obviously prefer one way over the other. But I also realize that my opinion is formed based on past experiences, so maybe I'm not seeing the light of the other way.

Update

I'm not so much focused on why you should split policies from processes, standards, and procedures, that I understand and can articulate well. I'm more looking for pros and cons of many compact, focused policies vs. one large, all encompassing policy. I've updated the question accordingly.

Craine
  • 349
  • 2
  • 14

2 Answers2

1

The basic idea is that Policies are separated from Procedures because Policies are going to rarely change. They are a high-level view of the intent of the company. Procedures are how that intent is carried out. Those implementational details can vary from department to department and modify over time.

Imagine that the users can have one kind of password complexity requirement, but admins need another. With one Policy and two Procedures (user & admin), you can easily create such a scenario, track and enforce it more easily, and maintain it over time.

By splitting those 2 concepts, you can meet the needs of the company and meet the needs of implementation at the same time.

EDIT

After your clarification, I can say that it's a maintainability issue. An omnibus Policy would need to be reviewed and signed off by each stakeholder all at once, and any change would need to go through the same process. By splitting it up, you can make necessary changes, even small ones, without the need to get the entire company involved.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • Right, so I get why policies and procedure (and standards and processes) should be split (and I hope the reviewer does as well). I'm more concerned with the pros/cons of many focused policies vs one all encompassing policy. I personally find that many focused policies are better, but I'm wondering if there is something I am missing. – Craine Sep 18 '14 at 15:56
  • Frankly, it's a maintainability issue. An omnibus Policy would need to be reviewed and signed off by each stakeholder all at once, and any change would need to go through the same process. By splitting it up, you can make necessary changes, even small ones, without the need to get the entire company involved. – schroeder Sep 18 '14 at 17:20
  • That's a big thing. While I know that the smaller topical policies would be easier to maintain from my work-effort point of view, I couldn't quite put my finger on a concrete, business-minded reason why it would be easier to maintain. If you edit your answer to include that comment, I'll mark as correct. – Craine Sep 18 '14 at 18:56
0

A lot depends on how many people are in-charge for security in the organization (also termed as security organization). It also depends on how complex the organization is.

Case 1:- If you have a very small team and a single decision-maker, then it makes sense to have one, all-encompassing policy document because ultimately the person who-needs-to-sign-off-on-the-policy is the same guy.

On the other hand, if you have multiple decision-makers for different business units, it makes sense to keep individual policies separate.e.g., i have seen companies that have geographically spread business units. So they have separate CISO's for each unit, and a group CISO to manage them all. policy decisions are taken at BU level, whereas group level decisions goto Group CISO

Case 2:- Taking the example above, if an organization is geographically spread, with different type of businesses, their information security needs will also be different. e.g., information security needs of finance industry will differ from those for textile. In those cases, policies need to be in different documents to cater management directives depending on the industry-specific information security needs / controls.

Of course, maintainability is also a factor but i don't put much importance on it. Ultimately, the end-user requirements decide whether policy will be one document or split across many.

M S Sripati
  • 99
  • 4