Indeed, firstly consider the maintenance of this data. Ownership overall of the CMDB as a priority. If you load it in and then it dies in the corner, then elements your GRC program may die with it.
Next, determining the ownership of each record , rather , the ownership of THE THING the record represents. So - which single field on the CI will be used to determine who will own the entity (and thus, the controls and risks) by default. Each of these can be overridden, but to start with - everything generates with ownership defined based on that single field today. (Or you can set defaults).
You should also consider the attributes you need to determine the relevant scope, such as Criticality and lifecycle status, as normal flags you can filter on.
Try not to start with hardcoded string/name value filters, you want to consider longevity and how the dynamics of the organisational data and hierarchy will be represented.
Consider the relationships between the components and what classes they should live with so you can appreciate how you scale and start to ramp up.
What is your scope? Why? Try and align to CSDM latest principles now.
I suggest, if you are using CMDB, for GRC and in the absence of any other decision - start with Business Application.
This promotes the opportunity for Information Objects, without greater consideration.
You can build up and around as you move forward.
Do not boil the ocean!
