Skip to content

Leadership1 publisher2 min readPublished

A Manulife GRC executive argues control assessments describe an environment that has already changed

A governance, risk and compliance executive at Manulife argues that assessments taken at intervals cannot describe systems that change between them. The evidence he offers is his own experience with enterprise projects and one cited research paper.

The Board Room · Leadership desk

Illustration accompanying A Manulife GRC executive argues control assessments describe an environment that has already changed

What happened

  • Ramachander Rao Thallada, a governance, risk and compliance executive at the North American financial institution Manulife, set out a case for continuous governance in a Forbes Tech Council post.
  • He wrote that a control which worked well during its evaluation period may be operating in a completely different environment a few months later, as cloud services and connected applications keep advancing.
  • His example is an environment where applications exchange data across hundreds of flows, with added sources, changed permissions, altered transformations and shifting dependencies that each look insignificant and together move the risk position.
  • Continuous governance, as he defines it, means systems that keep producing evidence controls work, through monitoring, exception alerts, access control verification, data quality measures, log files and dashboards.
  • He cites Vasudevan Ananthakrishnan's 2026 research on governance frameworks for large-scale ETL ecosystems, which addresses visibility into lineage, transformation, quality, accessibility and dependencies across many pipelines.

Compiled by The Board RoomSomething wrong?How this is made

Why it matters

  • constraint A point-in-time assessment bounds what anyone can claim to the day it was taken. What the signature covers is assessment day. It says nothing about the environment as it stands when the signature is read.
  • exposure An audit finding dates the discovery of a bad setup. It does not date the start. On Thallada's account the defect has run for weeks or months by then, and the period belongs to whoever signed the last clean review.
  • decision The spending choice he poses is narrow. Monitor access permissions continuously and validate data where it is generated and transformed, or keep finding both classes of problem after a management report has gone out.
  • capability Tracking lineage, transformation, permissions and exceptions in real time would let a team answer an assurance question by querying the running environment. Thallada says this governance concept, not the ETL technology, is why the research matters to GRC teams.

Four reviews a year sit about 91 days apart, dividing 365 by four, and the quarterly audit is the place Thallada names as where improper access permissions get found [13][18]. A grant made in the second week of a quarter waits until the thirteenth for anyone to look. Continuous monitoring, in his framing, exists to shorten that wait enough that a person can still act on what it turns up [12].

Thallada sets limits on the claim himself. He wrote that continuous governance is not about daily audits and not about automating all GRC decisions, and that the goal is not to gather more data [11][12].

The record behind the argument is one practitioner's experience plus one cited paper. Thallada attributes his view to work on large-scale technology projects and complex enterprise settings [4], and the study he points to proposes combining centralized metadata management, pipeline monitoring, data quality management and access policies in one framework [15]. The piece does not quantify how often controls change or how many fail between assessments [19]. "In my experience, the problem usually doesn't arise from a lack of policies, but from maintaining visibility into whether those expectations continue to be met as the technical context changes," he wrote [8].

The engineering cost sits on the other side of the trade-off. Standing up monitoring, exception alerts, access control verification and data quality measures commits budget and engineering time and produces no new policy [11]. Thallada also puts a limit on how far the automation goes. "In pursuit of continuous governance, it's common to automate everything. In my opinion, however, this approach is wrong," he wrote, under the heading "Automation Should Support Accountability, Not Replace It", while allowing that automation works very well for repeated actions [17][20].

Nothing in the piece makes this a decision for this week. The cycle he describes is familiar: policies are set, control assessments are conducted after a specified period, documentation is kept and corrective actions close the gaps found. It has held for a long time, and an instrumented alternative is a multi-quarter engineering commitment [3]. The drift he worries about runs on a scale of months [6]. "Governance must be an ongoing process," he wrote [10].

What to watch

  • A measured drift rate: how many controls in a real pipeline estate fail between two consecutive assessments.
  • Whether an external auditor accepts continuously collected evidence in place of a period attestation.
  • Whether Ananthakrishnan's ETL governance framework gets tested on a live pipeline estate.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories