Business Applications - Mapping to Regulatory Requirements (PCI, SOX, SOC2 etc)

[RichieP]

Hi All,

We have a relatively immature deployment of APM and are really at the Crawl stage of deployment, with the exception we already have some levels of capability modelling, so have included this too.

We do not have IRM, GRC or similar modules in use and there is no immediate plan to do so right now.

As we define our Business Applications, we want to track which of these come under various regulatory requirements such as PCI, SOX etc.

There are a few ways to find some of this retrospectively, ie anything deployed in to a PCI environment may be considered in PCI scope, however Business Applications should be created ahead of any actual deployments and wouldn't necessarily be captured post deployment (ie SaaS would be less clear). 

Other options are

1. Specific attributes for each (least favourite option)

2. Multi Select field to opt in to specific requirements

3. Tags

How are others addressing calling out which Business Applications require specific standards to be adhered too relating regulatory requirements in APM?

Thanks in advance!

[AndersBGS]

Hi @RichieP,

I know you said that you don't utilize GRC, but I would strongly recommend you to look into this, if you would like your CIs mapped as entities according to regulatory requirements etc.

If my answer has helped with your question, please mark my answer as accepted solution and give a thumb up.

Best regards

Anders 

[RichieP]

Thanks @AndersBGS 

Totally agree, and that is being explored, but won't be a quick effort if agreed. But yes, once we have this we would obviously use the controls to align to apps and monitor compliance.

For now I'm keen to see how folks are tagging their apps in APM to highlight in the short term what scope applications fall in to, I know there must be a fair number with APM and not using the native GRC modules.

Thanks

[mcastoe · Accepted solution]

Hi @RichieP ,

Without having GRC/IRM, i have seen a couple successful approaches.   THe key is to evaluate what kind of outputs you need such as "give me a list of business application that have PCI" or "a list of Application owners where the application are subject to SOX".  Often this is easiest accomplished with a handful of attributes.  The muti-select, glidelist, attributes are horrible to use in reporting or list filtering etc.  

For those customers who are adverse to adding attributes, I have seen the data captured via Assessment assigned to the IT and/or Business Owners or perhaps a Solution Architect associated to the application.  Reporting is a bit more difficult but you do avoid adding attributes.  By the way, this is mostly how IRM / GRC gathers the information.

Tags?  im not a fan, too easy to create new ones, duplicates and reporting is poor.  

Finally, this may not be a full solution  but Information Objects provide a Classification capability where you can identify particular Info as PCI, PHI whatever alphabet soup regulatory you need.   The Info is associate back to the Business Application and therefore implication is the App has PCI etc.   Reporting is again a bit more difficult.   That is why i always look at what are the outcomes that are required.

hope this helps,

mark

[RichieP]

@MCasas this is great info, thank you.

We are exploring the GRC/IRM options, and if the related architecture artefacts is a mechanism used in helping to join these normally, then this could be a good option.

I get your point on multi select/glide, and albeit in the GUI it will seem like a great option, we do have lots of downstream reporting requirements across different use cases, so we need to make this usable programatically.

I did look at Information Objects for data classification and for wider user cases, I'm keen to avoid creating manual Information Objects and am waiting to have a data catalogue to master these, we would integrate with ServiceNow to tie Business Apps to Information Objects.

I think for now we'll add explicit attributes until we have the proper solution(s) in place, and then we can retire the attribute altogether.

Thanks!