Automating Legislative Compliance

When delivering Data Analytics projects in Government, we often refer to policies or legislation which mandate that datasets can only be accessed or integrated under a strict set of circumstances.

These legislative constraints are sometimes backdated and to locate them in large datasets takes considerable patience and time and in turn, increases the turnaround time to deliver the intended outcomes.

The result can be that new initiatives requiring a data request, take countless hours of effort by Analysts to decipher these rules and translate them into terms suitable for data engineers/developers. And to interpret and ensure they have been considered in their solution designs.

This convoluted approach adds additional complications, and as the solution goes into production Governance teams must again ensure that the legislation has been followed. This monitoring may also have to be repeated every time an end user consumes data, and non-compliance can result in onerous consequences.

Collection of sensitive data also warrants an additional set of controls around masking and encryption, and also integration with Identity and Access management controls.

Could we reimagine and rethink how we manage these policies and legislation controls in a way that is easy to enact and adopt by the software that we build?

Could we develop a process to define and enact the legislation by making them machine readable?

I believe we can, and we describe this automation as Legislation-as-Code (LaC).

LaC will have the legislation defined in a descriptive way and compatible with the same DevOps tools that are commonly used for code versioning, automation etc.

Currently, I’m collaborating with my colleagues as part of the Thinkstream Analytics Think Tank team to conceive of ways that this could be developed into a capability that could reduce the administrative burden of embedding legislation in data products.

Initially, we believe the principles that should underpin such a solution would include but not limited to:

1. Rules based – Legislation or Policies governance controls can be unitised, enabling them to be programmable objects. These should be developed using a pseudo coding tool and not require a programmer

2. Deployed as stand-a-lone or integrated functions – System Applications such as SAP, Oracle, TechnologyOne can, for example, call the function before the data is deployed to a reporting tool

3. Flexible rules and policy controls – that can be changed simply and easily by a business (not IT) Governance team

4. Categorised recipients of data – ensuring that some recipient’s data access can be restricted based on an entitlement category.

I’d be interested to hear whether the difficulties of enabling legislation in IT solutions is a challenge you recognise.

Comment on the article on LinkedIn - Automating Legislative Compliance