The Zurich release has arrived! Interested in new features and functionalities? Click here for more

Track SOX in CSDM

sg28
Tera Contributor

Hi,

 

Currently I am implementing CSDM for a client and they are confused from which layer they should track SOX/GXP compliance, is it Business app, App service or Service offering. What does the best practice say?

1 ACCEPTED SOLUTION

CMDB Whisperer
Mega Sage
Mega Sage

The true answer to the question of compliance is about what the control states and how the configuration data can be used to determine whether a CI is in scope of the control, and if so, how it can indicate whether it is in compliance with the control objectives.

 

If you are looking to make a determination of whether an infrastructure CI is in scope, then you need to determine what Application Service it is part of.  CSDM relationships will tell you what Business Application the Application Service was deployed, and what Information Objects are being used by that Business Application.  For example, the Business Application may handle PII data or PCI data.  The Information Objects and their Data Domains are one of the most important elements for determining what compliance controls should apply to the Application Services and Infrastructure CIs.  To get that information you need to query across those CI relationships.

 

So to answer "do I need to include this Windows Server in my SOX audit" what you really need to answer is "is this Windows Server associated with an instance of a Business Application that uses Information Objects that are relevant to SOX compliance?"  When you have determined that the CI is in scope of the audit, then the question you have to answer is, what control objectives exist for your compliance audit, and does the CMDB data provide enough information to indicate compliance or non-compliance with that control, or do you need to look to other sources to perform the audit for that CI.

 

That is the most typical use case that CSDM seeks to address from a compliance perspective.  However, more broadly, the scoping of the audit as well as the indicators you create to measure compliance are based on the criteria of the policies and controls, which may include other factors such as where the infrastructure or application is being deployed, and who it is used by, and that data would need to be referenced from the relevant CIs and included in your audit criteria. 

 

Bottom line: the important thing to remember is that it is about interpreting the controls that you are auditing against, and making sure you are pulling the right information from the right CIs and CI relationships to support your audit.  In practice, Business Applications and Information Objects are where CSDM looks to define much of this compliance information.


The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.

View solution in original post

7 REPLIES 7

CMDB Whisperer
Mega Sage
Mega Sage

The true answer to the question of compliance is about what the control states and how the configuration data can be used to determine whether a CI is in scope of the control, and if so, how it can indicate whether it is in compliance with the control objectives.

 

If you are looking to make a determination of whether an infrastructure CI is in scope, then you need to determine what Application Service it is part of.  CSDM relationships will tell you what Business Application the Application Service was deployed, and what Information Objects are being used by that Business Application.  For example, the Business Application may handle PII data or PCI data.  The Information Objects and their Data Domains are one of the most important elements for determining what compliance controls should apply to the Application Services and Infrastructure CIs.  To get that information you need to query across those CI relationships.

 

So to answer "do I need to include this Windows Server in my SOX audit" what you really need to answer is "is this Windows Server associated with an instance of a Business Application that uses Information Objects that are relevant to SOX compliance?"  When you have determined that the CI is in scope of the audit, then the question you have to answer is, what control objectives exist for your compliance audit, and does the CMDB data provide enough information to indicate compliance or non-compliance with that control, or do you need to look to other sources to perform the audit for that CI.

 

That is the most typical use case that CSDM seeks to address from a compliance perspective.  However, more broadly, the scoping of the audit as well as the indicators you create to measure compliance are based on the criteria of the policies and controls, which may include other factors such as where the infrastructure or application is being deployed, and who it is used by, and that data would need to be referenced from the relevant CIs and included in your audit criteria. 

 

Bottom line: the important thing to remember is that it is about interpreting the controls that you are auditing against, and making sure you are pulling the right information from the right CIs and CI relationships to support your audit.  In practice, Business Applications and Information Objects are where CSDM looks to define much of this compliance information.


The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.

Nilanjan1
Mega Sage

@CMDB Whisperer This is what I am working on as as well there is a SOX field in the TSO and Application services that the client has and we are trying to find an approach how to utilize the SOX field to audit maintain compliance etc. Can you suggest few questions that could be asked or best approach towards this?

Yeah that's what 90% of customers do because it seems like a quick and easy solution to just put a checkbox on a CI form to indicate whether it's a "SOX Server" or a "PCI Server" etc.  The problems with this approach are 1) no one really defines the process for how that data gets filled out, 2) it would be extremely tedious and unreliable to do this manually even if you did define a process, and 3) using a checkbox is inadequate because there is no way to differentiate between an unchecked box that was intentionally left unchecked, and one that just hasn't been evaluated yet.

 

That said, if you do want to have this as an indicator on the individual CIs, you should mark it as read-only and then run a process to populate those attributes programmatically by looking at the prescribed CIs and relationships from CSDM to determine whether a CI is in scope.


The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.

sai12
Tera Contributor

Hi,

It may be more apt to track this information at application service level as all instances of application will not be audited for compliance and only PROD in most cases. How does it work when we integrate this with GRC controls OR APM and see ( a thought) instead of creating custom fields.