Every document in an Aspen IRB submission, and how the board reads them against each other
An Aspen submission is not a stack of forms. It is one object, and the board reads it for internal agreement — which is why the commonest defect is never a missing sentence inside a document but a disagreement between two of them. Three documents are required in every case. Ten more become required the instant a particular fact about your design is true. And five agreements run between them, each of which a reviewer will test.
Charlotte Devereux, MSN, RN · 2026-08-23
In short. Aspen requires three items with every application: the chair-signed application form, the approved proposal covering chapters one to three as a Word file, and your training certificates. Ten further documents attach conditionally. Then the board reads all of them against each other.
Where do the forms actually live?
Not on a public page, which surprises people who go looking. Aspen keeps the application directions and every template inside the Center for Graduate Studies Lounge: open Content, then find the Institutional Review Board process. Step one there holds a document setting out requirements, forms and information in more detail than the handbook does, and if a form cannot be found the handbook asks you to write to the IRB office directly — copying your chair, as it asks you to on every message.
Two consequences follow. First, anything you find elsewhere on the internet is not your form; templates move, and a superseded one is a finding waiting to happen. Second, because these live behind a sign-in, it is worth pulling every template you might need into a single folder at the start — advice Aspen itself gives — rather than hunting for an assent form on the evening you meant to file.
What does Aspen require every single time?
Three things, with no exceptions and no conditions attached.
- The application form, approved and signed by your chair. Aspen wants the chair’s signature and the date on the form itself, and the application read and approved by that chair before it travels any further.
- The approved proposal, chapters one through three, as a Word file. Not a summary of it, and not a PDF. This is the document every answer on your application will be checked against.
- Your training certificates. Completion evidence for the human-participants course, finished before submission rather than alongside it, with each module quiz passed at eighty per cent.
Notice that the second item makes the whole package a comparison exercise. The board holds the plan your university already approved in one hand and your description of that plan in the other. Anything that differs between them is a query, and the reviewer has no way of knowing which version is the true one.
What becomes required, and what triggers it?
The remaining ten are conditional, which is a word that misleads people. They are not optional. Each is required the moment a specific fact about your design is true, and the fact is usually easy to check.
| Document | Required the moment… | What it has to carry |
|---|---|---|
| Site permission letter | the work happens anywhere that belongs to somebody else — a clinic, a school, a company, even a private online group | Letterhead, your name, the title, a short purpose, confirmation the protocol was reviewed, the permitted activities, any limits, and an authorised signature with title and contact details |
| Informed consent form | people take part and consent has not been waived by the board | Aspen’s template, tailored; plain language below a ninth-grade reading level; key information placed first |
| Assent form | participants are young people, or adults whose capacity is impaired | Written assent from thirteen to seventeen; a submitted script for oral assent from seven to twelve; guardian permission obtained beforehand |
| Records authorisation | a medical record is opened at any stage, in any format | The authorisation form, filed alongside the protocol |
| Recruitment materials | anyone is invited to take part at all | The flyer, email, post or spoken script exactly as it will be used — not an approximation of it |
| Another board’s approval | the site or a second institution keeps its own review body | That body’s written approval, which Aspen expects you to seek first |
| Instrumentation | any survey, interview schedule, screening tool or protocol is used | A copy exactly as it will be administered |
| Proof of purchase | the tool was bought | The receipt or licence record |
| Permission to use or modify | the author requires permission, or you are altering the tool | The author’s signed permission — always, where anything is modified |
| Supporting material | anything else would help the board understand the work | Training plans, checklists, protocols, or an account of deception or of work with a protected group |
Run that middle column against your own design and the package assembles itself. Most people are missing one row, and it is usually the sixth or the ninth.
Where must the documents agree with each other?
In five places. This is the cross-read, and it is the part that separates a package that is complete from a package that is consistent — a distinction the board cares about far more than the word count of any single form.
- Application against approved proposal. Every figure, instrument name, site count and procedure lifted across word for word. Where the plan is itself still loose, settle the plan first; a document cannot be quoted accurately until it says something definite.
- Consent against application. What a participant is told will happen must be what the application says happens — the same procedures, the same commitment, the same account of where their data goes afterwards.
- Recruitment against consent against instrument. These three describe the same activity to the same person at three different moments. A flyer promising a brief questionnaire, a consent describing a forty-item survey and an instrument running to sixty items is three different projects.
- Site letter against the data answers. The letter says what may happen on the premises; the application says what data leaves and who may touch it. If the application describes something the letter never authorised, the permission does not cover the work.
- Instrument against its permission, and against the plan. The tool named in the proposal, attached in the form it will be used, with any licence or author permission alongside it.
Aspen frames this in terms of what the package tells the board about you: a submission that is accurate and well made gives the board confidence, while one that is incomplete or internally inconsistent will be delayed. Read cynically, that is a warning. Read practically, it is an invitation — consistency is something you can manufacture deliberately, on your own schedule, before anyone else opens the file.
What about the signature itself?
A small thing that stops people on the last evening. Aspen’s application is signed digitally, which means a reader application installed and a digital identity configured before you can apply a signature at all. It is a short task, but it is not one to discover at the moment you intended to submit. The handbook walks through creating the identity and points to the vendor’s own guidance.
A last pass before it goes
Read the package once more as a stranger would, in this order: the recruitment text, then the consent, then the instrument, then the application, then the letter. That is roughly the sequence a participant would meet them in, and reading that way surfaces disagreements that reading document by document hides completely. Then check the plain mechanics — every file clearly labelled, the signature applied and dated, the certificates current, participant-facing pages free of the small errors that make a stranger doubt the whole enterprise.
Which findings that pass tends to turn up is set out in the nine findings written most. Where the package sits in Aspen’s wider sequence is drawn in the process, in order, and which reading it earns is covered in the piece on review levels.
What to do next
Build the package against the two lists above, then have it inspected before the board inspects it. That second pass is what the free application review is: send whatever exists to our contact desk — unfinished is fine, and a file already returned by the board is better still, because its letter tells us exactly what was read. Three consultants run the cross-read, and the report comes back in writing with each finding, the evidence behind it, a severity mark and the correction. Nothing is charged and nothing is owed; when a package is ready, the report says so and ends there. Where it is not, we can carry all of it: the classification settled from the design, every document built and cross-read, the submission prepared and filed with you, and each reply answered until the board has done writing. The project remains yours throughout, and so do its data and its conclusions; the decision remains the board’s. How it works sets out the stages, and our FAQ answers what usually comes next.