Getting started with mapping COBIT 2019

TrevorK · ‎01-28-2022

We are looking to get started with using Policy and Compliance Management for COBIT 2019. We are a long time GRC customer, back to the very first release, and are looking to upgrade to the latest version of GRC. Unfortunately, we won't be using UCF so are creating the mappings ourselves. Luckily we don't plan to use more than a couple frameworks.

While watching the videos, tutorials, and starting guides I have come with the following starting points:

Create a Content Reference for COBIT 2019
Create an Authority Document for COBIT 2019
Use the related list to link the Authority Document for COBIT to the Content Reference for COBIT 2019 (it's my understanding this is done so we can look at the Content Reference and see Policies we have created and that as well from a single view)
Create Citations

Does the above seem correct so far?

For the Citations, I am looking to create a Citation for each Objective and Practice. Do I use the Parent field to link the Practice to the Objective then? What I have thought is entering the following for citations: EDM01, EDM01.01, EDM01.02, EDM01.03. Then, I will populate the Parent field for EDM01.01, EDM01.02, EDM01.03 with EDM01. This would "link" the Objective (EDM01) with the Practices (EDM01.01, EDM01.02, EDM01.03).

Does that seems correct?

My last question revolves around some of the information that COBIT 2019 is storing that I would like to capture. I would like to also attach the Area and Domain to each of the Objectives, however there are not fields for these OOB. Our compliance people understand EDM is Evaluate, Direct, Monitor but I suspect anyone outside that world would have no clue. Creating new fields on the Citation table is possible, it just seems like it would get really dirty as you do that for all the frameworks. I could create a custom table then that links to the Citation to store this information and use the class to filter it down nicely to the "additional information" I care about. This is only needed for the Objectives, as the Practices relate to them.

I lean towards the custom table as I can picture it working really nice (having a parent table, then extending it for each of the frameworks we use so we can create the framework specific fields). Using OOB would mean I create many, many fields as each framework might have it's own attributes I care about. Not an ability problem, we do heavily customize and have that experience. But I'm hoping to find out the best practices.

Thoughts? How are you handling this? I can see my questions being really important when you have many frameworks so I hope it's a common set of questions.

Phil Swann · ‎01-28-2022

Some great questions.

First two points yes, although Content Reference isn't THAT important right now, I do see a lot of potential for this; and it needs to be taken more into consideration - so to see you put it first, I think is a really positive start. Just try and maintain it, and also consider including all the OTHER content connected too...=

Parent field is available on most content records.

Once you have the citations, you will need the internal control objectives. And then map those to the citations.

Not sure why you need a custom field. If you need additional reference/choice fields, in most cases sn_grc_choice will suffice; and provides 3x fields OOTB on all document, content and item table classes. classification, type and category.

beyond that if you really want to describe something with ANOTHER field, just go back and make sure this isn't actually a separate THING, and really the entity scoping and hierarchy should evolve a bit... if it needs a field, will the content and item need to be sync'd ? will this require controls to revert to draft ?

You say " might have own attributes " , what do you mean by that ? how many ? where ? why ? the document/content/item model is fairly robust

And plus, one field or 10, once you change the default form layout - you need to maintain it for every upgrade. much better to add custom fields to custom form sections - if you can, and also remember... Now/Next UI is coming...

sounds you like just need to start getting the content loaded and play around with it.

one problem i have seen with COBIT in particular, is that some organisations write their POLICIES based entirely on COBIT, so the INTERNAL (POLICY + CONTROL OBJECTIVES) frameworks are almost 1:1 match to EXTERNAL (AUTHORITY DOCUMENT + CITATION) frameworks, and that duplication in SN seems wrong... (it might be); just accept it, and put up with the duplication for now. Consider how your internal policies could be refined and streamlined to satisfy multiple external requirements, with the internal best practices - as you move forward...

Always start by focusing on what is most important. Normally that starts with getting the content in, and then the controls can start to be scoped, measured and mapped to the Risks... and go from there.

TrevorK · ‎01-30-2022

Not sure why you need a custom field.

COBIT has Domain and Area that I can potentially see someone asking me to capture. As well, those unfamiliar with COBIT might want to know if it's an Objective or Practice.

As I type this out, I really wonder if this will be a problem. Someone who does not know an Objective and Practice likely does not need to know it's an Objective or Practice (I mean, it is pretty clear). However, I still ask myself if I will be called upon down the road to have those values there for something like reporting.

I just don't know if it's good practice to modify the OOB table to add such COBIT specific fields.

sounds you like just need to start getting the content loaded and play around with it.

Yeah, I have tossed in the Objectives and Practices. Then I created the Parent relationship to map the Practices to the Objectives. I tried to follow the OOB stuff for the old COBIT version and I was able to map the fields as such. Thoughts on this so far?

What I didn't like is that the Name is the actual name. A lot of people might want to refer to it as APO01. Being that Name is the display value for the record, that's what you would typically see when you link it and part of me thinks having APO01 at the front would be nicer. But I know SN had the OOB old COBIT version split apart like this, and I'm not sure if it was simply a UCF thing or if there is a bigger reason.

one problem i have seen with COBIT in particular, is that some organisations write their POLICIES based entirely on COBIT, so the INTERNAL (POLICY + CONTROL OBJECTIVES) frameworks are almost 1:1 match to EXTERNAL (AUTHORITY DOCUMENT + CITATION) frameworks, and that duplication in SN seems wrong... (it might be); just accept it, and put up with the duplication for now. Consider how your internal policies could be refined and streamlined to satisfy multiple external requirements, with the internal best practices - as you move forward...

Thanks for the heads up - that was going to be one of my future questions. With our COBIT implementation, we try to stick to what COBIT prescribes as much as possible.

If we are simply using COBIT as written, could we not just have our custom made Control Objectives reference the Citation (instead of a Policy)? From what I had gathered, the big distinction was a Policy was something we wrote / modified, but a Citation was something from an external entity.

I am not sure if I am missing something, but I was assuming we could use our own Control Objectives with the COBIT Citations.

Thank you for all your help!

JohnJasinski · ‎01-30-2022

COBIT 2019 - NOW Hackathon in 2020 NOW GRC. YouTube – 3:46 minutes (turn up volume) ????

Also see K15 Breakout on COBIT

TrevorK · ‎01-30-2022

Thank you, that was an interesting video to watch the walkthrough of your accelerator!

Why did you go with Policy instead of Citation? Is it so that you could customize Policies to your organization? Or is the best practice to simply have Policies be what you do and Citations be what the framework states? I just struggle with that because Citations have a relationship to Control Objectives so I instantly think that's a valid way to set it up as well.

I think this is the stumbling block I am seeing right now. I see that I can do Control Objectives off of Citations, so I am wondering why we would make a Policy that mirrors a Citation. We are looking to do some other frameworks, such as PCI DSS, which will also be very prescriptive. But I see that Policies also have an entire lifecycle where I can assign ownership, go through approvals, etc. which Citations certainly do not.

I am not sure if this is what another person mentioned - that they will be duplicated and to just accept it. However, I am sure there is a reason to use Policy instead of Citation, so I would love to hear what that is as I am missing it!

Thanks for all your help!