The IT Skeptic - Comments for "How does IT survive with no policy framework?"

IRS are in a league of their own

skeptic — Fri, 30 Sep 2011 02:33:00 +0000

Whilst it is true I pick on the USA, I would point you to the Economist surveys that show NZ is one of the easiest countries in the world to do business. I'd also add that the vast majority of New Zealanders have no need to file a personal tax return or to engage an accountant. Tax is automatic.

I find the NZ IRD website very helpful, e.g. I research international Dual Taxation agreements for my business now and then.

Whereas I found my dealings with the IRS drove me to the brink of madness.

[Updated] I can phone the NZ IRD and get a polite and helpful human but I searched for ages to find an IRS number for international tax, and when I finally did ring the woman who answered was first surprised then clearly pissed off that the phone had actually rung. She proceeded to be obstructive and was even more pissed off when I tricked her into confirming what I needed to know.

Sorry if my baracking offends. I figure the USA is big enough to take it.

Tax law in New Zealand is so much better?

itsm_stephen — Thu, 29 Sep 2011 20:51:00 +0000

I went and spent about 5 minutes on Google trying to find some list of "complex tax codes" - while I didn't have much luck in that, I did find this interesting slide deck (in pdf):

http://www.irs.gov/pub/irs-soi/10rpresconenhance.pdf

Apparently the US Agency, IRS, paid some Dr. Sawyer, Professor of Taxation, at University of Canterbury in Christchurch, NZ to some research (or maybe just present) on Enhancing Compliance through Improved Readability.

The only point I have about this is, while it may (or may not, but probably is) true that the New Zealand tax law is easier to understand than the US tax law, according to the good Professor Dr. Sawyer, over 2/3 of the New Zealand tax law is written at or above an undergraduate level of education. Fortunately for New Zealand they tend to have higher levels of education - but this still leaves half the adult population presumably not educated enough to read the majority of the Tax codes!

The problem is probably far worse in the good 'ol US of A but we don't need to be reminded of our (many) problems when the Kiwi's have (several) problems of their own they could use to make good examples.

Now, to try to make this all nice and tidy, it seems to me then that the problem would not only entail "Do we even have the right policies in IT" but also include "Are they written in such a way to be understood?!"

What good would it do you to have some policy on "Appropriate use of iTunes" (as a crazy example) if it was written by this guy:

http://www.itskeptic.org/list-itil-v3-roles#comment-8396

from a long time reader, infrequent caller (or commenter?)

lists of policies

skeptic — Wed, 28 Sep 2011 19:50:00 +0000

Much as I appreciate you contributing, your perspective is exceedingly narrow; just security. There is much much more to policy. It worries me if such a huge list of policies can be generated by security wonks alone.

How can a staff member possibly be aware of the existence of all those policies, let alone understand the implications for them of each and every one?

Now scale that up to all the other organisational policies.

How do you make them aware and educate them in a systematic manner?
How do you give a staff member a list of all policies and only those policies that apply to their role?
How do you decide which policies are more important? What order to work on developing them? Which ones are subsets or elaboration of others? How should they build on each other?
And so on...

Sorry but lists like this are worse than useless - they make the task look hopeless.
And if you ever get them all in place it will be like American tax law: you can't hope to know it all but they are still gonna nail you if you transgress.

I know I am posting about 18

bintekster — Wed, 28 Sep 2011 07:39:08 +0000

I know I am posting about 18 months after this was brought up but thought I'd share anyways. Skeptic, I feel your pain as it has taken me some years and time of hashing through this stuff to make any sense. I recently did an ISO 27002 to Policy mapping to provide an initial roadmap for a customer. I will post here the Policies mentioned in the ISO framework. Each policy mentioned also goes into detail as to what 'should' be covered in the Policy but ultimately you and the business have to decide what does and does not apply. Aside from the list ( of which I will post down below ) http://www.sans.org has a wonder Policy Primer pdf that goes into what the whole Policy, Standard, Procedure thing is about and then gives you some high level primer policy every company should have. After that they also list a nice set of policies that may apply to the business you support with a lot of great templates you can borrow from.

I hope this post helps you some. :)
Enjoy

List of ISO Policies

