Use Case: Regulatory Policy Implementation

You’re an organization in a highly regulated industry. You have to handle a complex and frequently-changing domain of regulatory requirements. These requirements impact many of your core business functions, such as:

• Determining which data can be provided to a requestor, and in what form

• Determining which credentials apply for authorizing actions in certain locations

  • for example: rules that vary from US state to US state about which type of medical certifications allow for data access

• Determining how to delegate access

• Determining how to make certain calculations given the locations of the parties involved

The Problem

You want to implement these rules in a consistent, clear, and verifiable way. You want to avoid re-work and mistakes. You don’t want the enforcement of these rules to become a single point of failure for your application. You also don’t want to ignore the rules, because that can carry legal repercussions. You want it to be fairly easy to audit the implementation of the rules. You don’t want

If you try to implement these rules directly in your applications & services, assuming you have more than one for which these rules apply, you end up with a significant amount of duplicated effort, which may not always be implemented exactly the same way across multiple teams. Developers who are not experts in rule-making may struggle to interpret complex regulatory policy correctly. Changes to those rules will require revisiting the applications, distracting from other tasks. It is difficult to test these rules in isolation. Often these regulatory rules carry penalties for violations.

The Old Way

The old way was to embed the policy rules directly into the applications and services. This often resulted in multiple implementations that were not always consistent, because the developers of the applications are not always comfortable with the often-complex world of regulation. Decisions were either made locally, and quickly, but not always correctly; or decisions were made centrally, which introduced scalability and reliability challenges. Changes to the rules often required updates to the applications, which became either labor overhead, or a distraction from implementing software to support the functional needs of the organization. Testing this in a robust way is difficult, because adherence to regulatory rules is not the prime purpose of these applications and services. Internal and external auditors want to see proof that the rules are implemented and being used correctly, which requires significant audit infrastructure, and often significant access to the developers to explain how data is processed and walkthroughs of how rules are enforced.

The Policy as Code Way

Use a Policy as Code engine to implement and enforce the rules. Change the applications so that they reach out to the PaC agents for answers, rather than implementing those decisions themselves. The agents can be co-located with the application servers, dramatically reducing response time and the chances of failure. New applications and services gain access to these rules immediately, with minimal integration effort.

If scaling is a concern, the open-source PaC agents scale easily, and have a robust model for deploying new rules quickly across the entire organization, ensuring consistency.

Writing the rules can be performed by dedicated regulatory experts, one time, in one place, which significantly reduces the chances that the rules are incorrectly implemented, or inconsistently applied between various applications and services.

Testing these rules becomes more straightforward, because the rules are separated from the applications, reducing the “indirectness” of testing the rules.

Auditing can be done centrally, using the centrally managed rules, and decision logs captured by the PaC agents.

Evaluation

• Does this make managing regulatory policy easier?

  • Yes! But it is not a silver bullet! Some regulatory policy will still be difficult to implement properly.

• Does this prevent changes to the applications/services in the event of a regulatory change?

  • Often yes, but sometimes no. If a regulatory rule requires access to new data, the applications will need to provide that data to the PaC agent (or the PaC agent will have to acquire it)

• Does this scale well?

  • Yes - the agents have a small footprint and can be deployed across the organization at minimal cost.

• Does this ensure that the policies are correct?

  • No, you still need someone to write the rules and determine that they are properly implementing the policies. But these people can be experts at policy (or become experts at policy) rather than addressing policy as a distraction to their normal work.

• Can you build infrastructure to verify that the policies are correct?

  • Yes - you can build testing solutions that exercise every edge case imaginable, and verify that the PaC system is returning the correct results in all scenarios. Combine this with the audit logs, and you’ll have very strong confidence that you are in compliance with your regulatory burden.

Results

You have more confidence that your applications and services are in compliance with your regulatory regime

You can demonstrate that compliance more easily to auditors

You can change the rules as required centrally, and all infrastructure will gain access immediately.

You can create a group of developers who are dedicated to understanding regulatory requirements and implementing rules appropriately.

Your policy team can make changes centrally, without any code impact to the downstream infrastructure (in most cases)