How to Manage Conflict of Interest in Grant Assessments: A Guide for Public Sector Funders

Conflict of interest management is the area of grants administration where the gap between policy and practice is most consistently wide — and where the consequences of that gap are most serious. Virtually every government agency and Crown entity that runs a funding programme has a conflict of interest policy. A much smaller number have a conflict of interest process. The distinction matters more than most grants managers realise.

The difference between having a COI policy and having a COI process

A conflict of interest policy sets out what your organisation considers a conflict, what assessors and panel members are required to declare, and what the consequences of non-disclosure are. It is a governance document. It tells people what to do.

A conflict of interest process is the operational system that ensures those declarations are made, captured, and enforced consistently for every application in every round. It is the mechanism that turns the policy into action.

The distinction matters because audit exposure rarely comes from an assessor failing to know they needed to declare a conflict. It comes from a declaration being made correctly and then nothing changing — the assessor continuing to score the application, attending the panel discussion, or accessing the application file after the declaration. That is an enforcement failure, not a policy failure.

When the Office of the Auditor-General examines conflicts of interest in public sector procurement and grant-making, the question it asks is not "did you have a policy?" It asks whether conflicts were identified, declared, and managed so that the outcome of the decision was not affected by the conflict. That is a process standard, not a document standard.

What a COI declaration actually needs to capture

The declaration itself is often the weakest link. Generic COI declaration forms that ask assessors to confirm they have "no conflicts" are functionally useless. They create a paper trail, but they do not generate the information needed to manage the conflict.

A declaration that is fit for purpose needs to capture:

The nature of the relationship. There is a material difference between an assessor who is a former employer of the applicant organisation, an assessor who has co-published with the lead researcher, and an assessor who holds a board position at the applying organisation. These require different management responses. A checkbox that says "I have a conflict" does not capture the distinction.

The direction of the conflict. Some conflicts create a bias toward the applicant (personal financial interest, close professional relationship). Others create a bias against (competitive relationship, personal dispute). Both require management, but the character of the risk is different.

The assessor's own assessment of the conflict. Asking the assessor to rate the seriousness of the conflict — while not determinative — gives the convenor useful information about how the assessor understands their own position.

The date and stage of declaration. A conflict declared before scoring begins is manageable. A conflict declared after scores have been submitted, or not declared at all, is a process failure that may require the application to be reconsidered.

The enforcement gap: what happens after the declaration

The enforcement gap is where most public sector grants programmes are most exposed. Once an assessor declares a conflict, what actually happens?

In many programmes, the answer is: the convenor is notified, the declaration is filed, and the assessor is asked to step aside from that application. In practice, this means the assessor is trusted to self-enforce the restriction. They are told not to score a particular application and expected to remember that instruction across a panel session that may involve 30 or 50 applications.

That is not enforcement. It is an instruction.

Enforcement means the assessor cannot access the application file once the conflict is declared. It means their scoring interface does not present that application for review. It means they cannot see the scoring of other assessors on that application. And it means every one of those restrictions is logged with a timestamp, associated with the specific assessor and application, and available for audit.

Without system-level enforcement, you are relying on human memory and professional conscientiousness under conditions — multi-day panel reviews, large volumes of applications, pressure to reach consensus — that are not well suited to consistent self-regulation.

What system-level COI enforcement looks like

In a purpose-built grants management system, COI enforcement is architectural. When an assessor declares a conflict against a specific application, the system immediately revokes their access to that application record. They cannot open it, cannot score it, and cannot see other assessors' scores for it. That restriction is recorded in the audit log with the timestamp of the declaration and the identity of the assessor who made it.

In Tahua, this is the default behaviour. When an assessor declares a conflict, the system automatically blocks their access to that application and logs the restriction against both the assessor record and the application record. The panel convenor can see the declaration and the restriction in their programme dashboard. The audit trail is created automatically — there is nothing additional to document.

For a programme like Te Māngai Pāho, which administers more than $60 million in annual funding across multiple rounds and hundreds of applications, this kind of architectural enforcement is not a convenience feature. It is a programme integrity requirement. Te Māngai Pāho has more than doubled both its number of funding rounds and the number of contracts under management in recent years with the same team size — that scale of growth is only achievable if the compliance architecture scales automatically, rather than requiring additional manual oversight.

The system-level approach also closes a specific risk that most convenors do not plan for: the mid-panel declaration. If an assessor is part of the way through a panel and then identifies a conflict with an application they have already partially reviewed, the question of how to handle that requires both procedural clarity and system support. Can they be excluded from the final ranking discussion for that application while remaining in the panel for others? Can you isolate the influence of their partial review? System-level enforcement makes the management of that scenario auditable.

The panel convenor's obligations: beyond the initial declaration

Panel convenors often understand their COI obligations in terms of the declaration stage: circulate the COI forms, collect the declarations, note any conflicts, and ensure affected assessors are removed from those applications. That understanding is accurate but incomplete.

The convenor's obligation extends through the panel process. Specifically:

Discussion management. Even where an assessor has declared a conflict and been excluded from scoring an application, if they are present in a panel discussion where that application is being deliberated, there is a risk. Assessors with declared conflicts should be excluded from the panel room or call during deliberations about applications with which they have a conflict. This is harder to manage in practice than it sounds, particularly in virtual panels.

Record of the management decision. The decision about how a declared conflict was managed — whether the assessor was excluded from scoring only, or from discussion as well, and the reasoning behind that decision — should be documented. If the same convenor uses a different approach to managing a similar conflict in a subsequent round, that inconsistency is itself a risk if the matter is ever reviewed.

Post-panel review. Before scores are finalised, the convenor should confirm that no assessor with a declared conflict has scores recorded for the affected application. In a system with architectural enforcement, this is automatic. In a spreadsheet-based process, it requires a manual audit step that is easy to skip under end-of-panel time pressure.

Escalation. Some conflicts are serious enough that the assessor should not remain on the panel at all, or that a senior decision-maker should be notified. The convenor's COI process should include clear escalation criteria — not just "when in doubt, declare" guidance for assessors, but criteria for when the convenor escalates to the programme manager, legal, or the chief executive.

How to test whether your current process would survive an OIA request

The practical test for COI process adequacy is to ask what would happen if your assessor records and panel documentation were requested under the Official Information Act. What would the file show?

A process that would satisfy OIA scrutiny needs to produce, for every assessment round:

  • A declaration log that shows every assessor was asked to declare, and records either their declaration of no conflict or the details of any conflict declared, with timestamps
  • Evidence that declared conflicts resulted in the assessor being excluded from the affected applications — not just a policy statement that they should have been, but a log showing they were
  • Panel discussion records that show how any conflict was managed at the deliberation stage
  • A record of any management decisions made in response to declared conflicts, including the reasoning

If your current process produces some of these but not all, the gaps are your audit exposure.

The OAG's best-practice guidance on managing conflicts of interest in public sector procurement makes clear that documentation of how conflicts are managed is as important as documentation that they were declared. The fact that an assessor declared a conflict is not, by itself, sufficient evidence that the conflict was managed appropriately. The management action and its outcome need to be on record.

For government agencies that operate under parliamentary reporting obligations — as NZ On Air does, for example — that documentation burden is not abstract. It is a real requirement with real consequences.


If you are designing or redesigning a grants programme that needs to meet government-grade COI requirements, the government grants management page covers how Tahua's architecture supports that standard. For a direct look at how it handles your specific programme context, book a demo.