The phrase regulatory affairs teams reach for most often, “regulatory compliance review,” covers at least three different jobs. Deciding whether the product can enter the market, obtaining the testing and certification, and verifying that confirmed regulatory items actually landed in the documents.
The first two have reasonably clear owners. The confusion starts at the third. Once the subject becomes regulation as it appears inside technical documentation, who judges what stops being obvious.
This article sets out where the lines fall between regulatory counsel, certification bodies, and the technical documentation team.
Three Questions Hiding in One Phrase
The regulatory questions a manufacturer needs answered break into three. They call for different expertise, they happen at different points, and the nature of the responsibility differs in each case.
| The question | What it involves | Who can answer it |
|---|---|---|
| Can this product enter this market? | Statutory interpretation, pre-market pathways, approval conditions | Outside counsel, regulatory consultants |
| Has this product passed testing and certification? | Testing, type approval, entitlement to apply a mark | Test labs and certification bodies |
| Did the confirmed regulatory items land correctly in the documents? | Deciding how each item is applied, then verifying it | Technical documentation team (in-house or partner) |
“Regulatory compliance review” usually bundles all three together. The confusion that surfaces from time to time is expecting the owner of the third to answer the first two. As it becomes better known that manuals carry regulatory content, the team producing those documents starts to look like a team that can rule on the regulation itself.
First, to be clear
This article is about dividing the roles. It is not about which role matters more. If any one of the three questions has no owner, the other two can run perfectly and the launch still stops.
Why Regulatory Counsel Alone Does Not Finish the Document
Many manufacturers retain outside counsel or a regulatory consultancy market by market to confirm what applies. That work is necessary and nothing else substitutes for it. Three limits appear when that structure is asked to cover the documents as well.
What regulatory counsel actually covers
The role of regulatory counsel is to run the pathway to market authorization in a given jurisdiction. Which regulation applies, which testing and certification are required, which filings go where and when. Which page of the manual carries what, in what words, sits outside that scope.
A blender makes the point. The order for dealing with a hazard starts with design. You add an interlock so the lid cannot come off while the blade is turning. Where that is not achievable, the judgment becomes that the residual risk has to be communicated in the document.
Counsel takes you that far. It does not tell you how to build the interlock, or which page of the instructions for use should carry which sentence. That was never the engagement, and counsel is not positioned to direct it.
So the decision about where the residual risk goes, in what wording, and at what length, falls to whoever builds the document. Leave that decision empty and you reach a state where the regulation is settled and the document is not finished.
Why market-by-market engagements do not accumulate
Counsel advising on a launch in country A and counsel advising on a launch in country B answer within different frames. One cites the statute. The other explains local practice. Unless those answers get organized into a common format, they never become a regulatory item register and stay scattered across individual emails.
The management load then grows in a straight line with every market added, even where plenty of items could have been grouped.
Why the cost structure fights repeat verification
Documents get revised. Models are added, specifications shift, language versions multiply. Where every one of those triggers a billable question, the people doing the work gradually stop asking. What accumulates is a series of decisions to leave an uncertain item exactly as the previous version had it.
Who Decides How a Confirmed Requirement Goes Into the Document?
The name of a regulatory item and its legal basis usually come down from above. What that item looks like inside the document does not come with them. Whoever passes it along has no picture of what the current document contains or how it is organized, so they cannot direct it at that level.
A decision is therefore required. Two examples.
First, a requirement arrives to carry region-specific certification documents. Someone has to decide whether to pull only the regulatory entries out of the certificate, turn them into a table, and place it behind the front cover, or to build a separate Declaration of Conformity page ahead of the back cover and reproduce the certificate in full. Both satisfy the requirement. They differ in what the document becomes, how long it runs, and what revision costs later.
Second, a requirement arrives to describe the intended user. Someone has to decide whether that sits ahead of the safety information or inside the product overview, whether it reads as prose or as a list of conditions, and whether qualifications and completed training get named.
Regulatory knowledge alone does not produce these decisions. Four things have to be weighed alongside it.
- Does it follow on naturally from the text before and after?
- Does it leave the reader learning sequence intact?
- Does it fit the logical structure of the document as a whole?
- Does it keep the blast radius reasonable when a revision comes?
Inserting a regulatory item and designing a document meet at this point. Leave the decision to whichever individual happens to be doing the work and the same item lands in a different place, in a different form, at a different length in every document.
Once decided, it goes into the regulatory item register. Whoever picks up the work next reads the direction there and applies it. The result stays consistent, and at revision time it is clear what has to be looked at again.
The work nobody assigns
What comes over from the regulatory side is the name of the item and its basis. That is also what the documentation team receives. Where it goes and in what form comes from neither side. The same holds when the work is outsourced. The request specifies language count, deadlines, and deliverable formats, and it does not specify this decision. The absence of an instruction does not make the work disappear. Somebody ends up doing it, and if that somebody is different every time, so is the result.
What a Technical Documentation Team Cannot Do
The other direction needs stating just as plainly. A team that builds documents cannot make legal determinations, and should not.
Which warning wording is the statutory wording, what label the product has to carry and what it must contain and where it goes, whether this product is entitled to apply a particular mark: these are regulatory and certification judgments. When a documentation team substitutes its own view, unsupported confidence goes into the document as though it were settled.
So the boundary has to be named from the start.
| Can do | Cannot do |
|---|---|
| Verify that confirmed regulatory items landed in the document | Determine as a legal matter what the regulatory items are |
| Decide and record where and in what form each item is applied | Give final approval on statutory wording and figures |
| Structure and maintain the items by market and product | Rule on certification status or entitlement to a mark |
| Confirm that translation carried the regulatory wording accurately | Act as agent in pre-market approval procedures |
| Mark items that cannot be judged and send them back | Make the call on items that require legal judgment |
How to Divide Regulatory Compliance Review
Arranging the three parties as sequential gates lets each of them work where they are strongest.
| Stage | Owner | Output |
|---|---|---|
| 1. Confirm the items | Outside counsel, regulatory consultants | Applicable regulatory items and their basis, by market. Settled here, the same question stops coming back. |
| 2. Obtain certification | Test labs, certification bodies | Test results, certificates, entitlement to marks. This is the source for whatever certification data the document carries. |
| 3. Decide how items are applied | Technical documentation team | The regulatory item register. Which deliverable, which position, which format, recorded. |
| 4. Apply and verify | Technical documentation team | The applied document and a determination per item. Anything that cannot be judged is marked and sent back. |
Counsel does not lose ground in this structure. It gets concentrated where it performs best. Instead of being pulled into piecemeal coordination across the whole process, it goes into confirming the items, and repeat verification is handled inside the documentation process.
When stage four turns up something that cannot be judged, stage one was usually incomplete. Statutory wording for a given language did not come with the item, or the applicability condition arrived sitting on a boundary. If the documentation team fills the gap with its own judgment at that moment, unsupported confidence goes into the document and nothing records that it happened.
What Changes When the Roles Are Split
- The nature of advisory spend changes. The cost that used to fire on every revision moves to firing only when a regulation actually changes.
- Market owners get out of regulatory coordination. Brand and business managers stop brokering between counsel and document production. That was never their job.
- Regulatory items accumulate as an asset. Adding the next market no longer starts from zero. Common items carry over and only the differences need checking.
- Accountability gets a clear edge. When something goes wrong you can trace which stage dropped what. This is as much about prevention as it is about response.
When you use the phrase “regulatory compliance review,” write down alongside it what is inside the scope and what is outside. This holds whether you are dividing work internally or putting it out to a partner.
Making the scope explicit does not constrain a partner. It tells you what you are covered for and what you still have to secure elsewhere.
Related reading Who Owns the Regulatory Content in Your Product Manuals? works through what a regulatory management system has to contain, in six elements. If the regulatory item register does not exist yet, start there.