In the previous Building a Research Security Program blog, we looked at how Digital Science and Kharon used a real, public settlement between the University of Delaware and the U.S. Attorney’s Office to show what a data-driven research security review can catch. That case, discussed during the April 28, 2026 webinar “Building a Research Security Program,” made a clear point: a lot of the information needed to catch a disclosure failure already exists in research data, if you know where to look and how to connect it.

But catching one case is not the same as running a program. The rest of the webinar, featuring Aaron Melville of Carnegie Mellon University and Catrina VanAllen of Huron, focused on exactly that: how an institution organizes its risk review, pairs data with expertise, and keeps the people affected by these decisions part of the process.

A simple framework helps a team know where to look

Aaron Melville, Assistant Vice President for Research Security at Carnegie Mellon University, was candid about how the field feels day to day: “There’s so much going on in the research security landscape right now. It is hard to stay afloat sometimes, and you sometimes will feel like you’re drowning.” His answer is a framework he calls his “P risk areas”: People, Property, Programs, Paper, Purposes, Places, and Payments.

  • People and Property: who is on campus or partnering with you, and what intellectual property or physical assets are at risk.
  • Programs and Paper: what your institution is known for, and which publications contain sensitive, export-controlled know-how.
  • Purposes and Places: who funds the work and its end use, and where partners and collaborators are physically located.
  • Payments: payment processors and where funding originates. Melville said this was the area that surprised him most.

Melville’s point is that once an institution understands where its risk exposure actually sits, it can start working on mitigation, and eventually on measuring whether that mitigation is working.

A tool works only if there is a team and a process behind it

Catrina VanAllen, Director at Huron, made the case that data has to be paired with processes. Huron’s research security team has worked in this space since before 2018, tracking regulatory change as it happens and partnering directly with institutions to help identify risk and implement the right programs and policies. VanAllen also described a workflow worth borrowing: when a funder flags a risk, an institution with good data behind it can push back with specifics rather than simply accepting the flag. In one case she described, the institution was able to write back and articulate exactly why a flag existed and why it was no longer an issue, and the flag was resolved.

She also pointed to the Department of War’s risk matrix, which requires a mitigation plan if a researcher has engaged with or co-authored with certain entities within the past five years. Her framing is a good one to adopt: once you know what a requirement will look like, you can gather that data proactively and be forward-looking, rather than reactive.

The researcher stays part of the conversation

Melville described a practical, human step in the review process. When a researcher raises a potential collaboration, his team can pull up that researcher’s Dimensions report next to a Kharon report side by side, show exactly which organizations the entity in question is connected to, and explain the risk. In many cases, the decision about whether that risk is acceptable is left with the researcher, since research security officers often have an advisory role rather than the authority to unilaterally block a partnership. Melville noted that visualizing the connections side by side makes that conversation easier, because it is grounded in shared facts rather than a flat “no.”

Data can also tell a good news story

Heidi Becker of Digital Science, who had opened the session with the University of Delaware case discussed in Part 1, closed on an optimistic note. Referencing a recent report – “Are Research Security Policies in the US working?” – Appendix A names 45 key labs of concern, she explains how an institution can build a tracked group around those organizations in Dimensions and watch collaboration trends over time. In the example she reviewed, the trend was moving in the right direction. Her point: research security data is not only useful for catching problems. It can also show leadership and external stakeholders that mitigation efforts are working.

What this looks like in the Dimensions Research Security product

Everything demonstrated across the webinar maps directly onto how Dimensions Research Security is built. According to Digital Science, the product is designed to turn fragmented research security checks into a consistent, audit-ready workflow for identifying, reviewing, and documenting potential risk across researchers, collaborations, and organizations. For academic institutions, that includes verifying researcher disclosures using enriched profiles that cross-reference global affiliation, funding, publication, patent, grant, and clinical trial data, and identifying concerning affiliations, partnerships, and funding links using configurable review criteria.

The workflow features that support the practices shown in the webinar include:

  • Repeatable review configurations, so a search like Becker’s “engineering researchers with NASA funding and a China-based affiliation” can be saved and reused across departments or institutions.
  • A managed review queue, so flagged researchers move through a defined process from initial identification to completion, rather than sitting in a static report.
  • Date-stamped notes and tags, so a team can document its reasoning as it works, similar to how VanAllen described writing back to a funder with specific context.
  • Audit-ready reports, which include the review configuration, notes, and tags applied, giving stakeholders the full context behind a decision.
  • The Dimensions Research Security API, which supports high-volume, repeatable reviews and can be embedded directly into an institution’s existing compliance, HR, or grants management systems, with review indicators for dual affiliations, restricted entities, and foreign talent programme ties.

The bottom line

Across the session, Digital Science, Kharon, Huron, and Carnegie Mellon made a consistent case: research security works best when it combines the right data, the right depth of relationship intelligence, the right expertise and process, and a clear internal framework for where to look. The University of Delaware settlement, covered in Part 1, showed what happens when disclosure relies only on what a researcher chooses to share. The practices covered here, from Melville’s “P risk areas” to VanAllen’s process guidance to keeping researchers part of the conversation, show what a robust program looks like once an institution moves past a single-point-in-time check. None of these pieces work as well alone as they do together.

See it in action

Dimensions Research Security is built to help institutions turn scattered, manual checking into a consistent, audit-ready workflow, from verifying disclosures against global affiliation, funding, publication, patent, grant, and clinical trial data, to documenting every review with notes, tags, and a defensible audit trail. If your institution is looking to move from reactive checks to a repeatable process, request a demo to see how Dimensions Research Security can fit into your existing workflow.