Building a quality management system when the regulatory framework is still being written is a different problem than building one for a mature, well-understood environment. The instinct is to wait until the rules are settled. This instinct is wrong, and following it is how organizations end up scrambling under deadline pressure with a compliance architecture that was assembled rather than designed.
The Problem with Waiting
Regulatory frameworks don't arrive complete. They arrive in pieces, often over multi-year timelines, with enforcement postures that shift as the regulator gains experience. A sector that is regulated in principle may operate under ambiguous guidance for years before the rules are clear enough that most operators feel confident acting on them.
Organizations that wait for clarity before building their QMS are solving the wrong problem. The problem isn't "what does the regulation require?" The problem is "what does a well-run operation in this sector need, and how do we document that in a way that survives regulatory evolution?"
ISO 9001 as Architecture, Not Certification
The most useful framework for QMS development in emerging regulatory environments is ISO 9001:2015, not because of the certification, but because of the governance architecture it provides.
ISO 9001's process approach gives you a structure that is regulatory-neutral. The standard doesn't tell you what procedures to write; it tells you what your documentation system needs to be able to do. When you build a QMS on ISO 9001 architecture, you're building something that can absorb new regulatory requirements as an overlay rather than a rebuild.
This is what I did for BC pharmacy regulation. The Health Professions and Occupations Act came with three sequential regulatory deadlines across a 24-month window. Waiting until all three were in effect would have compressed a 97-document development project into an impossible timeline. Instead, we built the ISO 9001 architecture first (governance, document control, incident reporting, records management) and then mapped each specific regulatory requirement to the appropriate procedure as the bylaws were finalized.
The result is a QMS that addressed all three deadlines without requiring structural changes between each phase. New requirements arrived into an existing system rather than triggering a new build.
Document Architecture Principles
A QMS built for regulatory durability follows a few principles that differ from one built purely for compliance.
Anchor to mechanism, not outcome. Procedures should describe what is being done and why, not just the required outcome. "Submit the report" is an outcome. "Initiate the CIRCL report within 24 hours of the triggering event, assign to the designated reporter, obtain supervisor sign-off before submission" is a mechanism. Mechanisms survive when the required outcomes change.
Match document hierarchy to decision authority. The governance document defines policy. The procedure defines process. The work instruction defines execution. Each level should contain only what belongs at that level. When a policy contains execution detail, it becomes impossible to update execution without triggering a policy review. When a procedure contains policy rationale, the procedure becomes a political document rather than an operational one.
Build for real operators, not ideal operators. A QMS that works only when everyone is well-trained and highly motivated is not a QMS. It is a best-case scenario. Checklists, decision trees, and exception handling aren't signs of distrust in the workforce. They're the mechanisms that make the system reliable across the full range of the people who will actually use it.
The Standards Development Parallel
I've seen this dynamic from the other side as well. As chair of ULC TG-44002 and vice convener of ISO IWA 37-1, I was on the side of the table that writes the frameworks that QMS architects have to absorb.
The lesson from that work: the organizations that adapted fastest to ISO IWA 37-1 were those that had already built their quality systems on ISO infrastructure. The framework arrived as a set of additional requirements layered onto governance they already had. For organizations that had built compliance-only documentation, the IWA arrived as a mandate to rebuild.
Timing
The right time to build a QMS for an emerging regulatory framework is before the regulation is finalized, not after. The build should anticipate the structure of the regulation: what sectors it will cover, what failure modes it is trying to prevent, what the enforcement posture of the regulator is likely to be. Then create a documentation architecture that can absorb the specific requirements when they arrive.
This requires a different kind of work than compliance documentation. It requires strategic judgment about where the regulation is going. It requires understanding regulators as stakeholders with specific concerns, not just as sources of requirements. And it requires building a system that is designed to evolve, because in emerging regulatory environments, evolution is the only certainty.