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

Question

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.

Explanation / Answer

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.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.