Framework Clause Policy Road Map
ISO 27002 5.1.1 Information Security Policy
ISO 27002 7.1.3 Acceptable Use Policy (see also 10.8.1.d)
ISO 27002 10.5.1 Information Backup Strategy Policy
ISO 27002 10.8.1 Information Exchange Policy
ISO 27002 11.1.1 Access Control Policy
ISO 27002 11.3.3 Clear Desk Policy
ISO 27002 11.3.3 Clear Screen Policy
ISO 27002 11.4.1 Use of Network Services Policy
ISO 27002 11.7.1 Mobile Computing Policy
ISO 27002 11.7.2 Teleworking Policy
ISO 27002 12.3.1 Cryptographic Policy
ISO 27002 15.1.2 Intellectual Property Rights Compliance Policy
ISO 27002 15.1.4 Data Protection and Privacy Policy

I need a framework

skeptic — Thu, 25 Mar 2010 10:42:29 +0000

Thank-you John. Good thoughts but I need you to come down about 30,000 feet in abstraction.

I know the theory, I need a framework that answers the concrete questions in my post.

Policy - think documentation hierarchy

John E. Jasinski — Wed, 24 Mar 2010 14:56:51 +0000

Some quick brainstorm thoughts: Lack of clearly defined policy is the primary source of process variation. Ed Deming suggested this with his 85 / 15% rule over 50 years ago. ISO 9k suggests a hierarchy of policy, process, procedures and work instructions / details repeated in the ITIL Glossary of Terms. To keep things simple for basic ITSM, consider using language from ISO20k as policy, ITIL as process, then have the people that do the work define procedures; work instructions / details generally include a customization of the tool documentation. This approach takes advantage of several basic realities. 1) Policy is mandated with the statement of you "shall" do this - ISO content provides a low bias source - relatively constant - minimal development cycle time. 2) ITIL is taught as process all over the world - leave it there - ITIL does not describe policy or procedure - it does help suggest procedural elements. 3) Using reference models accelerates the diffusion of innovation. 4) If the people who do the work create the procedures they're much more inclined to be care about performance - buy-in. 5) the people creating the documentation are humans. The book from the Achieving ISO/IEC 2000 series addresses some of these concepts in "Managing decisons and documentation" - see chapter 8 (BIP 0030) (ISBN 0580474585).

Often we find documentation a mix of all types of process related information from policy defined at a task level, to metrics and roles and responsibilities to micro details. Each of these are different elements. ITIL and COBIT documentation clearly separate framework components for a reason. It makes it understandable. This approach is simple and it works. If you start with process maturities less than level one, this approach can help accelerate improvement. ISO 20k's not perfect but when you have no IT policies, how much creativity is needed? And, who can argue with a policy that suggests all changes shall be recorded?

If documentation is a mix of policy, process, procedures and work instructions the shelf life is very short. How often should you need to update policy and process for incidents? I suggest policy and process should withstand organizational changes and be subjected to CAB / Config control. If you mix in procedures and details and tools and organizational unit IDs, with policy and process, and then mix it all together, it's tough to identify the contents and update when needed. Poorly designed documentation can increase process variation over time. This is what we typically have in IT today. Think of how you can increase the life expectancy of your documentation. Separate out the component parts, use the reference models to your advantage and customize your procedures heavily until you minimize your variation. This could be called a common sense approach. Keep IT Simple Smartie!

Oh, back to policy, granted some functional IT groups use the term policy at different levels, like in security or storage. Fine, preface your definitions properly such as IT Security policy, or ITSM Configuration process. An IT policy framework does not exist but the documentation hierarchy does exist - we should all understand the opportunity it provides to improve IT.

Signed, a Skeptic Fan
Thanks for the opportunity to share!

get in the box

skeptic — Tue, 23 Mar 2010 19:25:00 +0000

Et tu Joseph? I disagree strongly: the fadurking sysadmins need to get in the box before they REALLY break something. Don't foster prima donnas.

Every professional wants to know what rules and KPIs they work under. When they make decisions they want them to be informed ones that act in the best interest of their employer. It's called work.

IT Policy and Governance

Joseph Kern — Tue, 23 Mar 2010 15:05:50 +0000

Often sysadmin make things work in-spite of local policy rather than because of it. At least in my experience. "Good" sysadmin want challenging and rewarding work; not mindless processes and best practices.

I am excited about IT policy and governance in only one major respect: this may allow IT a proper seat at the business table. Rather than being forced to implement and maintain poor strategic business schemes (and then blamed for their failure); IT has the chance to create a better business through externally acknowledged processes.

But, this introduces barriers and red tape to the sysadmin. Apprentice and Journeyman sysadmin should be only gradually introduced to these concepts. Raising caring and intelligent sysadmin is hard. Processes are easy. We need to find a balance for both in this brave new world.