Compliance and ITSM

Compliance - the Holy Grail of ITSM?

Are we seeking the Holy Grail?

Now why have we heard so little about compliance in the past few months, there are those who say it’s not quiet at all but I must say that it is, compared to a couple of years ago.

Have we learned how to be compliant, or what to be compliant against? Have we finally learned how to work with and around regulatory requirements? Have we learned to understand the needs and the drivers of our business and the risks? Have we learned to put our ear to the train rails and know when to safety take it away and follow the flow?

I believe not. But I think that we are learning. Here are some Repo thoughts and feelings around compliance today.

REPOing to the community on some topics:

  1. Compliant? What does that really mean?
  2. SAM, HAM, SoX, PCI, DIKW, ITIL, Cobit, Security, Resilience, business, licenses, devops, scrum, agile, buzzzz words… Compliance?
  3. Can you do it, or is it a mythical Holy Grail?

Compliant? Really?

Now if you take the word compliant and put it into a translator, or search on Wiki, you get something like this: abide by others, docile, obeying, obliging, agreeing with a set of rules, adherence to standards, regulations, and other requirements..

Now there are definitely different compliances to be compared to but, in general, you comply with a need or rule set up by others or yourself. Now when that is said:

What does it mean? What we have found during the years, me and my colleagues as well, is that you can basically be compliant to whatever set of rules or policies you like. Whether it is a process or requirement, it doesn’t really matter.

What matters is how compliant you are, and that’s the tricky part. What risk are you willing to take? Do you understand the ‘data or information’ you have? Do you have the knowledge to see the risks and take decisions on the level of compliance you want or need? What actions you need to take?.

Buzz words, compliance, risks?

You might argue that compliance is tied to governance and regulatory requirements, while this may be true, it’s also tied to everything else you do. You might believe that compliance is a control function and a specific rule or policy. Well it is, but if someone else is involved in delivering something to your business then that “someone” might be subject part of a delivery process. Well isn’t that also compliance?

Short list of some buzz words:

  • SAM (Software Asset Management), you want to pay right amount of money for your software, you also want to pay for the software you use etc. To do that you need to control the highest risks and be compliant to software licensing requirements and continuously work with them
  • HAM (Hardware Asset Management), the cost of owning hardware and/or meeting business need with the right capacity on hardware are two good and easily related topics to consider in HAM. Now you need to understand the needs/requirement from business and also have an understanding of finance and suppliers. I would argue that if you take the risk approach and comply with a policy then you are on a good path
  • SoX (Sarbanes-Oxley Act) etc. Now here’s a set of regulatory rules for you to follow. Take a look at your information rating on every system that has an impact on your business and finance. Take a risk approach by understanding which system would create the highest damage if broken. What is the cost if broken? The highest or most expensive ones need to be controlled, the decision needs to be made on the level of authority to approve (money). For example – If the risk becomes a fact and the system downtime or security breach is costing 10 billion, then the decision needs to be made by someone who can approve 10 billion. Now you can decide to continuously control changes or rules on the system or approve the risk. (Decisions can always be made and documented, if they are wrong, then make a new decision).
  • DIKW (Data-Information-Knowledge-Wisdom), if you only have data, or you do not really understand what you are looking at, then you can never be compliant to anything related to that data.
  • ITIL, well what is not part of a possible compliance work? Are you not setting up policies for the processes and routines?
  • COBIT (Control Objective for Information and Related Technology Standards), yes its one way of realizing compliance, it may be too complex for some businesses but it’s worth taking a look.
  • …. Security, Resilience, business, licenses, devops, and scrum, agile, I don’t need to go on do I.

So what do you do, the Holy Grail?

Now here’s one general way to do it, you can apply it to all… the Holy Grail…

It sounds easy doesn’t it? Well it might be and it might be too complex to grasp the benefits that can be there for your business.

1: you need to understand your business, what are the rules, drivers, requirements, and standards. If you do not have a clue where to start, you can always start by following the money. See what rules are on the things that cost most.

2: make a risk assessment; understand what you find in logs, reviews, reports etc. If it feels like that’s something you can redo again, and its worth doing, make it a routine and later make it an automated report or review / controlled service.

3: Review what you found. If you find inconsistencies or things that make you worry, but those in a follow-up / take action workflow with documentation, fixing and reporting. If there are people involved, you need to consider HR involvement and confidentiality.

4: improve and expand, redo the ones you have automated or made controlled… You will quickly find that compliance is expanding and that knowledge and risks are managed. Compliance with the topics you cover increases and becomes more understandable. You also find that one decision made in the beginning may change quickly the more you understand the drivers, so be prepared to be able to make decisions, then adapt and make new decisions.

And last, but not least, have fun, take risks, but DO not try to be compliant to all things and NOT 100%, because it’s not justifiable for the effort and money involved for your business (with one exception – if it’s a rule or policy regarding people’s health or similar, the aim should be to reach as close to 100% compliance as possible).

Harry Repo

Harry Repo

Harry is an project, business and service management consultant that has been working in the IT industry since 1997, currently working for CBO2 Consulting. In his work within ITSM, Project and Governance, Harry always takes the customer's current and specific position with business models to establish and develop improved processes, business value and organizations. He has experience in Business Consulting, Architecture within IT Service Management (ITSM), Management, Software Asset Management (SAM), Financial Management and Governance with extensive background in Project Management, Contract and Bid management, often being a mentor to the steering groups, IT managers and top management representatives.