top of page

02. Proposed High Level DSL Model for GRC Domain

The proliferation of frameworks, standards and regulations, generally in the GRC domain and more specifically in the IT/Cyber GRC domain is a painfully intractable problem in the world of GRC.

02. Proposed High Level DSL Model for GRC Domain

Introduction:


The proliferation of frameworks, standards and regulations, generally in the GRC domain and more specifically in the IT/Cyber GRC domain is a painfully intractable problem in the world of GRC.

The author is inspired by the role of XBRL standards in harmonising the world of business- information/financial reporting across the globe and how it takes the portability of business-information/financial reports to new heights. The same thought is applied for the GRC domain in an attempt to solve the problem stated above.

The idea presented here can then be leveraged across a wide range of functional areas like HR, Legal, Marketing, Sales, Procurement etc., We just need the dedicated time of a few domain experts to prepare a working meta-model for their respective domains.

Thus, if this meta-model approach is followed, the following paradigms will be relatively easy for any software vendor or the clients that buy them:

1.       Converting the standard frameworks to a vendor platform specific framework format is easy. The reverse (to export) is also easy. In fact, we can export to any desirable format.

2.       Converting data from one framework (say NIST) to another framework (say PCI DSS) is easy through the intermediary step of capturing the data in the meta-model level constructs.

3.       Use cases like harmonizing controls across frameworks is possible since the frameworks/standards meta-model definitions are same for any frameworks/standards.


Model Concepts:


The following will be expected (somewhat similar to how XBRL standard was accepted or how containers revolutionized the shipping industry) to happen:

1.       All standards will have the meta-model representation.

2.       All frameworks will have the meta-mode representation.

3.       Pure data (like that of the GRC domain) will have its own meta-model representation. The high-level GRC domain model is explained in the next paragraph. It will have a way to capture the taxonomy (object levels) and ontology (relationship levels) information too.

4.       Meta-model representation of data should be simple, and all the complex model aspects should be shifted into the framework/standard meta-model.

5.       The framework or the standard is expected to understand the meta-model version of the data set.


Proposed High Level DSL Model for GRC Domain:


 


Before proceeding further, at the outset I would state the below vivification points on the proposed model:


1.       This is a very ‘high’ level meta-model that still needs to be developed for its schema/attributes/properties.

2.       Interested/organized SMEs should work together to identify the full domain object lists with its attributes.

3.       Object inheritances should be expected to keep some basic attributes in some basic objects that is inherited by all the domain specific objects.

4.       There may be several ways to resolve a use case like harmonising of controls using the meta-models. The meta-model should be expected to support all popular use cases of that domain.


Runtime model:


1.       Reference data meta-models can be released by the framework/standards expert bodies along with the meta-model version of the frameworks/standards.

2.       The vendor software tools will be able to apply the meta-model level data to any of the meta-model level frameworks/standards and the final outcome will be in the vendor/client expected format of the GRC domain data. It can run in phases as outlined below:

a.       Data Ingress from the source

b.       Conforming Transformations to the data meta-model

c.       Transformation to Expected Formats (using the target framework/standard meta-models). This will be the intermediary data + framework meta-model.

d.       Please refer to point #3 above. We should be able to comfortably merge 2 different data + framework meta-models.

e.       Meta-model to vendor/client specific model transformation

(c & d can be combined if necessary)

f.        Validation and Correction

g.       Data egress to the target platform

 

Each phase above can have its own verification mechanisms before proceeding to the next stage.

 

3.       There are numerous software vendors developing a myriad of applications supporting numerous business activities/horizontal functions. In fact, there may be a large number of applications targeting the same domain.

 

If we target to develop a meta-model-based domain objects system and supporting frameworks/standards (render able in the meta-model format), the world will appear lot easier to both the application vendors and the clients.

© 2035  Powered and secured by Wix

bottom of page