How long does Aspen IRB approval take? Counted in gates and passes, not dates

The question everybody asks has no honest answer in the units it is asked in. What can be answered exactly is the shape of the route: the gates a file has to clear before anybody at the board reads it, and the number of passes the board then takes over it. Shorten the second by getting the first right.

Miriam Kessler, DNP, APRN · filed 2026-08-23

In short. No one can promise you a decision date; the board’s calendar and determination are its own. Count gates instead — the approvals a file needs before filing — and passes, the readings it takes afterwards. Completeness is the only lever you hold.

Why will nobody quote you a date?

Three reasons, and none of them is evasiveness. The first is authority: the determination belongs to the board, and so does the order it works in. Nothing on this site predicts either, and nothing anybody does influences a board except through the quality of the file it reads.

The second is that the route is not a queue but a sequence of conditions. Some sit with you, some with your faculty chair, and some with an organisation that has never heard of your project — the manager who must sign a permission letter, the research office at a hospital, the author of an instrument you want to adapt. A file waits on the slowest of those, and which one that is varies by project rather than by institution.

The third is that a board’s own reading can branch. Aspen’s handbook notes that projects reaching the fuller level require a convened meeting, with a majority of members present including at least one whose concerns are non-scientific, and approval carried by a majority of those attending. Aspen’s programme material adds that projects touching protected populations may call for outside expertise before a view can be formed. Those are structural facts about how boards work, not delays that anyone caused.

Aspen’s current handbook or IRB portal may publish its own expectations for each level of review. Read them as the board’s statement of its own practice rather than as a commitment made to you — and plan the project so that nothing depends on the board moving at any particular speed.

The gates before the board reads a word

Each gate below has a key, and the keys are held by different people. Files stall at whichever gate its owner assumed was somebody else’s job.

Gates on the way in — what opens each, and whose clock it runs on
Gate	What opens it	Whose clock
The project plan, approved	Aspen’s handbook has the application submitted once the proposal has been defended and the project team has approved it — written approval issued on the programme’s own form	Yours, with your faculty chair and committee
Human-subjects training	Certificates completed before the application is submitted, and uploaded with it	Yours entirely
Site permission	A separate letter to the board from the organisation hosting the work — not the same document as any immersion agreement signed earlier	Somebody else’s, which is why it is requested first
The site’s own board, where one exists	Aspen’s guidance is that approval from an organisation’s own IRB is typically sought before submitting to Aspen; where the organisation wants something from Aspen first, the handbook says to ask the IRB office how to proceed	Entirely somebody else’s
Instrument permissions	The author’s written permission where you adapt a published instrument; registration where the publisher requires it	Somebody else’s, and easy to forget
HIPAA paperwork	An authorisation form filed with the protocol wherever medical records feature at any point	Shared with the record-holder
A complete, consistent application	Every attachment present, every number matching the plan, the checklist in the handbook’s appendices actually worked through	Yours — and the one gate that most affects the passes

Notice how many keys sit outside the building. That is the argument for requesting the letter and the outside board’s reading at the very start rather than at the end: no amount of diligence later can start somebody else’s process retrospectively. Our pieces on the site permission letter and on a second board reading alongside Aspen cover both in detail.

The passes, counted from the moment of filing

One pass is one complete reading by the board, ending in a written disposition. Aspen’s handbook names four, and every applicant receives the decision in writing:

Approved. The work may begin — and not before. Recruitment, data access, data collection and implementation all wait for this letter.
Modifications required to secure approval. Changes are needed for the file to meet the criteria. This is the ordinary outcome for a file with fixable problems, and it costs a further pass.
Disapproved. The board has everything it needs and the project as described does not meet the criteria. The notification gives reasons, and you have an opportunity to respond in writing or in conversation.
Deferred. Reserved for an application that is incomplete, or for a convened review where the necessary members were not present.

Read that list as a cost table. The only outcome that closes the route in a single pass is the first. Everything else adds at least one more reading, and each additional reading re-enters the board’s ordering from wherever it happens to be. That is the whole economics of the thing: you cannot make the board read faster, and you can make it read fewer times.

What actually adds passes?

Aspen’s handbook is unusually direct about this. Applications that are incomplete, contain errors or typographical mistakes, or give inconsistent information are, in its own words, delayed. The handbook also asks applicants to work through its checklist before submitting, and points out that mistakes in anything a participant will see — recruitment material, consent, instruments — may put people off or make them doubt the work.

In practice the findings that generate an extra pass cluster into five, and every one of them is visible in the file before submission:

An application that paraphrases the plan it answers to, so that sample sizes, site counts or instrument names differ between two documents in the same file.
A consent that has drifted from the current protocol version, or that is missing one of the required elements.
A site letter that is absent, unsigned, signed by somebody without the authority, or silent about what data leaves.
A data-security answer that says the data will be kept secure, where four named answers are wanted: storage, access, de-identification, destruction.
A category claimed that the design does not support — the most expensive of the five, since every later answer was written to the wrong question.

One consolation: the level of review is not one of your risks. Aspen’s handbook states that neither you, nor your faculty chair, nor committee members determine the level — the IRB chair or a designee does — and that the application exists to gather what the board needs in order to decide. What you control is whether the application describes a design consistently enough for that decision to be made on a first reading. See the review levels for how the claim is weighed.

The gates that come after approval

An approval letter is a checkpoint, not a finish line, and each of these is a gate in its own right:

Changes. Any alteration to an approved project — instrument, consent, site, recruitment method — goes back on a change request and must be approved before you proceed. The handbook notes the review a change receives depends on its magnitude and its effect on the balance of risk and benefit.
Continuing review. Approval carries an expiry. Where the work will outlive the window stated in your letter, the continuing-review form goes in and approval to continue has to be granted.
Events. Unanticipated problems meeting the handbook’s three tests — unexpected, related to participation, and placing people at greater risk — are reported on the events form promptly, as are deviations from the approved plan and violations of the terms of approval.
Closure. Aspen closes the file on graduation or at the expiry of the approval, whichever arrives first; work still running at that point needs the board contacted rather than assumed.

So what can you actually shorten?

The count of passes, and the queue of gates you are standing in. Concretely, that means four habits, and they are the same four whether the project is a chart review or a set of interviews:

Settle the category from the design before any form is filled in, because a wrong category is the one finding that resets everything after it.
Request every outside signature first — the site letter, the other board’s review, the instrument permission — since those run on clocks nobody in your project controls.
Fix the plan, then quote it. Every number and name in the application should be lifted from the approved plan rather than recalled.
Cross-read before filing: application against plan, consent against protocol version, letters against the data answers, certificates against what the portal requires.

That is precisely the inspection we run, and it is the whole argument for reading a file before the board does. The route from there is set out at how it works, stage by stage.

What to do next

If you are counting toward a deadline of your own, count gates rather than dates — then close the ones that belong to other people first. If you would like the file read the way the board will read it, that reading is free and comes back in writing.

Send the file as it stands. Every finding a reviewer could raise is already in your documents, and we write them down before the board does.

Request the free application review

What follows can be handed over in full: the determination and plan, each document built, the filing itself, and each answer the board asks of the file before it decides. What is never promised here is a date or an outcome — both belong to the board. More in the questions answered first.