Typically when one associates the law with analytics, the discussion focuses on how an organization uses analytics to assess the economic value of damages or claims.
Specifically, in the field of litigation analytics, the primary concern is the statistical analysis of legal issues such as torts, employment law, worker’s compensation, and insurance. Litigation analytics also covers stocks, bonds, derivatives, and mortgage-backed security valuations.
However, here I'm focusing on a broader topic -- how the law circumscribes the development and deployment of analytic work products.
Did you obtain the data inputs for your analytic work with or without the consent of survey respondents? Do the data inputs contain personally-identifiable information? Does your organization collect "competitive intelligence" to increase revenue or profits? Does your big-data include clickstreams from sources outside of the US? Does your contract allow you to sell your databases to other organizations? Do any local, state, or federal laws regulate your data collection or information-sharing activities?
While the legal dimensions of analytics should be your boss's concern and not your own, you should be aware that you cannot do your job without the approval of some legal/regulatory authority or agent. Whether it is a human subjects review board, a federal agency, or your company’s law department, every organization has a gatekeeper that ensures it conducts business activities in compliance with the governing laws.
To the extent that your work products could come under review for legal compliance (such as a system audit) or as part of a criminal investigation, here are some best-practices to follow:
- Document your data sources. Whether as part of a program header, system specifications document, or user manual, you should record all known information about the origin and characteristics of the data.
- Document any transformations made to the data. You should record all changes to the organization of the records, variables, or data values.
- Document the analysis plan. You should record how you were instructed or chose to analyze the data.
One way of simplifying your "audit readiness" is to use tools that capture metadata. This method requires a lot of upfront work in terms of deriving operational definitions and entering a lot of detailed information, but it will pay off if you ever need to produce the information for an audit.
In like manner, tools that graph the data processing and analysis plan can provide auditors easily interpreted visuals of the dataflows. You still may need to produce source code, but having the associated visual aids will reduce the probability of such a request.
In short, someone inside and perhaps also outside your organization has authorized your work as an analyst. To that extent, everything you do is subject to review, especially if your data inputs are sensitive or analytical tasks have far-reaching implications. You should approach your work in a manner that makes every data source and analytic task traceable and trustworthy: Even in analytics, you cannot escape the long arm of the law. Hence, you should be proactive and conduct your work in a manner that would stand up to an unexpected regulatory review.
Have you ever taken the time to examine your analytic work in a legal context? Will you now? Comment on the message board below.