When to apply When the institution needs to capture foreign components, dual-use research of concern (DURC), export-control classifications, and equivalent national disclosures as structured CRIS metadata.
Before you start
Prerequisites
What needs to be in place before you operationalise Research security terminology in your CRIS or repository.
- Awareness of NSPM-33 (US), the UK Trusted Research framework, the EU Dual-Use Regulation, and equivalent national policies in your jurisdiction
- An institutional research-security officer or equivalent function with authority to make determinations
- A controlled vocabulary for foreign-component declarations and DURC categories
- Familiarity with EAR (Export Administration Regulations) and ITAR (International Traffic in Arms Regulations) classification at a working level
- A clear boundary between research-security determinations (institutional) and the underlying confidential disclosures (HR / legal)
Deployment
Five steps to deploy
Each step is small enough to land in a single sprint or a single sitting with the relevant CRIS administrator. Follow in order.
Define a Research-Security Determination entity
Structured record with: determination_type (foreign component / DURC / EAR-ITAR classification / other-national-equivalent), scope, finding (closed list), date, expiry, authorising_officer, linked_projects, linked_outputs, restrictions (closed list).
Capture foreign-component disclosure at project setup
On every new project, prompt for foreign-component declaration: foreign affiliations, foreign funding, foreign collaborators, foreign-located equipment, foreign data access. These are not abstract — they are specific structured fields per category.
Wire DURC review where applicable
For projects in the seven DURC pathogen / toxin / experiment categories (or jurisdiction-equivalent), require a DURC review record before data collection or publication. The review record captures the panel, the date, the outcome, and any imposed restrictions.
Capture export-control classification on outputs and datasets
For controlled outputs, store the ECCN (EAR) or USML (ITAR) code, the determination date, and the determining officer. The output's access mode must align with the classification — controlled outputs cannot quietly become open without re-determination.
Pilot with a borderline project
Pick a project with international collaborators and a potential dual-use angle. Walk through the full determination flow; verify that determinations gate the appropriate downstream actions (publication, dataset deposit, sample export) without producing false-positive blocks.
Worked example
Sample workflow
A realistic walk-through of a single record passing through the Research security pipeline once the checklist is in production.
Integration points
CRIS and repository systems
Vendor-specific notes on where this vocabulary fits in real research-information systems. Names appear here only where there is public field evidence — they are not vendor partnerships.
Custom Determination entity on the Project record; access-controlled to research-security staff. Pure does not natively gate downstream actions on security determinations — bolt on via API.
Custom entity for security determinations; link to Project and Output entities via standard relationship types.
Trusted Research-aligned modules exist for UK institutions; configure foreign-component and DURC determinations as part of the project-approval workflow.
Compliance module covers security determinations; integrate with the project lifecycle so security-blocked phases cannot advance.
Add Determination as a configurable entity; access-control deposit on output records via embargo and group-based access policies aligned with the determination.
What goes wrong in the field
Common pitfalls
The patterns that show up repeatedly when this checklist is skipped or misapplied. Address these before they become entrenched.
- Treating research-security as a once-per-project checkbox instead of as date-ranged determinations that may need re-determination
- Storing ECCN / USML codes as freeform text rather than as controlled vocabulary
- Letting the institutional research-security record drift from the funder-side determination (e.g. NIH foreign-component disclosure)
- Mixing confidential security-officer notes with the public record on the same output, leaking what should not be public
- Treating "no foreign collaborators" as the default and the declaration as optional, so the negative declaration is never recorded and cannot be audited
Frequently asked
Implementation FAQ
- Who maintains this checklist?
- The Research security working group maintains the checklist alongside the dictionary terms in the same domain. It is reviewed each release cycle (March and September) and updated when a working-group consultation, a vendor product change, or a federation-partner schema update materially changes the operational guidance.
- What if my CRIS or repository is not listed?
- The integration points listed name the systems CASRAI has direct field experience with — Pure, Symplectic Elements, Worktribe, Converis, DSpace and DSpace-CRIS, EPrints, VIVO, Dataverse, Invenio-RDM. The CERIF mapping in the checklist is vendor-neutral and applies equally to other CRIS or repository products. If your system supports the underlying entities (Person, Project, Output, Funding, plus the domain-specific extensions), the steps transfer.
- How do I validate my implementation?
- Three validation surfaces. First, the deposit form should refuse a record missing required fields rather than warn and accept. Second, the resulting metadata should round-trip through the federation layer your institution uses (OpenAIRE Guidelines 4.0 for European federation, DataCite Commons for DOI-anchored discovery, Crossref for article-anchored discovery) without upstream errors. Third, walk a real-world record through the sample-workflow path on this page and confirm the structured fields capture what the prose describes.
- Where do I report errors in the checklist?
- Open a comment via the dictionary-feedback flow at /dictionary/contribute. Editorial corrections — wrong vendor module names, deprecated standards, broken integration paths — are queued into the next release cycle. Substantive disagreements on the operational guidance are routed to the working group for review and may motivate a checklist revision.
- Is this checklist enough to certify my implementation?
- No. The checklist gives you the operational baseline; certification against federation profiles (CoreTrustSeal, OpenAIRE-compliant, COAR-aligned) is a separate process with its own audit. Treat the checklist as the engineering scaffolding and the certification as the institutional sign-off that the scaffolding is being used.
