Building the governance team¶

When Jules Keeper joined Coco Pharmaceuticals as the CDO, he soon realized that the execution of their business strategy to move to personalized medicine was being held back by their operational practices. Some of this was related to their use and management of data (his responsibility to fix of course), but there were broader issues relating to security, IT infrastructure management, software development and their corporate governance. He realizes that he can not do this alone and calls his colleagues together to discuss how they proceed.

They agree to divide the work amongst themselves, using the traditional governance domains to divide out the responsibilities, but maintaining the governance information using open metadata (Egeria) to be able to coordinate their work across the governance domains.

The result is as follows:

• Jules Keeper becomes the CDO and head of the DATA governance domain.
• Ivor Padlock becomes the CISO and head of the SECURITY governance domain.
• Faith Broker becomes the CPO and head of the PRIVACY governance domain.
• Reggie Mint as the CFO becomes head of the CORPORATE governance domain.
• Gary Geeke as the infrastructure lead becomes head of the IT INFRASTRUCTURE governance domain.
• Polly Tasker as the most senior software manager becomes had of the SOFTWARE DEVELOPMENT governance domain.

They also add more specialist governance leaders to the team.

• Erin Overview is to lead the DATA SHARING governance domain.
• Tessa Tube is to lead the DRUG DEVELOPMENT governance domain.
• Tom Tally is to lead the SUSTAINABILITY governance domain.

Defining the governance drivers¶

Their first challenge is to document the governance drivers. These are the business imperatives, regulations and threats that the governance team needs to focus on.

They begin with the business imperatives. They try to capture the key concerns of their board and come up with:.

• Personalized medicine - the company wants to provide personalized medicine to its customers. Initial projects in this space have provide promising. This is a key focus of the board, and requires an extensive business transformation. It is where the governance activity can add a lot of value.
• Cyber Resilience - the board recognizes that cyber-security is critical to avoid both loss of intellectual property and the ongoing operations of the business.
• Sustainability - sustainability is recognized by the board as a way to provide focus on the future viability of the business.

Next they think about the threats to the business, including:

• Cyber-attacks
• Loss of competitiveness
• Insufficient talent
• Disruption in the supply chain

They next list the regulations that govern the business. These are divided into:

• regulations that any business must adhere to, such as financial reporting.
• regulations that govern the drug development process, such as the way clinical trials are conducted.
• regulations that govern the manufacturing of pharmaceuticals
• regulations that govern the distribution of pharmaceuticals

They create definitions for each of these drivers to capture the essential information needed to understand the governance requirements they represent and load them into Egeria using the Dr Egeria Markdown processor.

The governance leadership team defining governance drivers

With the drivers in place, they agree to go back to their teams to define the responses to each of these governance drivers.

The risk register¶

Before they disperse, the leaders meet a second time to build the risk register. The idea comes from the cybersecurity team, where the practice is well established, but Jules asks for it to be built jointly - the threats they have just listed do not respect the domain boundaries they have just drawn, and a register owned by one team would only ever describe one team's view.

The distinction they settle on is between a threat and a risk. A threat is a governance driver: a description of something that could go wrong. A risk is the concrete, assessable consequence that a threat gives rise to in this company, rated for likelihood and impact - and therefore for importance - and linked back to the threat it realises. "Cyber-attack" is a threat. "Ransomware could encrypt manufacturing control systems and halt production of on-demand personalised treatments" is a risk, and it is the second of those that can be argued about, mitigated and measured.

Each leader brings the risks arising in their own domain, and the group rates them together. Twelve risks come out of the session, in six categories:

Each risk records its likelihood, its impact and the implications that follow - what would have to be true for the company to be able to say it had responded. The ransomware risk, for example, carries the requirement that manufacturing systems be segmented from the corporate network, that offline and tested backups exist for everything critical to production, and that the incident response plan cover manufacturing downtime specifically. Those implications are what the domain programs are later written against.

