Regulation, Compliance, and Delivery

“Regulatory compliance” and “agile” are words that may not seem to belong together. Nonetheless, agile delivery is a reality, business drivers rule, and to production we must go. You must know your risks and understand the impacts to the business. When regulatory agencies issue warnings to companies not in compliance, those companies’ stock prices can take a major hit.

The Latin phrase “non scriptum non est” means “If it is not written, it does not exist” and is appropriate for regulatory compliance, where documentation is of the utmost importance. However, it is worse to have your processes documented and not followed than to have no documented processes at all. Whatever processes are in place must be documented, verifiable, and auditable. Should an audit occur, anything related to that regulated process and environment can come into scope and be used to prove a company is following documented policies and procedures.

Compliance Strategy and Leadership
My first experience in dealing with software that handled regulated data was with Title 21 CFR Part 11 of the Code of Federal Regulations, Food and Drug Administration (FDA) guidelines on electronic records and electronic signatures. More recently, I was responsible for compliance with Sarbanes-Oxley and the Office of Foreign Assets Control for specially designated nationals.

For the FDA projects I worked on, the compliance leader made T-shirts to get the word out. The front read, “Comply or die,” and the back, “... but we are here to help.” Both messages on the shirt were sincere. In most cases where regulations apply, one must prove that a documented process has been followed—that auditable records and reports validating the processes and related document artifacts are in place, secured, maintained, and adhered to. Most regulatory agencies will only state what is under compliance, never how to be in the compliant state.

When dealing with highly regulated environments like the FDA, expect additional layers of QA or compliance management within companies. I separated them into “Big Q” and “Little Q.” The Big Q compliance teams at this company dealt with interpretation and opinions as to what processes needed to be in place to satisfy regulations. I was Little Q for this company. There was “Q envy,” as Big Q also oversaw the how aspect from Little Q, which owned the delivery and maintenance of the compliant state. Getting to the validated compliant state was no easy task, and maintaining it was even harder and costlier.

Risk to the business can be extreme, and the need for levels of compliance knowledge and leadership is serious. Part of the strategy is to deal with the regulatory representatives within your organization as accountable stakeholders who are totally engaged in the ongoing system delivery lifecycle.

The Awakening
I was totally unprepared to learn that any piece of software and hardware that deals with regulated data falls under regulatory compliance. This meant that the tools we used in the delivery of the software and handling of regulated data, like defect tracking, requirements, source or version control, test case repository, and management systems, now had to be in the compliant state. We needed quickly to learn new terms, such as installation qualification (IQ), operational qualification (OQ), and performance qualification (PQ). IQ, OQ, and PQ would need several articles to discuss, but it is important to call out the need for experienced compliance leaders in traversing the regulated landscape. These qualification steps needed to be in place, documented, and validated for the ancillary software and hardware prior to any production deployments for regulated data or processes. This included requirements management, source or version control, test case management, and defect management software. Standard operating procedures (SOPs) for all tools and processes in support of the regulated data were a priority, as was the training needed for all associates involved with regulated data.