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

RichieP · ‎05-07-2024

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!

mcastoe · ‎05-14-2024

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

View solution in original post

Angela C · ‎01-21-2025

We use Information Portfolio/Information Objects to track our regulatory requirements. It allows for ownerships for approval processes.