The exercise of linking every risk back to a threat exposes a gap that nobody had noticed. Three of the twelve arise from regulatory obligations - FDA clinical trial regulations, Good Manufacturing Practice, and Martyn's Law - that the leaders had captured as regulations but never as threats. The risks were real, and each had an owner, but there was no driver in the model for them to answer to. The team defines the missing threats so that every risk links to one.

This turns out to be the first practical demonstration of the point Jules had been making about keeping the definitions in open metadata rather than in separate documents. Nobody discovered the gap by reading the register; it appeared because the links would not resolve.

Building out the governance domains¶

Then each leader takes their domain back to their own team. The domains develop in parallel, and what comes back is more than anyone had expected.

Four of these domains did not exist when the leaders divided the work. Human Resource Management, Health and Safety, Distribution and Diversity, Equity and Inclusion each had to be registered as a governance domain before any definition could claim it - and the fact that they were missing from the original list is itself a finding. The traditional domains describe how a company governs its information; they do not describe how a pharmaceutical company governs the things that can hurt somebody.

What the domain programs revealed¶

Read together, the programs give the leadership team its first comprehensive view of what Coco Pharmaceuticals is actually obliged to do. Several things become clear that no single domain could have seen.

The domains are layered, and the layer decides who should own a definition.

Some domains face two ways at once. Human resource management answers outward to employment law, and inward supplies data other domains depend on absolutely: manufacturing cannot certify a batch without evidence the operator was qualified, drug development cannot show good clinical practice compliance without site training records, and security cannot revoke access to someone it has not been told has left. Until the programs were written side by side, those were three assumptions rather than three obligations.

Obligations from different domains can genuinely conflict. The health and safety program makes the sharpest case. Every other control in the plant protects the product from the people; these protect the people from the product. Coco Pharmaceuticals handles compounds that are pharmacologically active at very small doses, and the containment needed to protect an operator can work directly against the conditions needed to protect a sterile product - airflow that pulls contamination away from an operator pushes it toward the product. Such conflicts are resolved by engineering judgement, but they have to be recognised first, and a change assessed only for its manufacturing consequences will pass while creating an exposure risk nobody evaluated.

The group structure reaches into everything. A trial site sits in the UK or the EU, the sponsor entity determines who the data controller is, and the data consolidates into a US-held clinical database - so a clinical trial engages obligations owned by the privacy domain. A pack destined for Belfast and one destined for Dublin leave the same production line and are governed by different serialisation regimes. The same corporate shape appears in the financial, privacy, employment and serialisation programs, described four times by four teams who had never compared notes.

Definitions in one domain depend on definitions in another. Transport classification is drawn from the substance register that health and safety maintains and the agent classification in the biological agents file. The corporate program links to the raw material obligation in manufacturing. The personalised medicine programme turns out to be contained use of genetically modified organisms in the legal sense - manufacturing governs the patient identity attached to that material, and nothing had governed the fact that it is a GMO at all.

The dependencies are numerous enough that the loading order of the definitions has to follow the story: a definition can only link to one that already exists.

Why data governance matters to all of it¶

The shape of Jules' own program is the clearest evidence of what the exercise proved. The Data domain owns only three governance drivers - the small number of problems that originate in how the organisation manages data itself, that no single domain can fix from inside its own boundary, and that surface as damage in several domains at once. Everything else in the data governance program responds to drivers owned elsewhere.

That makes it short on drivers and long on links, and deliberately so: most of what the data domain does exists to let another domain meet an obligation that is theirs. A data policy that answers no driver and serves no domain is governance without a customer.

It also explains why the leaders' insistence on maintaining their definitions in open metadata rather than in separate documents turns out to matter more than it seemed at the time. Each team wrote its own program, but the value is in the links between them - and links can only be followed if the definitions live in the same place. The set of obligations they have now described is the material that the key information supply chains are later drawn against, and reading those links backwards becomes a governance check in itself: an obligation with no data flow attached is either operating on data that does not move, or is an obligation nobody has yet worked out how to observe.

See:

• Creating the Data Governance Program
• Creating the Security Governance Program
• Creating the Sustainability Governance Program

Raise an issue or comment below