Finding Unexpected Allies Pt 2: Regulatory Affairs


In the previous post, I talked about how you can often build support for a modeling initiative by looking outside the obvious stakeholders, i.e., executives, and engaging with a department that has to consider dependencies due to externally imposed requirements.

The specific case I started with was the risk management group of a financial organization, but this does lead us on to another case that has greater generality – regulatory affairs.

Every organization has to engage in some level of regulatory compliance – health and safety, human resources and so on… but many face specific, detailed regulatory regimes. Just a few examples are banking, as previously discussed, pharmaceuticals, telecommunications... and faced with such detailed regulatory regimes, it’s common for companies in these industries to have a specific regulatory affairs unit – and this unit is in a position to benefit from Enterprise Architecture modeling, making them a potential ally.

So – what’s the value proposition that the EA team can offer to this group? In the cases that I’ve seen, there are two specific ways that Enterprise Architecture modeling can help with regulatory compliance.

First of all, the Enterprise Architecture group can map the demands of particular pieces of regulation to the business processes that they affect. The approach that I’ve seen is generally to identify and break out the regulations into specific requirements which you can then map directly to business processes. The regulations can also be mapped back to the specific regulations or laws that gave rise to them.

This provides several benefits. First of all, it becomes possible to gain a clearer understanding of what parts of the organization are affected by each individual piece of the regulatory regime. At the same time, the fact of having engaged in this effort offers a starting point when the organization is audited for compliance.

Depending on the nature and stringency of regulation, it may also be worthwhile to map regulations directly to applications that they affect – with exactly the same benefits.

The second way that Enterprise Architecture modeling can assist with regulatory affairs is by assisting with the actual efforts to comply with requirements – in particular, requirements around data. Some industries have had specific regulations around the treatment of data for many years – a classic example is HIPAA, with its requirements around the treatment of personal health information (PHI).

If the organization is able to map specific business processes to the data that they access, it becomes possible to identify processes that need extra controls. From there it becomes possible to map business processes to the business actors that are involved in these processes…and this helps the question of regulatory compliance in two ways that speak to the interests of the EA department and the regulatory affairs department respectively.

Performing this mapping makes it easier to implement controls in the business processes (and the applications that support them) to ensure the regulatory compliance; but at the same time, it helps the regulatory affairs department to demonstrate that appropriate efforts are being made to ensure compliance, in a way that is easily digestible for an auditor.

So in industries where a regulatory affairs group commonly exists, such a group has an alignment of interests with the EA department – and can serve as a valuable ally.